[Chicken-hackers] [PATCH] Handle import libraries with static linkage egg property

[Evan Hanson]

Hi there,

On 2019-05-29 11:39, address@hidden wrote:
> address@hidden wrote:
> > > On 2019-05-07  7:45, Evan Hanson wrote:
> > > > On 2019-05-06 13:04, address@hidden wrote:
> > > > > I don't think that patch is right. If you emit import libraries from 
> > > > > the
> > > > > static builds, you will not be able to import modules from the 
> > > > > evaluator
> > > > > when the modules are statically linked, because the module 
> > > > > registration
> > > > > code is taken out.
> > > > 
> > > > Oh, of course, you're right. I suppose the bug is really that the build
> > > > script tries to compile these files, then, and not that they aren't
> > > > emitted?
> > > 
> > > No, that's not right either. It's a combination of the two: if they're
> > > not emitted, there's no file to install and separate compilation is
> > > impossible, but if they *are* emitted then they're removed from the
> > > compiled artifacts and ipmort-in-eval fails (as you point out).
> > > 
> > > I wonder... For static-only extensions, do we perhaps need to add a call
> > > to csc with "-analyze-only" just to produce the import libraries? And in
> > > the meantime, should we "undocument" the static option for "linkage"
> > > with something like the attached?
> > 
> > I dunno, this somehow defeats the purpose of the linkage property.
> > I think it is better to change the behaviour to do the right thing instead
> > of defining an switch that has just a single option.
> 
> Should we fix this for 5.1?
> 
> In any case we should probably open a ticket to keep track of that issue.

I finally got around to this.

I decided it would be dumb to invoke the compiler an extra time just to
emit import libraries when we're already compiling the extension once;
better to just have csc do what we need it to on that one pass.

I spent a while trying to make this work with the current set of
options, but in retrospect that's impossible. There are now three
situations we need to support: (1) the current "sane default" behaviour
where emitting an import library removes it from the program, (2) the
situation where a user explicitly drops the library code by passing the
"-no-module-registration" flag, and (3) this new situation where we need
to both emit the library code and keep it in the program. To support
this third case I've added a flag that causes the module registration
code to be preserved in the program unconditionally -- basically the
inverse of `-no-module-registration' -- which chicken-install then uses.

I think this is a pretty logical addition, and it fixes the linkage egg
property, but let me know what you think.

Cheers,

Evan

0001-Handle-import-libraries-with-static-linkage-egg-prop.patch
Description: Text document