Re: [Mingw-users] [4.4.0] g++ packaging bug, libtool

[Dave K. <dav...@go...>]

Charles Wilson wrote:
> Dave Korn wrote:
>> [ not (fully) subbed to the list, cc me if replying. ]

>>   The attached patch works around
>> that bug by finding the right bin dir and putting the correct relative path in
>> the .la file.  It works by ascending the dir tree until it finds ...../lib/,
>> so it could conceivably go wrong if you use some bizarre setting for
>> --libexecdir or one of those configure settings.
> 
> Hmmm.  Do you think these two libtool patches should go upstream? With
> the removal or rewording of some of the comments, I think so.  Who wrote
> them? Can we get them proposed/pushed to libtool-patches?

  I wrote it, so there's no problem about that, but the reason I haven't sent
it upstream is because I don't think it's suitable.  It's not generic or
robust enough; it works only for the single case of building a library in a
deep subdir of $prefix/lib.  If you were building a var into a deep subdir of
(e.g.) $prefix/share/$packagename/...., it would fail because it wouldn't know
when it had ascended enough to reach $prefix, wouldn't find a /lib/ component,
and would end up (as I found out when I tried this patch against libtool head
and ran the testsuite) ascending all the way up to / and installing into /bin.
 (No, you can't even bail out early if you ascend to a directory where you
find a /bin/ subdir, because during "make install" $prefix/bin hasn't
necessarily been created yet by the time it's started installing runtime libs.
 No, you can't bail out early if you reach all the way up to $prefix, because
libtool has no idea what $prefix is, it knows only the destination path to
install the .la file.  So AFAICS there's no generic way to know how far to
ascend and how far is too far.)

  So, that patch is only good for compiling GCC in a standard $prefix layout,
and could break even for GCC if you set --libexecdir= somewhere strange.  I
think the only real generic and robust solution is for makefiles to explicitly
pass $bindir to libtool as a new command-line option when installing.

>>> Second, I don't know how the import libraries got named _s.a
>>> or why -- I assume gcc/collect2/ld likes 'em that way.
>>  I wouldn't make assumptions...
> 
> Dave is correct (kinda).  Actually, Aaron renamed the import lib
> specifically so that ld would NOT find it unless explicitly told about
> it.  See below.

  This is perhaps his solution to the problem that there's no
--static-libstdc++ option in the gcc driver (fixed in 4.5.0).

>>   If I were you I'd try and get them built right in the first place rather
>> than fix it up afterward.  Libtool can be easily confounded by manual changes
>> made to the layout of a package after installation.
> 
> Well, yeah...but I'm just trying to work with what is present in the
> existing mingw-gcc-4.4.0 so that I can build gettext; if the next
> release of mingw gcc is better, great. But I'm not knowledgeable enough
> about gcc to /tell/ Aaron how to fix it -- I'm just informed enough to
> identify that yep, there is some sort of problem here.

  Well, bearing in mind that it's a beta package and some of these quirks
might not be long-term strategies but temporary workarounds in search of a
longer-term fix, I'd suggest crudely hacking your way around it by e.g.
manually hacking around your installed .la files to point to the right places.

> MinGW's current binutils is 2.19.1 from early Feb 2009.  Probably not
> new enough, so we'll need a new version.

  CVS HEAD should be in pretty good shape right now, I hope.

> Well, if Aaron's accepting reco's for the next mingw gcc, then I'd say:

> Except...Aaron did all that for a reason.  See below.

  Righto, I think just hacking around your local install to get libtool to
build for you is the way to get started for now.

>>> Okay, now back to the C++ problem.  Libtool has to "run" the link
>>> itself, using g++ -nostdlib.  So, it has a lot of code to suss out what
>>> g++ actually does when !-nostdlib, and then tries to mimic it.  
>>   (Side note: Y'know, attempting to duplicate the same extremely complex logic
>> in two entirely separate places is a really bad design.  I wonder if libtool
>> could be in some way integrated with or make use of the gcc driver to get this
>> stuff done properly for it.)
> 
> Well, that's not really what libtool is doing: the libtool devels don't
> try to "maintain" a copy of gcc's logic in the libtool code by hand.
> Instead, each time you configure/build an instance of libtool -- which
> happens every time you configure/build any libtool-using package -- the
> configury magic actually invokes g++ and tries to figure out what it
> actually does.  Then, it hopes simply to mimic that, later.
> 
> So...I think it actually does "make use of" the gcc driver...

  Ah, it's more sophisticated than I understood.  I tend to come to things
long after the scripts have been generated and find myself debugging the more
generic parts that come from the template anyway.

>> .o files from the static archive.  But in general mixing the shared and static
>> libs like that is a risky business.... ODR violations abound.
> 
> Ah. OK. I think I have found the (remaining) problem (and also the
> explanation for why Aaron renamed the import library away from its
> normal .dll.a):
> 
>   Shared libstdc++: Compile with -D_GLIBCXX_DLL and add -lstdc++_s to
>   your link flags to link against a DLL version of libstdc++.
> 
> So, mingw-g++-4.4.0 defaults to using the static runtime. BUT, libtool
> sees the .la file for libstdc++.la, and by default tries to link
> "dynamically" unless told otherwise.

  Ah.  I'd guess Aaron wanted static linking to remain the default because
it's more conformant (cf. ONDEE) and reliable at the moment.

> With the original .la file, it sees library_names="libstdc++.dll.a" and
> uses that -- but this fails because the file has been renamed.  After I
> modified the .la file to say library_names="libstdc++_s.a", it finds the
> import library -- but the link fails because my objects were not
> compiled using -D_GLIBCXX_DLL.

  Ah, which presumably somehow activates _dllimport attributes.

> So, I think I can work around my problem, at least on MY system and for
> my own purposes, by 

  Looks like the right approach to me.

> But the larger problem remains.

  Hopefully when the shared libstdc++ is stable enough to be the default,
Aaron can do away with the renaming trick, and that and patching the libtool
install script to find the bin dir should bring everything back into line with
the SP, I think.

> Dave -- In the cygwin release, we don't seem to require a compile-time
> flag when switching between static and shared libstdc++, nor funky
> renames to "hide" the import library from ld, do we? What magic is this,
> and can you share it with Aaron?

  I'm just relying on the default behaviour, but then I'm happy to go with
shared linking as the default, which is not the mingw way.  With this setup,
mingw users can make standalone C++ executables or ones that depend on shared
libgcc only, and it takes extra steps to make an exe that needs both shared
libs because for mingw people want stand-alone executables as much as possible.

    cheers,
      DaveK