Re: [PATCH] Build libgcj, libgcj-tools, and libffi as shared libraries on Windows

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Aaron W. LaFramboise wrote:
> Yes.  Sorry, I forgot to mention this.  In addition, we specifically do
> not want this function to be exported from the DLL at all.  See below.

Well, with the default ld behavior, we /are/ exporting darn near
everything, including these ltdl symbols.  By ensuring that the ltdl
symbols are not decorated, and given that no other symbols anywhere in
libjava are decorated, you in effect turn the default
--enable-auto-export behavior back on -- just as if you had explicitly
specified it on the command line.  But you knew that.

> OK, I will fix this comment to reflect the purpose of this name change.

Good enough, given <below>.

> The new libltdl does not have this issue.  I have no idea why we're
> stuck with the 1.5 version of libltdl even though we're using a recent
> libtool.

Yes, I thought we had fixed this.  I don't remember, but perhaps back in
spring '07 when the Great Autotool Update happened -- taking libtool
from 1.4p3-FORK to libtool-CVS-HEAD-20070318, the decision was made to
postpone the libltdl bits until the "real" libtool-2.0 (now called
libtool-2.2) was released.  I guess.

I noticed another thread where Peter O'Gorman was proposing to update
libtool in gcc to latest libtool-git-tip (e.g. now that libtool-2.0 ne'
libtool-2.2 is out). Perhaps the update to more recent ltdl would be an
appropriate addendum/followup to his patch.

For now, tho:

> However, libltdl seems to have been modified in similar ways by other
> people; just look at the ChangeLog.  Since everyone else is modifying
> this, and this is not an issue in the upstream version, I think this is
> the best change.

Sure. If -- for whatever reason -- we are currently using a forked
version of old ltdl, there's not too much reason to worry about
maintaining synchrony with the original (and independently progressed)
version over at libtool-git.

> Updating to a newer libltdl would probably be good, since I suspect
> there are Windows-specific improvements in it.  However, libjava would
> need to be ported to it, since its currently dependent upon interfaces
> that have been removed in newer versions of libltdl. 

Right. If I am correct above, this was probably the rationale for why it
didn't happen as part of the Great Autotool Update: too messy to deal
with all at once.  But now...maybe it's time. But I agree -- that is a
big effort, and shouldn't be part of your patch here.

> There may also be
> other reasons we're still using this old version of libltdl.

I doubt it. Probably just inertia.

> I don't like this solution as much, as these exports really are not
> dllexport, and we specifically do not want them to be exported--even
> though we are doing nothing at present to prevent this. 

Ack.

> (As I mentioned
> previous, a future patch will fix this symbol leakage.)  For this
> reason, I think it's important we completely avoid marking these
> dllexport, beyond fixing this specific issue.

That makes sense. I wonder if the right approach is to once again
leverage the version script stuff and generate a .def file, like you did
for libgcc.  But later.

> If it's all the same to you, I like my solution better. :)  Let me know
> if you still feel differently, and maybe we can talk more.

No, it's fine.

BTW, I don't think I've mentioned this: but /thank you/ for your efforts
this summer.

--
Chuck