Re: DLL naming conventions
"Gary V. Vaughan" wrote: > > > > Also, there are two separate issues being discussed here: (1) how to > > (compile-time) link against the 'right' version of a library, and (2) > > how to insure that the 'right' dll is loaded at run-time. > > Nah. I'm talking about (2) only. I *am* assuming that at link time > the only version of a library you can link with is the one that > corresponds with the header files you have installed. Okay. I was just going by the example from http://www.debian.org/Lists-Archives/lsb-spec-9905/msg00011.html, quoted here: --- > The development links become a bit more complex. The temptation is to > place both development sets in their own subdirectories, providing: > > /usr/include/gmp1 > and > /usr/include/gmp2 > > and the development symlinks: > > libgmp1.so > and > libgmp2.so > > This causes problems for packages which expect to build against gmp. > Having to edit the make file to reflect the correct include and link names > is not a clean solution. > > Thus, for gmp-2.0.2, the includes are provided in /usr/include, and the > development link is libgmp.so. Only gmp1 need be placed in the special > locations above. But, you are right. The extra linktime libaries are only necessary if you also have the extra header files in a special directory. Since you have to edit the makefiles (and possible the source code) for 'package X' that depends on the old interface (gmp1 in this example), then you might as well specify '-lgmp1' and you don't need the symlinks. > > Since windows-dll > > loading is based on the executable path, and not 'LD_LIBRARY_PATH' or > > similar, you've got a problem. > > Most definitely. Chris argues against this in his other message. I'll reply to that point in a separt message. > > > It would be nice if you could create a 'cygwin LD_LIBARY_PATH' and a 'PW > > LD_LIBRARY_PATH' etc. But that probably requires that you abandon dll's > > altogether, create your own 'so' file format, write an ld.so (ld.dll?) > > that will load .so's 'just like unix (tm)'. And, for this to work > > cleanly, such a beast would have to be written for ALL the major unix > > emulation environments. However, we're just concerned with cygwin, > > here. (I can't take credit for this idea; both Tor Lillqvist and Chris > > Faylor have on occaision mentioned something similar) > > In an ideal world. I'd be surprised if anyone is keen enough to > actually write it though. Far more likely that we can find the time > to make incremental improvements and adopt some conventions that make > things work a bit better... I think the ld.so stuff is very ambitious. IMO, it's something to keep in mind for the next major revision of cygwin -- but then, I'm not an official spokesman. Again, IMO, 'adopting some conventions' is the way to go right now -- just like we adopted the convention that 'libfoo.dll.a' means an import lib. > > You can (mostly) fix point (1: compiletime version) by careful naming > > and use of import libs + careful naming and use of dll's. > > > > For instance: > > > > libpng.dll.a --> libpng3.dll.a > > ^^ > > symlink > > > > libpng30.dll.a (most recent API, corresponds to png-2.0.x) > > embeds the name "libpng3.dll" > > libpng20.dll.a (older API, corresponds to png-1.0.x) > > embeds the name "libpng2.dll" > > > > Programs linked against '-lpng' will be dependent at runtime on > > libpng3.dll. Programs linked against -lpng2 (or against '-lpng' before > > version 2.0.x was installed -- e.g. when libpng.dll.a --> libpng2.dll.a) > > will be dependent at runtime on libpng2.dll > > Why bother with the symlinks? You can't link against -lpng2 unless > you have matching headers, and presumably you upgraded those when you > installed libpng3.dll. > > My proposal was to start with this: > > libpng.dll.a embeds libpng2.dll > > and we keep libpng1.dll around for the applications that were > linked against interface 1. > > when we install png-2.0, which implements a new interface that is not > compatible with libpng2.dll, we install: > > a replacement libpng.dll.a that embeds libpng3.dll > libpng3.dll > > and we keep libpng2.dll around for the applications that were > linked against interface 2. > > and we keep libpng1.dll around for the applications that were > linked against interface 1. You are (mostly) right. The symlinks are not really necessary -- but keeping libpng20.dll.a is a good idea (assuming you also kept the 2.0.x headers around, and put them in /usr/include/png2/. The symlink buys you ease of installation for the implib. Suppose you had 1.0.x installed, so libpng.dll.a embeds libpng2.dll. Then, you install 2.0.x. First, you need to rename libpng.dll.a to libpng2.dll.a, and then install the new implib as libpng.dll.a. With symlinks, none of that is necessary -- just install the new implib as libpng3
Re: GNU Libtool 2.2.8 released (stable)
On 6/8/2010 2:46 AM, Gary V. Vaughan wrote: > [[Adding Libtool List]] > > On 8 Jun 2010, at 08:56, Charles Wilson wrote: >> What happens if libltdl is >> used to load (say) libtiff which has an automatic dependency on libjpeg? >> The initial LoadLibrary from libltdl pulls in libtiff.dll AND >> libjpeg.dll, but only libtiff.dll gets a registered handle in libltdl. >> Suppose then the client app explicitly loads libjpeg.dll via libltdl -- >> does that work ok? > > If it doesn't, then that's a bug. Libltdl is supposed to keep track > of everything it loads, But the point here is that Bob is advocating that (in the first half of the example above) *libltdl* does NOT explicitly load the libjpeg dependency. However, the Windows *will* load it "behind the scenes" and automatically, when libltdl does a LoadLibrary(libtiff) because libtiff depends on libjpeg. Once Windows has done so, and THEN libltdl attempts to do a LoadLibrary(libjpeg) -- when libjpeg has already been "privately" loaded, unbeknownst to libltdl -- what happens? > and if it gets a request for a handle to a > library it loaded already, it can pull one out of it's internal data > structures without having to call the underlying module loader again. Except that in this proposal, its internal data structures wouldn't know that libjpeg has already been loaded. > More interesting still: I think things might blow up if the .la files > have been removed on a platform that does automatic deplib loading for > runtime linking, say lt_dlopening libpng.dll (which pulls in zlib > through LoadLibrary without libltdl knowing about it), and then the > application tries to lt_dlopen libz.dll. Uhm, isn't this the same scenario I was outlining, with libtiff + libjpeg? > It then depends on whether > the underlying LoadLibrary implementation is smart enough to realise > that it already has a copy of libz in memory and returns a handle to > it without trying to reload another copy first... this would be an > interesting test to have in the next release to see what feedback it > brings. Yes. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
On 6/8/2010 6:47 AM, Christopher Hulbert wrote:
> Peter/Charles,
> Do you have a summary of the capabilities added by your
> patches/branch
I'll let Peter speak for himself, but these are the patches in the
cygwin and mingw distributions:
* Pass various runtime library flags to GCC. (-shared-libgcc, etc)
1 file changed, 4 insertions(+), 1 deletion(-)
Apparently there is some argument here about how the various
-shared-{runtimelib} and -static-{runtimelib} flags should be
handled.
* [cygwin|mingw] Refine UAC support.
1 file changed, 17 insertions(+), 4 deletions(-)
* [cygwin|mingw] Create UAC manifest files.
1 file changed, 33 insertions(+)
* Refactor cwrapper cross-compile support; Add cygwin.
4 files changed, 617 insertions(+), 131 deletions(-)
* [cygwin|mingw] fix dlpreopen with --disable-static take N
3 files changed, 282 insertions(+), 25 deletions(-)
The UAC patches were most recently discussed, but that discussion
wandered off into the weeds of how UAC should be documented in the .info
file, and we never got back around to actually considering the patch
itself. My plan was, once the UAC stuff was resolved, to go back to the
well and try to get the other three merged, one at a time.
Only...my ability to participate is somewhat bursty. When those bursts
are expended on...bikeshedding...it saps my will to continue bloodying
my forehead against the brick wall. So...there we have sat, for the
past few months, since my most recent burst.
--
Chuck
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: pr-msvc-support merge
On 6/16/2010 8:30 AM, Peter Rosin wrote: > It was the easiest I could come up with after experimenting a lot. That > wasn't yesterday though, but IIRC if you want to convert paths with > spaces, you need to quote the $path for cmd, hence the quotes in the > echo "$path " construct. The space before the end quote will make the > argument always contain a space which forces MSYS to add quotes when the > path is fed to the Windows process (cmd in this case). The quotes are > added by MSYS after converting the path to windows form. Without that > space, the string is only quoted if it happens to contain a space, so > view it as a canonicalizer. The sed script is there to remove those > quotes (and the space before the end quote). Also, something seem to > mysteriously add a space at the end, so I'm removing that too while at > it, but only if it's really there (it felt like a bug that might be > fixed at some point). It might be possible to use eval to remove the > quotes, but since the path will typically contain backslashes I didn't > want to go there. func_path_conv() assumes that you ALWAYS want to convert from "something unixish" to win32. If that's the case -- e.g. it appears to only ever be called from inside func_cl_wrapper, for which that would always be true -- then it needs to be documented better. The current comment: # Convert a $build path to $host form and store it in $path doesn't specify that it only works when $host is win32ish. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/19/2010 11:45 AM, Bob Friesenhahn wrote: > Unfortunately, my MinGW testing is not so successful. The testing still > quits part-way through with some sort of make-related issue (as reported > in detail previously). Odd. My last test on MinGW was very successful. This was version 1.3266 (ef56e98f3 IIRC). I'll give it another go @ f0584085. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/19/2010 3:27 PM, Bob Friesenhahn wrote: > The 'make' used is GNU make 3.79.1. Yikes. Where did THAT come from? MSYS has provided at least make-3.81 for several years; the current msys make is 3.82. > There is a 'mingw32-make' which is > GNU make 3.82, but does not seem to work under MSYS. Right. mingw32-make is for when you do NOT have msys installed, and just want to use a makefile with MinGW gcc. Obviously, without msys, you can't run configure scripts, or generate Makefile's from Makefile.in's, etc -- or use libtool. Just as obviously, when building libtool itself, you darned well better have msys installed, so mingw32-make is not appropriate. Besides, mingw32-make doesn't grok msys-style pathnames. I sounds like your msys installation is WAY out of date. What I would suggest is the following: 1) download and install mingw-get (get the .zip file, and unpack it somewhere innocuous like C:\Temp\MinGW-Installer -- NOT C:\MinGW, because we don't want to disturb your existing TDM mingw compiler. You do not want to use easier mingw-get-inst wrapper, because it will automatically also install mingw.org's gcc, and you're using TDM. You *could* use mingw-get-inst, but (a) you'd have to pick a different installation directory, and (b) by default, your new msys would be in C:\\msys\1.0, NOT C:\msys\1.0. 2) edit C:\Temp\MinGW-Installer\var\lib\mingw-get\data\profile.xml (if it doesn't exist, copy default.xml). You should change the following two lines: To this: The default configuration will install a new MinGW into , and a new MSYS into /msys/1.0. You don't want that...so you have to edit the defaults. You might want to move your existing msys installation out of the way. Then, from a cmd prompt, cd to C:\Temp\MinGW-Installer\bin and do this: mingw-get update mingw-get install mingw-dtk The first command updates all of the locally cached package manifests to the latest version. The second command downloads and installs a selection to tools that will closely mimic the old "MSYS-DTK" package -- into C:\msys\1.0\*. However, as mingw-dtk (and the old "MSYS-DTK") collection includes "mingw"-ish autoconf/automake/libtool, THOSE tools will get installed into /*. It's up to you whether you should brute force copy these files over onto your existing TDM C:\MinGW or not (but do NOT put them into C:\msys\1.0!!!) Alternatively, of course, you could edit the mingw32 subsystem path specification in profile.xml, and install THOSE components directly into C:\MinGW. After that, you need to edit C:\msys\1.0\etc\fstab to add C:\MinGW /mingw as usual...but that's old hat. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/19/2010 12:57 PM, Charles Wilson wrote: > On 9/19/2010 11:45 AM, Bob Friesenhahn wrote: >> Unfortunately, my MinGW testing is not so successful. The testing still >> quits part-way through with some sort of make-related issue (as reported >> in detail previously). > > Odd. My last test on MinGW was very successful. This was version 1.3266 > (ef56e98f3 IIRC). I'll give it another go @ f0584085. MinGW/MSYS: old -- All 122 tests passed (2 tests were not run) new -- 108 tests behaved as expected. 12 tests were skipped. MinGW.org gcc 4.5.0 MinGW.org binutils 2.20.51.20100613 MSYS 1.0.15(0.47/3/2) 2010-07-06 22:04 i686 Msys make-3.81-3 (not 3.82! I should probably update...) msys-bash-3.1.17-3 msys-coreutils-5.97-3 msys-m4-1.4.14-1 mingw-runtime-3.18 (/mingw/include/_mingw.h) w32api-3.14(/mingw/include/w32api.h) -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/20/2010 11:31 AM, Bob Friesenhahn wrote: > On Sun, 19 Sep 2010, Charles Wilson wrote: >> MinGW/MSYS: >> old -- All 122 tests passed (2 tests were not run) >> new -- 108 tests behaved as expected. 12 tests were skipped. > > With Charles Wilson's assistance, I updated my MinGW environment to the > latest, but using the latest TDM GCC 4.5.1 compiler (only C & C++ > supported). > > These were the results: > > ERROR: 102 tests were run, > 6 failed (4 expected failures). > 18 tests were skipped. > > The test which failed (twice) was the C++ exception handling test. > Similar tests also failed in the GraphicsMagick test suite so it seems > that C++ exceptions are unreliable with this compiler. This is really strange. TDM's builds include special support *specifically* addressing C++ exception handling when linking against the static libstdc++ (and, IIUC, linking against the shared libstdc++ Just Works(tm) for both TDM and mingw.org compilers). IIRC, TDM's compilers link against static libstdc++ by default, and mingw.org's link against the shared libstdc++ by default -- but I'll need to double check that. Bob, if I were you I'd raise this as a bug on TDM's sf page: http://tdm-gcc.tdragon.net/bugs http://sourceforge.net/tracker/?group_id=200665&atid=974439 because if it "works" with mingw.org, but fails with TDM...well, that's a TDM bug, since John E. attempts to allow working exceptions-across-dll-boundaries for BOTH -static-libstdc++ and -shared-libstdc++. (Note that mingw.org's g++ WILL fail to propagate exceptions across the DLL boundary unless -shared-libgcc, which is the default for -shared-libstdc++, which itself is the default. Not sure about -static-libstdc++ with -shared-libgcc, but -static-libstdc++ -static-libgcc is right out. However, since it *works* with mingw.org, I don't think a screwup related to these flags is the culprit.) > As a side note, I find that the GNU make delivered with current MinGW is > at least 60X slower than before. It takes GNU make 2.5 minutes before > it does any actual work (while building GraphicsMagick), which > represents most of the compilation time with the previous make. A > one-year old Cygwin make takes maybe 1.5 seconds to start working when > given the same environment. And for this, I'd appreciate it if you could open a bug at mingw.org's tracker: http://sourceforge.net/tracker/?group_id=2435&atid=102435 -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/20/2010 1:41 PM, Ralf Wildenhues wrote: > I'd really appreciate if you guys could send build logs to the autobuild > server... > Here's what I use, more or less, to create the logs: > > ( ../libtool/configure [OPTIONS] \ > && make \ > && make -k check > cat test-suite.log tests/testsuite.log > if tail tests/testsuite.log | grep '^| ' >/dev/null; then :; else > sed 's/^/| /' config.log > fi > ) > logfile > > $sanitize logfile > mail libtool_autobuild.josefsson.org < logfile > > with the underscore replaced by @. For now, OPTIONS includes > autobuild_mode=bla if there is anything special about the build. See, that's what was missing. You had asked about a month ago for me to save all the logs from my various tests...but I had no idea what to DO with them. Anyway, those are all a month out of date, so I'll test the 2.4 release on those platforms and submit new reports. We should probably create some sort of reporting script (post 2.4, of course) and mention it (and its usage) in HACKING. Perhaps also in the message you get at the end of the new testsuite when there are failing tests. Right now that message says (for instance): = Please send `tests/testsuite.log' and all information you think might help: To: Subject: [GNU Libtool 2.2.11a] testsuite: 78 112 failed You may investigate any problem if you feel able to do so, in which case the test suite provides a good starting point. Its output may be found below `tests/testsuite.dir'. = -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
Peter Rosin wrote: > Just a friendly ping, but only just now I pushed a change to the > 'compile' script in automake and would like the new version in > the release if it's not too much to ask for. Thanks! Errr...is that kosher? I thought libtool was only supposed to ship the scripts provided by released versions of automake, not git head copies... Otherwise, if I autoreconf the libtool source archive, then I will downgrade 'compile' et al unless I take special steps. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On 9/21/2010 9:21 PM, Gary V. Vaughan wrote: > I don't recall having done so in a while but, according to bootstrap: > > # It is okay for the bootstrap process to require unreleased autoconf > # or automake, as long as any released libtool will work with at least > # the newest stable versions of each. Generally, newer versions offer > # better features, and configure.ac documents oldest version of each > # required for bootstrap (AC_PREREQ, and AM_INIT_AUTOMAKE). > > And in the release template in HACKING: > > You will then need to have recent (possibly as yet unreleased) versions > of Automake and Autoconf installed to bootstrap the checked out > sources yourself. > > So, I will install git automake at the front of my PATH, and if the > release process works, then I'll go ahead and use it for the release. OK. If it's documented, then that's fine. > Is there a better way to save rebootstrappers from accidental > downgrade than specifying AM_INIT_AUTOMAKE([1.11a]) in libtool's > configure.ac? Pity Automake doesn't use gnulibs `git-version-gen' so > that I could specify the particular revision with the compile script > patch that we want at libtool bootstrap time. Well, now that I think about it, it doesn't REALLY matter (to me). The only case, at this time, in which you need the compile script IN libtool to be latest-n-greatest is if you are building libtool itself using cl.exe/MSVC. I'm not. So...it doesn't matter if I "downgrade" the compile script by rebootstrapping with released automake. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
Just FYI... I don't think the following scenario applies to either of you, but I ran into the warning in the case described below -- and the warning is valid (e.g. we shouldn't try to fix MY case). I was using a cross compiler with sysroot support (cygwin->mingw) to build cygwin's setup.exe. I was linking against some pre-built libraries (compression, gpg) built using that cross compiler, but using an older, pre-sysroot-support version of libtool. (E.g. these libs are NOT the mingw-libfoo packages currently available from cygwin.com). Anyway, so what I had was: /usr/i686-pc-mingw32/sys-root/mingw/lib/liblzma.la etc, but -- because the lib was built using a non-sysroot libtool, the .la file specifies libdir='/mingw/lib' NOT libdir='=/mingw/lib' So, when building setup.exe using a libtool that supports --with-sysroot, it (quite rightly) complains that liblzma.la "appears to be moved" -- because it (a) is NOT in /mingw/lib, and (b) doesn't have the magic '=' sysroot marker. This is as designed. The "fix" is for me to rebuild liblzma et al using a sysroot-capable libtool. Just wanted to point out this scenario, which has similar symptoms as those reported by Marco and Dave, but is NOT an error. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: bogus warning 'seems to be moved'
On 9/24/2010 12:45 AM, Marco Atzeri wrote: > I am not sure to follow your explanation. > > on cygwin > > $cd /usr/lib I'm cross building, using $build_os=cygwin, but $host_os=mingw32, and a cross compiler. I am *not* building natively. In this situation, and with the new "sysroot" support in libtool, .la files will have a magic marker like this: -L=/some/path, or libdir='=/some/path'. The extra '=' symbol is interpreted by (new) libtool, WHEN it too is told that "sysroots" are active, to mean: pretend /some/path is prefixed by whatever the "sysroot" of the current compiler is; e.g. 'i686-pc-mingw32-gcc -print-sysroot' might report: /usr/i686-pc-mingw32/sys-root So, if the .la file in /usr/i686-pc-mingw32/sys-root/mingw/lib/foo.la claims that its libdir should be "=/mingw/lib", libtool will magically prepend the compiler's sysroot, and interpret the libdir specification AS IF it said libdir='/usr/i686-pc-mingw32/sys-root/mingw/lib' and not libdir='=/mingw/lib' Since that IS where the .la file is located, all is well and no warning is printed. However, WITHOUT sysroot support in libtool (or if the .la file doesn't have the magic '=' marker) none of this occurs, and libtool will print the warning. But...that's what it is supposed to do in this case. Now, I'm talking ONLY about a cross build situation. See (latest 2.4 libtool) info. There's a whole section about it. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.4 released [stable]
On 9/30/2010 7:19 AM, Paolo Bonzini wrote: > Note that it's perfectly possible to use .la files on the final system > that didn't go through "libtool --mode=finish", as long as all the > packages you compile are upgraded to Libtool 2.4 (and IIUC, cygwin's > packaging system for example is already re-libtoolizing each package, so > it's not that hard to do this). Except that we still haven't added '=' support to libltdl. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.4 released [stable]
On 10/1/2010 2:23 AM, Alon Bar-Lev wrote: > I wanted to see the process this way... > > export SYSROOT=/tmp/root1 > > package1: ./configure > package1: make install DESTDIR=/tmp/root1 > > package2: ./configure > package2: make install DESTDIR=/tmp/root2 What you are missing is that "sysroot" is primarily something associated with cross-compilers, not native compilers (so your "configure" would need a "--host=something --build=somethingelse"). Also, it's something that is understood by the compiler and binutils you are using. Even if libtool were to use an env variable as you suggest, the most likely setting would be: SYSROOT=`i686-pc-mingw32-gcc -print-sysroot` ^^^ cross compiler name But...if the "correct" sysroot can be detected from the compiler, why explicitly pass the value in the first place? Why not just tell libtool to grab the value from the compiler, itself? Using something like... --with-sysroot. (Note that --with-sysroot=/some/path is merely a mechanism to allow overriding the detected sysroot in odd cases; typical use would be --with-sysroot without a path argument). Also, the "DESTDIR" differs from sysroot, in that on the cross compiler build system, you would actually install the compiled product INTO the sysroot *permanently* -- to support building and linking against it when cross-compiling additional packages. It's not "temporary" in any way. (If you were creating a cross-compiled package that somebody else would install as part of a cross-compiling SDK -- think Fedora's mingw packages -- then you might use both sysroot *and* DESTDIR). --prefix, sysroot, and DESTDIR serve different purposes. Please, over the past three months there were hundreds of messages discussing sysroot and how it shoold be handled. While libtool's support is not yet complete, what IS there is the result of those discussions. Please read them; I have a suspicion you don't quite grok what sysroot is really FOR, so your assumptions about how it should/shouldn't/does/doesn't work are somewhat flawed. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.4 released [stable]
On 10/1/2010 4:22 PM, Alon Bar-Lev wrote:
> On Fri, Oct 1, 2010 at 3:35 PM, Charles Wilson
> wrote:
^^^
>> Please, over the past three months there were hundreds of messages
>> discussing sysroot and how it shoold be handled. While libtool's
>> support is not yet complete, what IS there is the result of those
>> discussions. Please read them; I have a suspicion you don't quite grok
>> what sysroot is really FOR, so your assumptions about how it
>> should/shouldn't/does/doesn't work are somewhat flawed.
>
> You assume wrong.
> I use cross compilers as much as I use native ones.
Then why was your example, demonstrating how "sysroot should work",
shown as using native tools? I don't know of a single distributor that
enables sysroot support in their native toolchain.
And...sysroot support, per se, is still very very new even in GCC. But,
gcc cross compilers with sysroot support is the primary milieu for which
libtool's own sysroot stuff was implemented.
> This why I waited and followed for long libtool's lacking support in
> these environments.
> I guess you know better and sure that all OK, this ends the discussion
> before it started.
No. It's just that your statements, and your *example*, lead one to
believe that you were approaching the sysroot issue from a perspective
OTHER than the one for which libtool's implementation was designed.
IF you have an issue with that design, AND you were "following for long"
libtool's development of it...why didn't you chime in three months ago?
> Anyway, sysroot and cross compile sysroot can be the same, however,
> making the cross compiler sysroot dirty, may cause undesirable
> results, especially in build machines.
See, this is exactly what I'm talking about. The whole POINT of
libtool's sysroot is so that you CAN install the built libs into the
compiler's sysroot, so that they can be automatically used there when
building OTHER libs and apps that depend on them. It's not making it
"dirty"...
> Here comes the DESTDIR to the
> rescue.
And you can STILL use DESTDIR if you like. However, if you are trying
to create *multiple* sysroots that can be used by the same compiler (at
different times, obviously)...then you can do this:
set CFLAGS+="--sysroot=/my/sysroot1"
(similar for CPPFLAGS, CXXFLAGS, LDFLAGS, etc)
That way, your compiler will use the "correct sysroot". Then, you can
also ensure that *libtool* knows to "turn on" sysroot support for
linking .la files, by configuring whatever it is you are building with
libtool's --with-sysroot=/my/sysroot1 option.
(I'm not sure if you can get away with just --with-sysroot; it OUGHT to
work, since `$(CC) $(CFLAGS) -print-sysroot` (that is, `gcc
--sysroot=/a/b/c -print-sysroot` should return '/a/b/c', but I'm not
sure about that.)
> But you know better...
Possibly. Possibly not. I do know that I've been participating in this
discussion for months now, and testing multiple libtool patchsets
related to sysroot in dozens of configurations with a handful of cross
compilers on a couple of $build platforms...and you have been silent.
So I have no idea what you do or do not know. All I can go by is what
you've said in this thread.
Which didn't start off well:
"Also, why not take the value of the sysroot from the DESTDIR automake
variable?"
DESTDIR != sysroot. It is similar, but *different*, and behaves in a
different way. (And I'm talking here about how gcc/binutils use the
term; regardless of how libtool addresses the issue). With DESTDIR, you
still have to ensure that your CFLAGS includes
"-I$DESTDIR/$prefix/include" and LDFLAGS includes
"-L$DESTDIR/$prefix/lib". Worse, those paths "leak" into your compiled
results. With sysroot, IF it is done correctly, you shouldn't need to
specify EITHER of those things, since $sysroot/$prefix/{include,lib} is
already IN the (cross)compiler's default search path. So, no leakage;
all you need is to tell the compiler that it ought to use $DESTDIR for
the sysroot. (And, of course, if you use the default sysroot, you don't
need to tell it anything; it'll Just Work(tm)).
What if I wanted to build an SDK for linux->mingw, that a client
(developer) could install in THEIR compiler's (default) sysroot on
linux? I'd need a DESTDIR in /tmp/ where I could "package it up", but
underneath that DESTDIR I'd still need to see both the sysroot and the
prefix:
/tmp/my-build/usr/i686-pc-mingw32/sys-root/mingw/{include,lib,...}
^ ^^^
DESTDIR sysrootprefix (on $host)
Then, I'd create my RPM/deb from /tmp/my-build, so that Sally can
Re: DLL creation and static libs
On 11/2/2010 2:14 AM, Ralf Wildenhues wrote: > OTOH, if the w32 maintainers agree, then we can also give in and allow > linking against static libraries plainly. I tried the trivial patch > (set deplibs_check_method to pass_all) a while ago but that caused a > number of test failures, so somebody would at least have to look into > this issue. the problem is there are TWO different libuuid's. There's the one that is part of the win32 api, and simply contains a number of static objects that represent UUIDs of elements of the Windows OS. [1] Then, there's the unix-derived one that provides routines for *generating* new UUIDs. [2] [1] On cygwin this is /usr/lib/w32api/libuuid.a (On mingw, it's /usr/lib/libuuid.a). In both cases, it IS a static library, not an import library. [2] On cygwin, this is /usr/lib/libuuid.[a,dll.a]. To my knowledge, there is no corresponding element for mingw. So...the special casing is going to be pretty complex, because you don't want to treat cygwin's unix-derived /usr/lib/libuuid* differently than any other library, but mingw's /usr/lib/libuuid.a and cygwin's /usr/lib/w32api/libuuid.a would both need the special treatment. (FYI: we'd also need to add similar logic to binutils' ld, to special case the auto-export). -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: DLL creation and static libs
On 11/3/2010 12:23 PM, Matěj Týč wrote: > On 2 November 2010 13:26, Charles Wilson wrote: >> On 11/2/2010 2:14 AM, Ralf Wildenhues wrote: >> ... >> the problem is there are TWO different libuuid's. There's the one that >> is part of the win32 api, and simply contains a number of static objects >> that represent UUIDs of elements of the Windows OS. [1] Then, there's >> the unix-derived one that provides routines for *generating* new UUIDs. [2] > > I thought of the nm tool. It could be used to identify which library > is which, although AFAIK, it can't be used to generally identify > libraries that contain data only. Is that correct? Well, as long as we're special casing, we can look for a *specific* public read-only data item: nm -B libuuid.a | grep ' R _IID_IUnknown' that should only appear in the w32api version, and not in the unixy one. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined vs gcc 4.6.0
On 3/19/2011 6:25 AM, LRN wrote: > I expect to find a lot of libtool-using projects that will require such > hacks or workarounds, because `unrecognized option '-no-undefined'' is > very common. Ah, but actually -no-undefined should be added by the upstream maintainers, in Makefile.am, to libfoo_la_LDFLAGS. It is a *description* of the library -- which is true regardless of the host platform the library is being built for. It is a claim by the library designer that: "This library, when linked, will not reference any symbols, unless they are defined either in its own source objects or in other explicitly listed dependencies" In order to build a library on win32/cygwin, libtool requires that the library designer assure it of this fact. So, either a library DOES or DOES NOT satisfy the claim: if it doesn't, then it can't be built on windows without massive surgery. If it does, then it does no harm to tell ALL platforms that it does so -- thus, upstream should add -no-undefined to their Makefile.am/libfoo_la_LDFLAGS. This "declaration" is usually NOT passed via an explicit variable statement on the make or configure command line. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library versioning
On 6/16/2011 2:50 PM, Lasse Collin wrote:
> About -version-info vs. -version-number: *If* it turns out that all
> operating systems supported by Libtool should use a versioning style
> that is essentially the same as version_type=linux, could
> -version-number become the recommended option to set the library
> version?
Oh, please god, no. On windows and cygwin, where (a) symlinks can't be
used for DLL resolution, and (b) there is no ld.conf/ld.so to manage
versions, we REALLY depend on a sane numbering system, because it gets
embedded into both the name of the DLL and its clients. (Remember:
unlike the *nix schemes, no redirecting via symbolic links is allowed)
> Major:minor:revision is easier to understand than current:revision:age,
Major:minor:revision artificially entangles package release numbering
with API/ABI changes. Typically when one 'goes up' so does the other,
but not always -- and not by the same increment.
And what if...your package has two different libraries, and only one of
them had an ABI change?
> which in practice is (major+minor):revision:minor.
ONLY if you slavishly follow the one particular scheme for your package
version numbering. I'll point out that linux itself (the kernel)
doesn't follow that scheme. Nor does TeX. And what if you increment
package $major because your *application* has had a major new
functionality addition, AND its command line interface has changed...but
the DLL hasn't changed at all? Why should the DLL soname be changed
just because one of its clients has a new set of cmdline options?
Actually, that particular scheme ('bump major for ABI breaks; bump minor
for significant new features, bump micro for bugfixes') is honored more
in the breach than actually followed...Many projects appear to
(accidentally?) break library ABIs with minorver updates...and sometimes
majorver updates don't modify the ABI at all but simply represent a big
new feature addition -- or a promotion to 'stable' (**)
> Using a scheme that
> is easier to understand would hopefully reduce mistakes in library
> versioning.
No, it just ensures that the version numbers associated with shared
libraries will ALSO be infected with marketing-induced version inflation.
current:revision:age is VERY simple -- if you bother to read the libtool
manual (a tall order, for some project maintainers, I'll grant you).
But the key point is, *library* version numbers should be entirely
unrelated (*) to the *package* version numbers (**).
(*) except in the most vague sense of 'when ones goes up, the other one
might go up too. Maybe.'
(**) Which is why I was mildly annoyed when xz-5.0-final was published,
and included a wholly unnecessary "version bump" from 0:0:0 to 5:0:0.
Granted, it helped *me* out because I was already using 1:0:0 on cygwin
due to an ABI change in the prereleases. Anyway, my annoyance was only
mild, because you had announced that soname plan LONG before the event,
so we were well prepared for it.
--
Chuck
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library versioning
On 6/17/2011 5:26 AM, Lasse Collin wrote: > At that point, Debian had bumped major to 2. Other distros might have > had other versions. If I had tracked the ABI breakages in development > versions, current in -version-info would now be close to a three-digit > number. Probably I wouldn't have remembered to update the version number > on every ABI breakage. So it was much simpler to not track the ABI > breakages until a stable release. FYI, this is actually the recommended approach (at least, during periods rapid development where the API changes a lot, or /between/ official tarball releases of the source). However, I find this "recommended practice" a bit risky, because after three months of development one is likely to /forget/ that patch ae76b23f from six weeks ago changed the API, when it comes to update -version-info and package up the new -src tarball. > People were packaging Git snapshots so incrementing current only for > official releases (to keep version numbers low) wouldn't have worked so > well, although I admit that I made releases far too rarely. There were > ABI breakages between 4.999.9beta and 5.0.0, so even if I were > incrementing the library version only when making a release, I would > have had to increment the version for 5.0.0 anyway. Sure, I get/got that. It's just that, /ideally/, you would have simply incremented to 1:0:0. However, you chose to increment to 5:0:0 for two reasons -- one good, and one somewhat misguided IMO. The good reason: to leave "room" for people like me (cygwin, mingw) and debian, who had been tracking pre-releases and had 'used up' soname 1 and 2 (and possibly more) in addition to the "official" prerelease soname 0. The bad reason: let's jump to soname 5 because the package version number is 5.0. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 3:46 AM, Marco atzeri wrote: > on cygwin > > "lt_cv_deplibs_check_method=pass_all" > > is my workaround at configure stage to bypass incorrect > libtool detection of system capabilities and to allow > shared libs building. It's not about "system capabilities" in this case. It's about the fact that this -- creating a shared library by linking against existing static libraries -- is a really bad idea. If any of those static libs (a) exports a data item, and (b) is used by more than one DLL in your stack, then you'll end up with two different copies of the data item, and one DLL will use the first copy while the other DLL will use the second copy. Similarly, if the static lib even has a private "global" data item (that is, not exposed to clients, but used in common by many of the static lib's API functions), then you end up with the same problem. The first DLL will call one copy of those functions, which modify/access the first instance of this "private global data", while the second DLL will call the second copy of those functions, which modify/access the second instance of this "private global data". Imagine if the data item was a mutex. IIRC elf can put these "static" elements in a .common section of each .so, and the elf loader will consolidate them at runtime. Not so with pe/coff and the windows loader. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 11:03 AM, Marco atzeri wrote: > Sorry Chuck, > but I can assure you that I am linking against shared dlls, > but the detection is incorrect. Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a, and foo-N.dll (plus the -lfoo incantation) you're using for which the detection fails? Maybe we can figure out why func_win32_libid() is failing. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/17/2011 10:19 AM, Vadim Zeitlin wrote: > On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn > wrote: > BF> Most projects using libtool come from Unix/Linux where "auto-import" > BF> is the default so it can be seen that most projects already depend on > BF> it > > My personal experience seems to contradict it. Maybe because auto-import > is relatively recent It was developed back in 2000, and all cygwin and mingw compilers since that date have supported it, EXCEPT for the old msys gcc-2.95.1 toolkit which was used to create *msys* executables up until 2009. > or maybe because most originally Unix projects that > target Windows (meaning not only Cygwin but usually MinGW as well and > sometimes even MSVC) need to fix other Windows-specific issues anyhow and > so do make the relatively small extra effort to add the necessary declspecs > too. This. IF -- and usually ONLY if -- the upstream maintainers have ported to *msvc* FIRST, then they have added the declspec stuff. Then, when it comes to supporting mingw, they have a choice: do things "the unix way" and DON'T activate the declspec stuff and use autoimport instead, OR, do things "the MSVC way". My experience has been that this decision usually goes the win32 way, but a significant fraction go the unix way for mingw. The alternate path is this: the upstream maintainers port to mingw FIRST, and fix the obvious things like using _mkdir(one arg) instead of mkdir(two, args) -- but don't want to "uglify" their headers with declspec. THEN, they port to msvc and are forced to uglify. At that point, they have a new choice: do they retrofit the declspec stuff for their existing mingw build, or not. Most do not. Obviously, packages developed originally on/for windows have the declspec stuff, and usually keep it "turned on" for msvc and mingw. > Anyhow, this is purely anecdotal and it's going to be hard to find an > objective way of determining whether it's the case. True. > A more interesting question is if the current situation with libtool can > be improved because I continue to believe that getting a static library > when you're trying to build a shared one can be very unexpected. And this > can be the case even under Unix where there would be presumably too much > resistance to change the way --disable-static works if it is controversial > even under Windows where I thought it would be "obviously correct". > > So it seems the only solution with any chance of acceptance would be to > add a different option doing what I want, e.g. --enable-shared-only. Or > maybe allow --enable-shared=(yes|no|only)? No, I think --disable-static, if specified, should actually *disable static*. That should be sufficient. If it's not doing that, then it's a bug IMO. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/20/2011 3:32 AM, Marco atzeri wrote: > Hi Chuck, > I guess func_win32_libid() is not failing but the gcc/linker is > smarter than libtool expect; or that autoconf is misleading libtool. > /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a > /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a > /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.la > /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.a > /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la > > libgfortran is available as dynamic and static, > while libgfortranbegin is only static > > libgfortranbegin.a is included as object in the build > of the dll/exe, while libgfortran.dll.a is used > for the linking with cyggfortran-3.dll Hm. This is a big, general problem: it means you libtool can't build ANY fortran DLLs -- because they will all need libfortranbegin.a IIRC, the fortran startup object used to be *an object*, so it didn't trigger this problem. We're really collecting more and more reasons to rewrite the support in libtool for the gcc compiler to just use $(CC) (or $CXX, etc) to link, and NOT muck around with detecting all these objects and compiler runtime libs and crud -- which we currently do so that libtool can link using $(LD) directly. Now, even if we DID do that, it won't "fix" the problem below: > Similar thing happens for the few libraries > that are available only as static like SuiteSparse > > checking for ccolamd in -lccolamd > result: yes > > so > CCOLAMD_LIBS = -lccolamd > > But Suitesparse libs are only static: > /usr/lib/libamd.a > /usr/lib/libbtf.a > /usr/lib/libcamd.a > /usr/lib/libccolamd.a > /usr/lib/libcholmod.a > /usr/lib/libcolamd.a > /usr/lib/libcsparse.a > /usr/lib/libcxsparse.a > /usr/lib/libklu.a > /usr/lib/libspqr.a > /usr/lib/libumfpack.a > > so they are included as objects in the dll build. Well, in this case, libtool is doing what it is programmed to do: don't allow DLLs to depend on static libs. As I said earlier, this is in general a good rule for win32. You've found a case where this heuristic fails, and violating it does not /appear/ to cause any problems for this particular application. I think, in this case, overriding the autoconf variable as you are doing is actually the right procedure! I'm leery of making this a configure option (--allow-static-deps) because then the uninitiated might use it all the time...and invariably they WILL run into the problems I warned about. > For your notice, building octave with > "lt_cv_deplibs_check_method=pass_all" > works fine and the program pass all the tests, > while without it the program is unusable. But we still have the problem with fortran DLLs in general. Sigh. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/21/2011 8:29 AM, Vadim Zeitlin wrote: > Charles Wilson writes: >> No, I think --disable-static, if specified, should actually *disable >> static*. That should be sufficient. >> >> If it's not doing that, then it's a bug IMO. > > Just to confirm: no, currently it doesn't do this. The example of my > original message came from libxml2 build configured with --disable-static. > > So should I try to create a patch making libtool fail in this case? I think so. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On 6/23/2011 11:03 AM, Vadim Zeitlin wrote: > On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn > wrote: > > BF> On Thu, 23 Jun 2011, Vadim Zeitlin wrote: > BF> > > BF> > I.e. it created a shared library with undefined symbols without any > BF> > problems because it never actually passed -no-undefined to g++/ld. > BF> > BF> In actual practice, it seems difficult or impossible to build programs > BF> under systems like Linux with -no-undefined. > > I didn't know this but doesn't this make the situation even worse? I.e. > because of the above you can't even recommend people to use -no-undefined > by default. So the default behaviour will remain the current one, i.e. no > DLLs at all under Windows. No, what it means is that, IF the project maintainers want to support shared libraries (DLLs) on win32, then they must do the following -- and this is true regardless of whether libtool is involved. 1) Ensure that when building for win32, that the various object files that will be combined into the DLL, as well as the library dependencies (-lwhatever) are such that there WILL BE no undefined symbols, at least *when building for win32*. Otherwise, ld will refuse to create the DLL. This may involve restructuring the code, and possibly changing the division of labor between various DLLs if your project has multiple interdependent ones. It is *very* difficult to build stuff on win32 where you have circular dependencies between DLLs, or between DLLs and an EXE -- not impossible, just very difficult. (*) Now, if you are going to go thru all that trouble to support win32...you'd just be making a lot of extra work for yourself to maintain TWO separate library structures -- one for win32 (and, btw, AIX) where everything is "no undefined symbols" clean, and one for everything else where undefined symbols are allowed. So...most projects that end up in this place (**), finally decide to restructure their shared libraries for *ALL* platforms. Notice I haven't said anything about libtool yet. 2) Once you've gone thru the exercise in #1, now you might as well add -no-undefined unconditionally to your libtool invocation -- if you are using libtool, that is. Remember, all the stuff in #1 is required just to build DLLs on win32 *at all*, libtool or no libtool. (*) You basically have to create an export file for DLL A (or the EXE), and an import lib for it. THEN, you can build DLL B as normal, and specify -lDLLA (or -lEXE). Finally, you build the "real" DLL A (or EXE), and specify -lDLLB. Libtool has /no/ direct mechanism to support this. (**) Except for those that use a "plugin" architecture, where the plugin DLLs *must* be able to call back to the EXE. That's really tricky, and they usually end up using another solution, of which there are several (see http://edll.sourceforge.net/ for a good description of several different approaches). But that's outside the scope of our discussion here. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
On 10/25/2011 6:51 AM, Gary V. Vaughan wrote: > Do you forsee any issues on Windows with my doing that? Yes. > I'm almost certain that modern gcc and hence cygwin and variants will > continue to work correctly without LT_SCOPE, LTDL_DLL_IMPORT and friends, > but I have no clue whether vendor compilers that currently work (or at > least are supported and supposed to work) with the current release are > relying on LT_SCOPE magic from libltdl. Modern gcc will be fine on cygwin, mingw, and mingw64. What will break completely is any version of Visual Studio, including 2010 -- which I'm fairly sure is not a "museum piece." It would be a shame to obviate all of Peter's work getting libtool itself to work with MSVC, and then to break that platform's libltdl.dll. But I'll let Peter take point on this one. -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
On 10/25/2011 11:03 AM, Peter Rosin wrote: > Gary V. Vaughan skrev 2011-10-25 14:17: > I configures both the way I usually configure libtool for msvc, i.e. > > ../configure autobuild_mode=msvc CC="/c/cygwin/home/peda/automake/lib/compile > cl" CFLAGS="-MD -Zi -EHsc" CXX="/c/cygwin/home/peda/automake/lib/compile cl" > CXXFLAGS="-MD -Zi -EHsc" LD=link NM="dumpbin -symbols" STRIP=: > AR="/c/cygwin/home/peda/automake/lib/ar-lib lib" RANLIB=: F77=no FC=no GCJ=no > > The testsuite result seems identical, with two good old failures: Be sure and check the exports from libltdl*.dll from and ... -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Obsoleting LT_SCOPE
On 10/25/2011 11:51 AM, Gary V. Vaughan wrote: I have to bow to your superior knowledge of Windows, which I haven't used for development since Windows NT 4, but it feels weird that Libltdl really does twist itself into a pretzel for Windows... and yet all the other GNU projects I've looked at do no such thing (possibly because I haven't yet found another one that can be compiled with MSVC). Well, a couple of points: #1, libltdl is not normal: unlike most libraries, we provide explicit support for (a) linking externally, (b) incorporating as a subproject and linking locally (separate ./configure), and (c) incorporating as a submodule(?) and linking locally (combined ./configure). Very few other libraries support any such thing OOB. #2, I can think of one other GNU projects that support similar sub-inclusion: libintl. And /that/ library, and its cousin libiconv, also twist themselves into giant pretzels for Windows -- even moreso than libltdl. Bruno invented a whole new method of linking! http://www.haible.de/bruno/woe32dll.html BTW: one possible solution to this whole conundrum is to adopt Bruno's method [*], which works for both MSVC and gcc. The idea is to *always* declare "exported" symbols as declspec(dllimport), even when linking against the static library. The trick is, some additional build steps when building the library itself, to add the requisite "import" thunks to the static lib. See the URL above for more info. FWIW, Bruno has long said that this method would "work better" with "just a few additional lines of code in libtool". However, as he's never actually posted just WHAT those additional lines of code would BE, I've been at a loss to move forward. That's been the status now for several years (not really high on my priority list). [*] without the -Wl,--disable-auto-import -- Chuck ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool
Eric Blake wrote: Working around the problem isn't hard, just comment out the offending rm line in Libtool's ltmain.sh, Which line? Since you already found the culprit, pointing others to the location would be helpful. Can you come up with a simple libtool patch? I know where. Actually, I'd prefer to keep the rm, if there is a mechanism to say "rm foo but NOT foo.exe". Does the "rm -f foo." trick still work to specify "foo without any extension and I really mean it." (I'd check, but I'm still using older cygwin kernel/older coreutils at the moment...) -- Chuck cygwin libtool maintainer ___ http://lists.gnu.org/mailman/listinfo/libtool
branch 2.0, make install DESTDIR=
is broken -- at least on cygwin, but probably everywhere.
( cd ../libltdl && /bin/sh
/usr/src/libtool/devel/CVS/libtool-b2.0/config/missing --run tar chf -
COPYING.LIB README Makefile.am Makefile.in argz_.h argz.c configure.ac
configure libltdl/lt__alloc.h libltdl/lt__dirent.h libltdl/lt__glibc.h
libltdl/lt__private.h libltdl/lt__strl.h libltdl/lt_dlloader.h
libltdl/lt_error.h libltdl/lt_system.h libltdl/slist.h
loaders/dld_link.c loaders/dlopen.c loader
s/dyld.c loaders/load_add_on.c loaders/loadlibrary.c loaders/preopen.c
loaders/shl_load.c lt__alloc.c lt__dirent.c lt__strl.c lt_dlloader.c
lt_error.c ltdl.c ltdl.h slist.c; ) \
| ( umask 0 && cd
/usr/src/libtool/devel/CVS/libtool-b2.0/.inst/usr/local/share/libtool/libltdl
&& /bin/sh /usr/src/libtool/devel/CVS/libtool-b2.0/config/missing --run
tar xf -; )
tar: configure: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
tar: configure: Cannot stat: No such file or directory
tar: Error exit delayed from previous errors
chown -R root
/usr/src/libtool/devel/CVS/libtool-b2.0/.inst/usr/local/share/libt
ool/libltdl && \
chgrp -R root
/usr/src/libtool/devel/CVS/libtool-b2.0/.inst/usr/local/share/libt
ool/libltdl || :
chown: `root': invalid user
chmod +x
/usr/src/libtool/devel/CVS/libtool-b2.0/.inst/usr/local/share/libtool/config.guess
chmod: cannot access
`/usr/src/libtool/devel/CVS/libtool-b2.0/.inst/usr/local/share/libtool/config.guess':
No such file or directory
(A) cross-platform? There is no configure script in $SRCDIR/libltdl --
although there is a configure.ac. This looks like some disagreement
over whether libltdl is a sub-configure'd project or configured directly
as part of the overall libtool's configure.
(B) cygwin-specific: There is no root user. There might be a SYSTEM
user which is somewhat similar, and Administrator which is somewhat
similar in other ways -- but regardless there is no facility to do CHOWN
unless you're building as Administrator (not SYSTEM). Basically, this
whole chown idea in libtool's installation is fscked-up w.r.t. cygwin.
(C) ${instdir}/usr/local/share/libtool/config.guess doesn't exist
because it's actually called
${instdir}/usr/local/share/libtool/config/config.guess
Does anybody TEST this stuff before checking it in?
--
Chuck
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: branch 2.0, make install DESTDIR=
Ralf Wildenhues wrote: (B) cygwin-specific: There is no root user. There might be a SYSTEM user which is somewhat similar, and Administrator which is somewhat similar in other ways -- but regardless there is no facility to do CHOWN unless you're building as Administrator (not SYSTEM). Basically, this whole chown idea in libtool's installation is fscked-up w.r.t. cygwin. OK. Does `id -u' tell you whether you are SYSTEM (id 0?) or not? What would be an appropriate solution for cygwin? Please also note that discussion about how to resolve this best is still going on[1]. I'm sorry that this caught you. It should not have been the cause for the installation failure (except for the annoying but harmless warning messages), though. I think you'd want to try to chown to UID 18 (SYSTEM), but the euid of the process running the install will not be 18. It'll Administrator (local machine, not member of Windows Domain) == 500, or Administrator (local machine, but machine is member of domain) == 10500 (unless the "domain member offset" has been changed to something other than 1). Or it might be J.Q.RandomUser with Administrator privileges. Or a Domain Administrator account. etc. I guess what it boils down to, is on cygwin you should attempt to chown to 18, but ignore failure, because there's no good way to tell if it's going to work other than simply to try it. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
RE: Libtool API suggestion: LTDL_SHLIB_PRE and/or char*ltdl_map_shared_n
* Alexandre Oliva wrote on Thursday, September 08, 2005 22:13 CEST: > On Aug 23, 2005, Albert Chin <[EMAIL PROTECTED]> wrote: > I don't know of > any linker that searches for say foo.a when given -lfoo. Uhm, how about ld? 'info ld' reveals... For instance, when ld is called with the argument `-lxxx' it will attempt to find, in the first directory of its search path, libxxx.dll.a xxx.dll.a libxxx.a cygxxx.dll (*) libxxx.dll xxx.dll before moving on to the next directory in the search path. (*) Actually, this is not `cygxxx.dll' but in fact is `xxx.dll', where `' is set by the `ld' option `--dll-search-prefix='. In the case of cygwin, the standard gcc spec file includes `--dll-search-prefix=cyg', so in effect we actually search for `cygxxx.dll'. Note that since ld on windowsish platforms can link directly to the shared lib (cygxxx.dll, libxxx.dll, or xxx.dll) instead of using an import lib (libxxx.dll.a), it is certainly legal for the developer to specify '-lfoo' and expect to successfully link against foo.dll. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool-HEAD, 20051007, cygwin
I ran into an oddity with 'make dist' recently: I bootstrapped, compiled, and ran the testsuite[*] on libtool cvs HEAD and got the expected results (see attached). I then did a 'make dist' (after hand-editing the top-level Makefile to remove references to fcdemo, as I do not have f90 installed). Then, using the dist tarball, I repeated the process (build, run testsuite). [*] In both of the cases described, I always build and run the testsuite outside of the srcdir. I have followed this procedure before with no unexpected occurances -- that is, running the testsuite in the build environment from the tarball produced equivalent results as running the testsuite in the build environment generated by the cvs working dir. However, this time, the tarball-derived environment failed a number of the "new" tests (see attached): Libtool's subdir-objects support. 15: C subdir-objects FAILED 16: C++ subdir-objects FAILED Standalone Libltdl. 17: compiling softlinked libltdl FAILED 18: compiling copied libltdl FAILED 19: installable libltdl FAILED 20: linking libltdl without autotoolsok Subproject Libltdl. 21: compiling softlinked libltdl FAILED 22: compiling copied libltdl FAILED 23: installable libltdl FAILED 24: linking libltdl without autotoolsok I can only conclude that something is screwy with regards to 'make dist'. (FWIW, I'm using autoconf-2.59 and automake-1.9.6, with the libobj patch from http://lists.gnu.org/archive/html/libtool/2005-08/msg00093.html) -- Chuck make check-recursive make[1]: Entering directory `/usr/src/libtool/cvs/libtool-HEAD/_build' rm -f tests/defs.tmp tests/defs; \ input="defs.m4sh"; \ sed -e 's,@EGREP\@,grep -E,g' -e 's,@FGREP\@,grep -F,g' -e 's,@GREP\@,grep,g' -e 's,@LN_S\@,ln -s,g' -e 's,@MACRO_VERSION\@,2.1a,g' -e 's,@PACKAGE\@,libtool,g' -e 's,@PACKAGE_BUGREPORT\@,bug-libtool@gnu.org,g' -e 's,@PACKAGE_NAME\@,libtool,g' -e 's,@PACKAGE_STRING\@,libtool 2.1a,g' -e 's,@PACKAGE_TARNAME\@,libtool,g' -e 's,@PACKAGE_VERSION\@,2.1a,g' -e 's,@SED\@,/usr/bin/sed,g' -e 's,@VERSION\@,2.1a,g' -e 's,@aclocaldir\@,/usr/share/aclocal,g' -e 's,@datadir\@,/usr/share,g' -e 's,@pkgdatadir\@,/usr/share/libtool,g' -e 's,@host_triplet\@,i686-pc-cygwin,g' -e 's,@prefix\@,/usr,g' -e "s,@configure_input\@,Generated from $input; do not edit by hand,g" /usr/src/libtool/cvs/libtool-HEAD/tests/defs.in > tests/defs.tmp; \ mv -f tests/defs.tmp tests/defs make[2]: Entering directory `/usr/src/libtool/cvs/libtool-HEAD/_build' make check-TESTS check-local make[3]: Entering directory `/usr/src/libtool/cvs/libtool-HEAD/_build' PASS: tests/link.test PASS: tests/link-2.test PASS: tests/nomode.test PASS: tests/objectlist.test PASS: tests/quote.test PASS: tests/sh.test PASS: tests/suffix.test PASS: tests/tagtrace.test PASS: tests/cdemo-static.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-static.test PASS: tests/demo-make.test PASS: tests/demo-exec.test PASS: tests/demo-inst.test PASS: tests/demo-unst.test PASS: tests/depdemo-static.test PASS: tests/depdemo-make.test PASS: tests/depdemo-exec.test PASS: tests/depdemo-inst.test PASS: tests/depdemo-unst.test PASS: tests/mdemo-static.test PASS: tests/mdemo-make.test PASS: tests/mdemo-exec.test PASS: tests/mdemo-inst.test PASS: tests/mdemo-unst.test PASS: tests/cdemo-conf.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-conf.test PASS: tests/demo-make.test PASS: tests/demo-exec.test PASS: tests/demo-inst.test PASS: tests/demo-unst.test PASS: tests/demo-deplibs.test PASS: tests/depdemo-conf.test PASS: tests/depdemo-make.test PASS: tests/depdemo-exec.test PASS: tests/depdemo-inst.test PASS: tests/depdemo-unst.test PASS: tests/mdemo-conf.test PASS: tests/mdemo-make.test PASS: tests/mdemo-exec.test PASS: tests/mdemo-inst.test PASS: tests/mdemo-unst.test PASS: tests/mdemo-dryrun.test PASS: tests/mdemo2-conf.test PASS: tests/mdemo2-make.test PASS: tests/mdemo2-exec.test PASS: tests/pdemo-conf.test PASS: tests/pdemo-make.test PASS: tests/pdemo-exec.test PASS: tests/pdemo-inst.test PASS: tests/demo-nofast.test PASS: tests/demo-make.test PASS: tests/demo-exec.test PASS: tests/demo-inst.test PASS: tests/demo-unst.test PASS: tests/depdemo-nofast.test PASS: tests/depdemo-make.test PASS: tests/depdemo-exec.test PASS: tests/depdemo-inst.test PASS: tests/depdemo-unst.test PASS: tests/demo-pic.test PASS: tests/demo-make.test PASS: tests/demo-exec.test PASS: tests/demo-nopic.test PASS: tests/demo-make.test PASS: tests/demo-exec.test PASS: tests/cdemo-shared.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-shared.test PASS: tests/demo-make.test PASS: tests/demo-exec.test PASS: tests/demo-inst.test PASS: tests/demo-hardcode.test PASS: tests/demo-relink.test PAS
Re: libtool-HEAD, 20051007, cygwin
Ralf Wildenhues wrote: Please post tests/testsuite.log containing the failures (packed?). I cannot reproduce this on GNU/Linux (and you posting should be less work than me trying to reproduce it on cygwin :) attached. -- Chuck testsuite.log.bz2 Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool-HEAD, 20051007, cygwin
Ralf Wildenhues wrote: Index: tests/testsuite.at === RCS file: /cvsroot/libtool/libtool/tests/testsuite.at,v retrieving revision 1.26 diff -u -r1.26 testsuite.at --- tests/testsuite.at 11 Oct 2005 16:51:50 - 1.26 +++ tests/testsuite.at 11 Oct 2005 19:19:49 - @@ -94,7 +94,7 @@ # -- m4_define([LT_AT_MAKE], [( $unset LIBTOOL LIBTOOLIZE - AT_CHECK([$2 $MAKE -e $1], [0], [ignore], [ignore]) ) + AT_CHECK([$MAKE $1 $2], [0], [ignore], [ignore]) ) ]) Yep, with this change, I re-ran the 'new' tests in the tarball-derived build directory, and got the same results (28 pass, 1 skip, 1 expected failure) as I had originally seen in the build directory created directly from the CVS working dir. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Unhelpful behaviour on Cygwin when "file" isn't installed
Olly Betts wrote:
Does the cygwin packaging chooser have the concept of dependencies?
Yes.
I've only used it briefly once some time ago, and I can't remember
much about it. But if it does, then libtool should really depend on
file.
The official libtool package for cygwin (e.g. the one you get if you
select 'libtool' in the cygwin installer) DOES in fact depend on 'file'.
That package is called "libtool1.5-1.5.20-2" (hard to miss, because
there is no other libtool in the official distro).
However, you mentioned that your user was using "libtool-1.5.22".
Therefore, I conclude that your user did not use the cygwin setup.exe
program to install libtool -- he apparently installed some third-party
version of libtool (yours?) or built his own. I have no idea how any
third-party provider handles their dependencies nor can I worry if some
end-user compiled libtool and expected it to work, but didn't bother to
run libtool's own testsuite to make sure ('cause libtool-sans-'file'
would bomb the tests, bigtime).
I can only control the libtool that *I* distribute as part of the
official cygwin system. *It* is already marked as requiring 'file', and
a normal cygwin installation of official cygwin-provided tools (incl.
libtool1.5-1.5.20-2) using the cygwin setup.exe program WOULD have
automatically included 'file'.
--
Chuck
cygwin/libtool maintainer
___
http://lists.gnu.org/mailman/listinfo/libtool
export_symbols_cmds erroneously expanded
When building pcre (which uses libtool --export-symbols-regex) I get the following error (libtool cvs branch 1.5, 20061014 checkout): /bin/sh ./libtool --mode=link gcc -export-symbols-regex '^[^_]' -I. -I/c/msys/1.0/local/src/pcre/cygports/pcre-6.7-1/src/pcre-6.7 -rpath /usr/lib -no-undefined -version-info \ '0:1:0' -o libpcre.la pcre_chartables.lo pcre_compile.lo pcre_config.lo pcre_dfa_exec.lo pcre_exec.lo pcre_fullinfo.lo pcre_get.lo pcre_globals.lo pcre_info.lo pcre_maketables.lo pcre_ord2utf8.lo pcre_refcount.lo pcre_study.lo pcre_tables.lo pcre_try_flipped.lo pcre_ucp_searchfuncs.lo pcre_valid_utf8.lo pcre_version.lo pcre_xclass.lo generating symbol list for `libpcre.la' /usr/bin/nm -B .libs/pcre_chartables.o .libs/pcre_compile.o .libs/pcre_config.o .libs/pcre_dfa_exec.o .libs/pcre_exec.o .libs/pcre_fullinfo.o .libs/pcre_get.o .libs/pcre_globals.o .libs/pcre_info.o .libs/pcre_maketables.o .libs/pcre_ord2utf8.o .libs/pcre_refcount.o .libs/pcre_study.o .libs/pcre_tables.o .libs/pcre_try_flipped.o .libs/pcre_ucp_searchfuncs.o .libs/pcre_valid_utf8.o .libs/pcre_version.o .libs/pcre_xclass.o | sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][ ]*_\([_A-Za-z][_A-Za-z0-9]*\)$/\1 _\2 \2/p' | /usr/bin/sed -e '/^[BCDGRS] /s/. /s/.. \([^ ]*\)/\1 DATA/' | /usr/bin/sed -e '/^[AITW] /s/. /s/.. //' | sort | uniq > .libs/libpcre.exp /usr/bin/sed: -e expression #1, char 20: unknown option to `s' /usr/bin/sed: -e expression #1, char 18: unknown option to `s' /usr/bin/grep -E -e "^[^_]" ".libs/libpcre.exp" > ".libs/libpcre.expT" The two offending sed expressions are: '/^[BCDGRS] /s/. /s/.. \([^ ]*\)/\1 DATA/' '/^[AITW] /s/. /s/.. //' These *should* have been '/^[BCDGRS] /s/.* \([^ ]*\)/\1 DATA/' '/^[AITW] /s/.* //' It appears that around line 3978 in ltmain.in: cmds=$export_symbols_cmds save_ifs="$IFS"; IFS='~' for cmd in $cmds; do IFS="$save_ifs" [[ cmd ok here , but $NM etc are not expanded ]] eval cmd=\"$cmd\" [[ cmd not ok here -- $NM etc are expanded, but s/// expression messed up ]] if len=`expr "X$cmd" : ".*"` && test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then $show "$cmd" $run eval "$cmd" || exit $? skipped_export=false else bad things are happening to the .* in the original s/// expressions. I tried umpteen ways of changing the quotes but couldn't seem to get libtool to DTRT, short of introducing another variable for an extra level of indirection (similar to how global_symbol_pipe itself is handled): # The commands to list exported symbols. export_filter="sed -e '/^[BCDGRS] /s/.* \\([^ ]*\\)/\\1 DATA/' | sed -e '/^[AITW] /s/.* //'" export_symbols_cmds="\$NM \$libobjs \$convenience | \$global_symbol_pipe | \$export_filter | sort | uniq > \$export_symbols" (We can't change global_symbol_pipe itself, because it's used in other contexts). There's also the (uglier, but less invasive -- doesn't require a new _LT_TAG_VAR for each tag): # The commands to list exported symbols. export_symbols_cmds="DOTSTAR='.*'~\$NM \$libobjs \$convenience | \$global_symbol_pipe | \$SED -e '/^[BCDGRS] /s/\$DOTSTAR ([^ ]*)/1 DATA/' | \$SED -e '/^[AITW] /s/\$DOTSTAR //' | sort | uniq > \$export_symbols" Any ideas what the RIGHT fix for this problem is? -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: export_symbols_cmds erroneously expanded
On Mon, 11 Dec 2006 18:36:56 +0100, "Ralf Wildenhues" <[EMAIL PROTECTED]> said: > Hello Charles, > > Thanks for the bug report. > > > [[ bug report and export_filter variable "fix" snipped ]] > > The above looks like a cleaner approach to me than the second one you > offer; but it means we'd need to change the definition of > export_symbols_cmds for each and every system, not just Cygin/MinGW. Yes, I figured that. I believe it would also be true for the other solution, as well. The problem is we need to expand *part* of cmd, but not *all* of it -- and this is true on every system and every tag, including the default definition of export_symbols_cmds. > (There is no need for two sed scripts here, by the way, one would be > just fine.) That particular expression is already written as two sed invokations; merging to one invokation would be fine, but since that's not germane to the problem here I didn't bother. > Another thing that worries me is I'm pretty certain the use of > export_symbols_cmds in the too-many-objects case will cause another, > differently-looking failure. IOW, tests for both use cases are needed. You're probably right. > I can look into this in a couple of days probably. Cool -- I'd appreciate your efforts [*]. I'm going to go ahead, for cygwin, and do a quickie release of 'libtool1.5-1.5.23a-2' (still branch 1.5, still 20061014 checkout) but with your --version patch (http://lists.gnu.org/archive/html/libtool/2006-12/msg00015.html) and the quick-n-dirty DOTSTAR "fix" for this bug assuming it passes the testsuite (as well as 1.5.23a-1 did). [Why? Cause it works, and I personally need a properly symbol-exported pcre Right Now...] [*] I'm a bit daunted by the prospect of adding a new LT_TAG_VAR variable -- I'm not sure what all the ramifications are and I'm afraid I'll miss some fiddly little but critically necessary item to 'make it all work' -- which is why I'm happy to leave this to an expert. But I'll be glad to test any patch you generate... Then I'll update cygwin's official release to a new -D date on branch 1.5 with your changes. Cruddy DOTSTAR patch attached -- Chuck diff -urN origsrc/libtool/libtool.m4 src/libtool/libtool.m4 src/libtool/libtool.m4 --- origsrc/libtool/libtool.m4 2006-08-25 11:04:54.0 -0400 +++ src/libtool/libtool.m4 2006-12-11 12:22:29.921833600 -0500 @@ -5440,7 +5440,7 @@ AC_DEFUN([AC_LIBTOOL_PROG_LD_SHLIBS], [AC_MSG_CHECKING([whether the $compiler linker ($LD) supports shared libraries]) ifelse([$1],[CXX],[ - _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols' + _LT_AC_TAGVAR(export_symbols_cmds, $1)='DOTSTAR='\''.*'\''~$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/$DOTSTAR //'\'' | sort | uniq > $export_symbols' case $host_os in aix4* | aix5*) # If we're using GNU nm, then we don't want the "-C" option. @@ -5455,10 +5455,10 @@ _LT_AC_TAGVAR(export_symbols_cmds, $1)="$ltdll_cmds" ;; cygwin* | mingw*) -_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]] /s/.* \([[^ ]]*\)/\1 DATA/;/^.* __nm__/s/^.* __nm__\([[^ ]]*\) [[^ ]]*/\1 DATA/;/^I /d;/^[[AITW]] /s/.* //'\'' | sort | uniq > $export_symbols' +_LT_AC_TAGVAR(export_symbols_cmds, $1)='DOTSTAR='\''.*'\''~$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]] /s/$DOTSTAR \([[^ ]]*\)/\1 DATA/;/^.* __nm__/s/^$DOTSTAR __nm__\([[^ ]]*\) [[^ ]]*/\1 DATA/;/^I /d;/^[[AITW]] /s/$DOTSTAR //'\'' | sort | uniq > $export_symbols' ;; *) -_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols' +_LT_AC_TAGVAR(export_symbols_cmds, $1)='DOTSTAR='\''.*'\''~$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/$DOTSTAR //'\'' | sort | uniq > $export_symbols' ;; esac ],[ @@ -5483,7 +5483,7 @@ _LT_AC_TAGVAR(module_cmds, $1)= _LT_AC_TAGVAR(module_expsym_cmds, $1)= _LT_AC_TAGVAR(always_export_symbols, $1)=no - _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/.* //'\'' | sort | uniq > $export_symbols' + _LT_AC_TAGVAR(export_symbols_cmds, $1)='DOTSTAR='\''.*'\''~$NM $libobjs $convenience | $global_symbol_pipe | $SED '\''s/$DOTSTAR //'\'' | sort | uniq > $export_symbols' # include_expsyms should be a list of space-separated symbols to be *always* # included in the symbol list _LT_AC_TAGVAR(include_expsyms, $1)= @@ -5594,7 +5594,7 @@ _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported _LT_AC_TAGVAR(always_export_symbols, $1)=no _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=yes - _LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]] /s/.* \([[^ ]]*\)/\1 DATA/'\'' | $SED -e '\''/^[[AITW]] /s/.* //'\'' | sort | uniq > $ex
Re: export_symbols_cmds erroneously expanded
On Tue, 12 Dec 2006 01:03:41 +0100, "Ralf Wildenhues" said > Or we need to make sure the extra expansion does not matter. > Arguably, this is a hack, but in practice it may be enough for now. > I had to create a directory /s to expose the bug -- do you have an > S: drive? Hmm. As a matter of fact, I do. On cygwin, I guess you'd only see this problem if you've explicitly done $ mkdir /s $ mount S: /s (which I have) or $ mount --change-cygdrive-prefix / (which I have not) However, you'd always get this bug under MSys/mingw. > > Please try this patch. Ookay, but: you're still expanding the value of cmd. You're just hoping that, for $PLATFORM, the value of export_symbols_cmds contains nothing that might expand to a directory/file list on the current machine. E.g. on unix, if there were an 's' directory in the root /, you'd also need some version of the patch below -- but in a different spot in libtool.m4. Anyway, testing will have to wait a few hours. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: export_symbols_cmds erroneously expanded
On Tue, 12 Dec 2006 01:03:41 +0100, "Ralf Wildenhues" <[EMAIL PROTECTED]> said: > Please try this patch. > > Cheers, > Ralf > > * libtool.m4 (AC_LIBTOOL_PROG_LD_SHLIBS) [ cygwin, mingw ] > : Avoid shell expansion of '/s/.*' through > double expansion, in case there is a 'S:' drive. > Report by Charles Wilson. Yep, that fixes the problem too: tested on both cygwin and mingw. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
[cygwin] Analysis for new testsuite failures 33,34.35
In this message: http://lists.gnu.org/archive/html/libtool-patches/2007-03/msg00030.html I mentioned that I had observed three new failures in the testsuite: 33,34,35: new regressions in CVS between 20070205 and 20070316 I think the CVS dates are a red herring. The error message in testsuite.log is -- well actually, the following is taken from a run of $ make check-local TESTSUITEFLAGS='-x -v -d 33' === ... ../../libtool-HEAD/tests/subproject.at:56: $MAKE all $tst_dist + make all dist stderr: /usr/share/aclocal/pstoedit.m4:7: warning: underquoted definition of AM_PATH_PSTOEDIT run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/share/aclocal/libmcrypt.m4:17: warning: underquoted definition of AM_PATH_LIBMCRYPT libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries mkdir: cannot create directory `/usr/src/libtool/cvs/_build/tests/testsuite.dir/33/subproject-demo-2.1a/sub/ltdl': File exists make[2]: *** [distdir] Error 1 make[1]: *** [distdir] Error 1 ... === The actual problem is a bug in automake-1.9.6, because these tests all pass under the following conditions: (1) force libtool bootstrap using automake-1.10 (by changing configure.ac, ensuring beyond doubt that the 'automake' and 'aclocal' in use are automake-1.10 and aclocal-1.10, rebuild, and run the tests (2) or use plain old automake-1.9.6, but with the following change backported from automake-1.10: distdir.am: @@ -50,7 +50,7 @@ ## if %?TOPDIR_P% $(am__remove_distdir) - mkdir $(distdir) + test -d $(distdir) || mkdir $(distdir) endif %?TOPDIR_P% ## ## It's because in the recursive call, am__remove_distdir is redefined to ':' -- specifically because we do not want to rm-rf it within the recursion. But without the above change, plain mkdir fails because the target already exists. Now, I'm not sure how to "solve" this problem: I don't know what the policy is on the required version of automake for libtool-HEAD, but I'm pretty sure it isn't "require 1.10". But I also don't know if automake-1.9.x is still under development, and would accept the above backport for some future automake-1.9.7 release. Ideas? -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
[RFC] New library "type" needed?
The problem: === Currently, libtool supports several types of libraries (I'm glossing over some stuff here, be gentle): (1) Normal shared libraries (2) Normal static libraries (3) Convenience libraries (a) non-PIC -- will eventually be "exploded" and subsumed into a normal static library, or used by an in-project executable (b) PIC -- will eventually be included into a normal shared library via '--whole-archive libfoo --no-whole-archive' or something similar; or perhaps included in a PIE executable(?). (4) Modules (a) shared (b) static, dlpreopen As far as I can tell, none of these types satisfy the following need -- and perhaps this "need" is win32-specific; I'm not sure. I have a library that I want to build shared (let's call it "libbfd"). It depends on a portability library that is currently built as a non-libtool, static library (let's call it "libiberty"). Now, it's bad to included non-PIC objects in a shared library (defer discussion of the meaning of "PIC" on win32 'til later, but consider the patch under consideration to add "real" -fpic support: [PATCH,i386][4.3][RFC] PIC Generation on windows/cygwin http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00855.html So, mindful of this, on non-win32 platforms the libiberty machinery manually builds a static archive of PIC .o's and a different static archive of non-PIC .o's. I modified the build machinery to do this also on win32. However, libtool can't tell the difference -- and, _currently_ on win32 there really is no difference -- so it rejects building libbfd shared, because "you can't build a shared library that depends on a static library". So, next, I dug up an old (Oct 2004) patch that built libiberty using libtool. That patch went thru several iterations trying to deal with multilib support that was lacking in the ancient libtool, before finally being withdrawn. Since I am currently experimenting with Steve Elcey's recent work Updating libtool in GCC and srctree http://gcc.gnu.org/ml/gcc/2007-03/msg00293.html bringing in modern libtool, I expect those old difficulties may no longer apply...but that's an issue for later. One other thing the 2004/10 patch did was AFTER building with libtool, it removed the actual libtool libs and created its own .a's using the libtool-built .o's. I didn't keep THAT part of the old patch; I wanted actual libtool libraries. However, this led to another problem: depending on whether I libtool-link using -rpath or not, I get either: (1) two convenience libs, on with "PIC" .o's and the other with "non-PIC" .o's, or (2) an actual shared cygiberty-0.dll and a "normal" static libiberty.a In the first case, here's what happens when I try to build libbfd with -liberty using libtool (1a) the static libbfd gets all of the objects of the static libiberty.a convenience lib included within it. This is bad because I really don't want libbfd to have those symbols. (1b) the shared libbfd ALSO gets all of the objects from the shared libiberty.a convenience lib, and auto-exports all of those symbols. This is also bad -- I want to use libiberty to satisfy internal undefined symbols within libbfd, but do not want to export those symbols OUTSIDE of libbfd. I tried adding -Wl,--exclude-libs -Wl,libiberty.a to libbfd_LDFLAGS, and that actually worked...but (i) it is not at all portable (ii) requires me to know that the convenience library name is exactly "libiberty.a", rather than relying on libtool knowing how to translate "-liberty" -> "libiberty.la" -> "(whatever)" (iii) confusing: the actual link command includes both -Wl,--exclude-libs -Wl,libiberty.a AND -Wl,--whole-archive libiberty.a -Wl,--no-whole-archive So I'm still including all of the objects in libiberty within libbfd, even though I'm not exporting any of the libiberty symbols. Libiberty might have 50 objects, but libbfd may only need two of them -- lotsa bloat. (2a) This works as you would normally expect; the libiberty _LIBADD is dropped from the 'ar' command when building the libbfd static library. (2b) This also works, but is problematic. The interface of the shared libiberty library is not stable. It depends on what objects are deemed necessary for a given target (or host, or even build, sometimes) and multilib setting. Normally, that's the time you should use -release MY_PACKAGE_VERSION instead of -version-info MY_C:MY_R:MY_A -- but libiberty is shared at a *source* level between multiple projects, which may be built differently, at different times. Besides, even if the build variant issue wasn't a problem, libiberty doesn't even HAVE release numbers we could use, so we'd need to come up with something to use... This is also an issue for gnulib. I considered maybe some
Re: [RFC] New library "type" needed?
Charles Wilson wrote: (3) where the PIC resolver library is used *like a static library* when building dependent shared libraries -- that is, used to satisfy undefined symbols in the shared library if -no-undefined, but where the objects in the PIC resolver library are NOT included wholesale via --whole-archive/--no-whole-archive -- and better yet, on win32 they should be excluded from auto-export using -Wl,--exclude-lib -Wl,resolver library name>. oops. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] New library "type" needed?
Charles Wilson wrote: I completely understand the motivation for the meat of this, speaking in the hypothetical sense, but why would you ever want to build libbfd shared? I did --enable-shared at the top level, and bfd is the first one that failed. I'm really more interested in the runtime libs (libgcc, libsupc++, etc) but I'm pretty sure that almost everything depends on libiberty...so the problem will show up eventually somewhere I care about. Why not solve it up front, with the first failure? Sure, I could have configured using "--enable-shared=lib,lib,lib" and left libbfd out of the list, but... It is always built static by default even on ELF systems, for the same reason as libiberty - it is not expected to expose anything resembling a stable or maintained ABI. Not entirely true. It is explicitly a part of binutils, and binutils has a version number. Plus, libbfd is already libtoolized and built using -release (*not* -version-info) so you'd end up with cygbfd-2.7.50.dll or somesuch. And its maintainers do not want the burden of having to maintain an ABI given its history of not being designed as such. So it seems like a really bad idea to jump through hoops to make it shared, as you'd end up with the situation you mentioned dozens of cygbfd-.dll files to satisfy all the various consumers. See above; the binutils maintainers have already thought of this, which is why they use -release. They can do this becuase bfd is part of bintuils, and not *part of* anything else, even if it may be *used by* something else. libiberty OTOH is shared _at the source_ level between binutils, gcc, newlib, and cygwin projects (more?) -- so (a) no one project owns it (b) it has no version number (c) it is needed to resolve undefined symbols (on windows) within not just applications from those various projects, but also libraries. Maybe I'm wrong; maybe libiberty is only needed by the non-runtimes, and I should just let -shared fail for libbfd and libopcodes, and hope for the best with respect to libgcc and all the runtime libs. But I think I've uncovered an underlying limitation (maybe win32-specific) with the current set of library "types" managed by libtool -- which is why I mentioned the other major set of software shared between projects at the source level: gnulib. Right now, any shared library that uses gnulib (typically built as a convenience library) will export symbols for (for instance) basename, just because they happen to use that symbol internally. cygMyLibrary.dll and cygYourLibrary.dll shouldn't both supply that symbol, should they? It's an internal implementation detail...but right now, the only way to not export gnulib-supplied stuff is to turn off auto-export in your non-gnulib code by explicitly declspec()ing stuff or using .def files (ugh. back to the bad old days). Or relying on non-portable "tricks" that lead to command lines with junk like this -Wl,--exclude-libs -Wl,libiberty.a -Wl,libgnulib.a AND -Wl,--whole-archive libiberty.a -Wl,--no-whole-archive -Wl,--whole-archive libgnulib.a -Wl,--no-whole-archive where these are "hand-coded" to a degree, in that the --exclude-libs garbage is inserted via _LDFLAGS. Ick. Granted, the gnulib folks are fitfully investigating mechanisms to rename symbols (e.g. cygMyLibrary might have MyLibary_basename, while cygYourLibrary would have YouLibrary_basename), which would prevent symbols from *clashing*. But even then, these internal implementation-detail symbols should not be in the export list. (I'm glossing over certain complications with gnulib, like program_name data elements and such, which would become awkward under both symbol-renaming and do-not-export regimes. Leave that aside for now...) -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [cygwin] Analysis for new testsuite failures 33,34.35
[EMAIL PROTECTED] wrote: On Mon, 26 Mar 2007 20:39:24 +0200, "Ralf Wildenhues" said: AFAICS, this can only happen if libltdl was treated with automake-1.9 and the tests run with automake-1.10 in place, so that the toplevel package (named subproject-demo-2.1a) is treated with 1.10. I'm not so sure; I believe I first encountered the problem using 1.9.6 exclusively, but I will rebootstrap explicitly with (unpatched) 1.9 and make sure. ... I hope I'm wrong... Fortunately, I was wrong. This change: http://sources.redhat.com/cgi-bin/cvsweb.cgi/automake/lib/am/distdir.am.diff?r1=1.63&r2=1.64&cvsroot=automake&f=h has two parts; the behavior I observed was because I was getting one part of it, without the other -- exactly as Ralf surmised. After forcibly rebootstrapping[*] with 1.9.6, it worked fine. I don't believe there is any need to worry about patching 1.9.6/7 or requiring 1.10 -- this "problem" has an easy solution: if using libltdl as a subproject, ensure that you use the same version of automake there as in the project that contains it: 1.9 or 1.10 (earlier? dunno), just be consistent. -- Chuck [*] this is where cygwin's slightly overgrown autotools system works well: we have a gentoo-derived "smart" wrapper for automake, but ALSO use alternatives, for when you absolutely positively have to use a specific version, and the "smart" wrapper is acting a little too smart for its own good... automake - status is manual. link currently points to /usr/bin/automake-1.9 /usr/bin/automake-1.10 - priority 60 slave aclocal: /usr/bin/aclocal-1.10 slave automake-info: /usr/share/info/automake1.10.info.gz /usr/share/autotools/am-wrapper.sh - priority 100 slave aclocal: /usr/share/autotools/am-wrapper.sh slave automake-info: /usr/bin/automake-1.4 - priority 10 slave aclocal: /usr/bin/aclocal-1.4 slave automake-info: /usr/bin/automake-1.5 - priority 15 slave aclocal: /usr/bin/aclocal-1.5 slave automake-info: /usr/bin/automake-1.6 - priority 20 slave aclocal: /usr/bin/aclocal-1.6 slave automake-info: /usr/bin/automake-1.7 - priority 30 slave aclocal: /usr/bin/aclocal-1.7 slave automake-info: /usr/bin/automake-1.8 - priority 40 slave aclocal: /usr/bin/aclocal-1.8 slave automake-info: /usr/bin/automake-1.9 - priority 50 slave aclocal: /usr/bin/aclocal-1.9 slave automake-info: /usr/share/info/automake1.9.info.gz Current `best' version is /usr/share/autotools/am-wrapper.sh. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] New library "type" needed?
Ralf Wildenhues wrote: Here's a review based on the question how such a concept could be expressed portably. I don't see how something like this would be of great help if it could not be made to gracefully decay into something still usable, on at least a useful set of platforms if not all of them. Agreed. While I was considering the problem, I kept getting the feeling that either (1) I was missing something, or (2) this was very win32 specific: it's a problem only for platforms that require -no-undefined for shared libraries, which I think is only win32 and AIX. * Charles Wilson wrote on Sun, Mar 25, 2007 at 09:34:47PM CEST: What I really want is a type of convenience library (call it a "resolver" library?) that (1) is built both PIC and non-PIC, depending of course on the value of enable_shared and enable_static. So far, just like a "normal" convenience lib. Well, currently a convenience lib is not built in both ways at the same time, but that's only a side issue for the discussion at hand. Really? I thought I had both; perhaps it was just accumulated clutter from multiple builds with different settings. In any case, I can see where the current behavior you describe could be problematic on some platforms, including win32, in certain cases. (2) where the non-PIC resolver library is ignored when building dependent static libraries (and dependent static [dlpreopened] modules). That is, NOT exploded and included within the dependent. However, the non-PIC resolver library should be used like a normal convenience library when building dependent, in-package executables that depend on it directly OK so far. You want a convenience archive without the whole-ness. Should it be possible to install this thing or not? Ummm...maybe? Let me ping back a few more questions: how would you install/distinguish between the two versions (no-pic and pic)? Would we need a naming convention of some sort and teach ld/gcc about it (a la' .dll.a) This could get ugly. On the other hand, currently binutils/gcc/etc install libiberty.a -- but do not install any headers for it. So the only was to use an *installed* libiberty is to declare the relevant functions yourself (or go dig around in the src for the headers), AND hope that whoever built the libiberty.a you want to link against, built it in such a way that it includes all the functions you want. In short, *currently* libiberty is not well-handled. Since the intent for that library is to share at the source level, a better policy would be for binutils/gcc/etc to affirmatively change their build structure to NOT install libiberty.a. And nobody talks about installing a libgnulib.a -- especially as gnulib-tool lets you change the library name... So maybe the answer to the question SHOULD BE no, even if at present the actual practice IS to install libiberty.a. Can it itself have nontrivial (i.e., non-convenience) dependencies? Errr...the two extant examples (libiberty and gnulib) do not, but... The first of these questions is really a crux of the matter: if libbfd can be shared and installable, then really I don't see any way except - either explicitly forbid any third party to use your library, even though you install it shared, - or have at least some sort of stable interface notion. Yes. Since libiberty is explicitly unstable in its interface, I believe it really makes no sense to install it; it's just of no use outside the build tree. Following this line of reasoning, I think my "resolver" library concept is really just a variant of a convenience lib -- in the sense that convenience libs are not usually (ever?) considered as installable objects. (worry about PIE here? We don't worry about it at present anywhere that I can see). We have very minimal PIE support only currently in CVS HEAD, in compile mode. Don't know enough about this issue; I'll let it pass... (3) where the PIC resolver library is used *like a static library* when building dependent shared libraries -- that is, used to satisfy undefined symbols in the shared library if -no-undefined, but where the objects in the PIC resolver library are not included wholesale via [ "not" correction included ] --whole-archive/--no-whole-archive -- and better yet, on win32 they should be excluded from auto-export using -Wl,--exclude-lib -Wl,library name>. Lots of systems don't allow symbol hiding (or, at least, Libtool currently doesn't support it well on most systems). What should happen for them? More to the point: what if libbfd uses the resolver libiberty release x, while libfoo used release y of libiberty, we're on a system without symbol hiding, and my program links against both libbfd and libfoo? The order of linkage will determine in which library the blow up occurs, be that silent or spectacular, depending on h
Simultaneous pic and non-pic convenience libs [Was: [RFC] New library "type" needed?]
Charles Wilson wrote: I'd still like to be able to build my convenience library as both pic and non-pic tho. And I still want to prevent libiberty.a(non-pic) from getting the --whole-archive treatment when it comes to libbfd.a. ... Several systems simply don't allow to mix PIC and non-PIC symbols. On w32 this warning is pathetic, but on others we would have a problem here. (I can see why, on w32, you'd want to kill the warning here.) No, you're missing the point of my statement: I *know* you don't want to mix pic and non-pic. After doing a bit of reading, the statements above are a little too strong. It's not that you can't mix pic and non-pic (or at least, it's not obviously the case; we'll dig deeper -- see below). At the surface level, it is simply that where -fpic/-fPIC makes a difference, you cannot include non-pic in a shared library. However, there's no reason you can't include pic in a static library: you just lose a little efficiency (from the AutoBook) "In practice, you can link PIC objects into a static archive for a small overhead in execution and load speed..." e.g. shared << pic only static << pic and non-pic ok Which I guess is why: if pic available, libtool defaults to using pic objects in the convenience lib, unless specifically directed otherwise. And yet, that same, single, convenience lib (which is pic) will be used when creating both static and shared libraries that depend on it. Digging deeper: On cygwin/mingw *at present*, the only difference between pic and non-pic is that the former objects were compiled with "-DPIC -DDLL_EXPORT". This could cause trouble for convenience libs that are sensitive to DLL_EXPORT (and isn't that the point? otherwise, why bother to -D it?) -- because while the machine code is more-or-less the same (that is, gcc doesn't generate machine instructions differently _on its own_) -- some packages might behave differently _at the source code level_ due to the different -Ddefines One example is libltdl itself, as we discovered a few months ago: #if !defined(LT_SCOPE) # if defined(__WINDOWS__) || defined(__CYGWIN__) #if defined(DLL_EXPORT) # define LT_SCOPE extern __declspec(dllexport) #endif #if defined(LIBLTDL_DLL_IMPORT) # define LT_SCOPE extern __declspec(dllimport) #endif # endif # if !defined(LT_SCOPE) #define LT_SCOPEextern # endif #endif So, we come full circle: now it's clear that the libtool assumption of "hey, if pic available, then just always use pic when building convenience libs (unless instructed otherwise via no-pic/--without-pic); that way, the result is "safe" for use regardless", breaks down on cygwin/mingw! So, perhaps it really is time to revisit this assumption...see Alexandre Oliva, February 2001 [ignoring the bits about "installable convenience libraries (??!!)] http://sources.redhat.com/ml/automake/2001-02/msg00304.html "And I wish convenience libraries could still come in PIC and non-PIC versions, just like object files. Currently, every time you create a convenience archive, you don't get the non-PIC objects, unless the PIC objects aren't available." There's still some issues with convenience libs themselves (where the following discussion ignores ALL of the above, no new library types, no new -exclude-lib option), like: (a) we should build a pic version and stuff it inside .libs/ if -enable-shared, and put a regular version in . if -enable-static ... (b) When linking a shared lib where a convenience lib appears in the deps, use the one in the .libs/ directory (c) ??? when linking a PIE executable where a convenience lib appears in the deps, use the one in the .libs/ directory (d) when creating a static lib where a convenience lib appears in the deps, use the one in the . directory when doing the explode-and- incorporate thing. (e) when creating a next-level convenience lib that has THIS convenienece lib as a dep, again, create a pic version in .libs and a non-pic version in . In each case, use the "matching" version of the dependency when doing the explode-and-incorporate thing. (f) In all other cases, use the "regular" lib [replace 'explode-and-incorporate thing' with 'partial linking thing' if your platform supports it] These improvements to "regular" convenience libraries are, IMO, necessary for proper operation where pic/no-pic makes a difference. And, as detailed above w.r.t. "-DDLL_EXPORT", even when -fpic itself makes no difference. I tried to figure out what it would take to do the above, but the maze of twisty little passages all the same made my head hurt. It *looks* like the build-a-convenience-lib codeflow "borrows" the "build
Re: .exe magic
[added libtool to CC list] Corinna Vinschen wrote: On Apr 18 04:49, Charles Wilson wrote: The current .exe behavior has benefited from many years of tweaking and fine-tuning, across many different packages (cygwin, gcc, gdb, binutils, automake, autoconf, libtool, bash, coreutils, ...) to work together to give the current, mostly coherent, least-surprise behavior we enjoy today. [...] Apart from that, I don't like what libtool does. I think it's a terrible idea to have a script and a binary with the same name (only differing by the .exe suffix) in the same directory. This behaviour breaks the CYGWIN=transparent_exe option and there's no reliable way around this. Is there any chance that this could be changed in libtool? Absolutely. I outlined the steps necessary to do this: http://cygwin.com/ml/cygwin-apps/2006-03/msg00028.html But got not P to TC. Any takers this time around? Caveat: over a year after the message referenced above, but libtool2.0 is STILL in code-slush, so the desired fixes will have to wait until after 2.0 (or 2.2, or whatever the heck we decide to call it) is released. Of the three steps outlined in the "fix", it's possible that (1) and (2) could go in prior to the 2.0/2.2 release, but this kind of thinking is why we're still in slush and haven't released. -- Chuck P.S. This will make you cry: libtool-1.5.0 was released 14-Apr-2003, four years ago last Saturday. After a year and a half, some destabilizing changes were under consideration and rejected for 2.0 -- we were "too close to a release" -- so an abortive "branch-2-0" was created 3-Oct-2004 and the "destabilizing" changes went into HEAD. Development continued sporadically on this branch for about a year until 24-Aug-2005 -- but throughout, most development effort remained on the trunk or branch-1-5. The load on the developers maintaining three branches was extreme, and branch-2-0 -- supposedly the "almost ready to release" branch -- was getting short shrift, for a YEAR. And the "destabilized" HEAD was now actually *more* stable than branch-2-0! It got so bad that the branch was abandoned, and 2.0 was retargeted to come from cvs HEAD Real Soon Now. Another year and a half, and here we are...still in code slush. (Sounds very very similar to the ongoing discussions with regards to gcc-4.2: http://gcc.gnu.org/ml/gcc/2007-02/msg00427.html and http://gcc.gnu.org/ml/gcc/2007-04/msg00510.html. Only much much worse.) However, there are indications that this situation will come to an end Real Soon Now And This Time We Mean It. So, here's hoping... ___ http://lists.gnu.org/mailman/listinfo/libtool
[cygwin, libtool] use shell function to emit wrapper scripts and wrapper.exe source [Was: Re: .exe magic]
[Added libtool-patches to CC list. Discussion of this patch
should probably drop libtool and cygwin]
Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Apr 18, 2007 at 08:49:31PM CEST:
Caveat: over a year after the message referenced above, but libtool2.0
is STILL in code-slush, so the desired fixes will have to wait until
after 2.0
... I'd prefer to see such a patch before deciding when it's good to put
it in.
Okay, here's the first bit. It's pretty simple. Testing is in progress
(and in conjuction with the new argz fix I just posted to
libtool-patches), but looks good so far: the "new" wrapper scripts are
identical to "old" ones generated without this patch.
--
Chuck
ChangeLog
2007-04-18 Charles Wilson <[EMAIL PROTECTED]>
* libltdl/config/ltmain.m4sh [func_mode_link]: move wrapper
script writing from here...
[func_emit_libtool_wrapper_script]: to this new function, and
write to stdout
[func_mode_link]: move cwrapper source code writing from here...
[func_emit_libtool_cwrapperexe_source]: to this new function,
and write to stdout
[func_mode_link]: call the two new functions and redirect to
appropriate file.
Index: libltdl/config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.72
diff -u -r1.72 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 10 Apr 2007 19:09:26 - 1.72
+++ libltdl/config/ltmain.m4sh 19 Apr 2007 01:05:30 -
@@ -1202,6 +1202,555 @@
}
}
+# func_emit_libtool_wrapper_script
+# emit a libtool wrapper script on stdout
+# don't directly open a file because we may want to
+# incorporate the script contents within a cygwin/mingw
+# wrapper executable. Must ONLY be called from within
+# func_mode_link because it depends on a number of variable
+# set therein.
+func_emit_libtool_wrapper_script ()
+{
+ $ECHO "\
+#! $SHELL
+
+# $output - temporary wrapper script for $objdir/$outputname
+# Generated by $PROGRAM (GNU $PACKAGE$TIMESTAMP) $VERSION
+#
+# The $output program cannot be directly executed until all the libtool
+# libraries that it depends on are installed.
+#
+# This wrapper script should never be moved out of the build directory.
+# If it is, it will not operate correctly.
+
+# Sed substitution that helps us do robust quoting. It backslashifies
+# metacharacters that are still active within double-quoted strings.
+Xsed='${SED} -e 1s/^X//'
+sed_quote_subst='$sed_quote_subst'
+
+# Be Bourne compatible
+if test -n \"\${ZSH_VERSION+set}\" && (emulate sh) >/dev/null 2>&1; then
+ emulate sh
+ NULLCMD=:
+ # Zsh 3.x and 4.x performs word splitting on \${1+\"[EMAIL PROTECTED]"},
which
+ # is contrary to our usage. Disable this feature.
+ alias -g '\${1+\"[EMAIL PROTECTED]"}'='\"[EMAIL PROTECTED]"'
+ setopt NO_GLOB_SUBST
+else
+ case \`(set -o) 2>/dev/null\` in *posix*) set -o posix;; esac
+fi
+BIN_SH=xpg4; export BIN_SH # for Tru64
+DUALCASE=1; export DUALCASE # for MKS sh
+
+# The HP-UX ksh and POSIX shell print the target directory to stdout
+# if CDPATH is set.
+(unset CDPATH) >/dev/null 2>&1 && unset CDPATH
+
+relink_command=\"$relink_command\"
+
+# This environment variable determines our operation mode.
+if test \"\$libtool_install_magic\" = \"$magic\"; then
+ # install mode needs the following variables:
+ generated_by_libtool_version='$macro_version'
+ notinst_deplibs='$notinst_deplibs'
+else
+ # When we are sourced in execute mode, \$file and \$ECHO are already set.
+ if test \"\$libtool_execute_magic\" != \"$magic\"; then
+ECHO=\"$qecho\"
+file=\"\$0\"
+# Make sure echo works.
+if test \"X\$1\" = X--no-reexec; then
+ # Discard the --no-reexec flag, and continue.
+ shift
+elif test \"X\`{ \$ECHO '\t'; } 2>/dev/null\`\" = 'X\t'; then
+ # Yippee, \$ECHO works!
+ :
+else
+ # Restart under the correct shell, and then maybe \$ECHO will work.
+ exec $SHELL \"\$0\" --no-reexec \${1+\"[EMAIL PROTECTED]"}
+fi
+ fi\
+"
+ $ECHO "\
+
+ # Find the directory that this script lives in.
+ thisdir=\`\$ECHO \"X\$file\" | \$Xsed -e 's%/[^/]*$%%'\`
+ test \"x\$thisdir\" = \"x\$file\" && thisdir=.
+
+ # Follow symbolic links until we get to the real thisdir.
+ file=\`ls -ld \"\$file\" | ${SED} -n 's/.*-> //p'\`
+ while test -n \"\$file\"; do
+destdir=\`\$ECHO \"X\$file\" | \$Xsed -e 's%/[^/]*\$%%'\`
+
+# If there was a directory component, then change thi
Re: [PATCH] Don't install .la files when --no-la-files is used
Roumen Petrov wrote: > Linking readline against ncurses prevent application to link against > readline against ncursesw and to offer wide characters support. Note that this is only even possible on a system with lazy binding. For windows, shared libraries cannot have any undefined symbols at link time, which means that the libreadline DLL (for instance) SHALL be bound to some particular instance of libcurses. There is no choice. If you try to exploit this in your build system, to allow "floating" readline...that will not be a portable construct. libtool is about portability, not necessarily about squeezing every possible flexibility out of ELF lazy binding. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem when cross compiling with mingw32ce
Vincent Torri wrote: > here is a reminding of something that i reported 2 months ago: (see > http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html). > > I recall the facts: when using the mingw32ce compiler, > func_emit_cwrapperexe_src() fails, hence the installation of the > binaries is not done. > > That function fails because several functions do not exist on that > platform. They are: > > * getenv, putenv (no environment variable on that OS) > * getcwd (no current working directory feature too) > * _spawn() > > The simple way would be to guard them, like it was done with errno: > > http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=2a06feab95ec4c0e10f265dfb40aff381489d8f3 Well, not really. The whole purpose of the wrapper (executable, or shell script on unix platforms) is to *set environment variables* appropriately before invoking the actual target executable -- especially $PATH on win32 so that the target executable can "find" the newly-built and not-yet-installed DLLs that it needs. How wince handles that with no environment variables I have no idea. Maybe if it has no directories at all (and hence, no "current working directory"), then "finding" DLLs it not really an issue. I dunno. But most of that can be worked-around using stub functions in the wrapper executable (e.g. wince_setenv() that does nothing and returns success, etc). What can't be worked-around is: _spawn. Somehow there MUST be a way for one executable on wince to start another process. Maybe by invoking CreateProcess() directly -- whereas the normal win32 C runtime provides the _spawn functions as posix-like wrappers around the core Win32API CreateProcess(). I guess there are two choices: (1) do we need the wrapper (executable) to "work" -- that is, can you invoke the wrapper executable within the target environment (a wince emulator, perhaps?) and if so, do we need it to perform as advertised: set up the proper environment (whatever that means, if anything, given no env vars) and handover control within the simulator environment to the actual executable, in .libs/$myexe? If the answer to either question is no, then perhaps the answer is (2) just to ensure that the wrapper executable compiles without error, even if it is utterly non-functional on wince. That's a little...disturbing, but then, I'm not involved with wince. FYI: the "re-organized includes and portability macros" part of this patch: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89. http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg4.html was done with an eye toward making these wince workarounds a little easier. I hope. Oh, there also might be a third option, but I could be exposing more of my ignorance: maybe wince could just set $needs_wrapper false always, regardless of whether the build is static or dynamically linked? However, what this all boils down to, is somebody is going to have to write the patch, and test it, using mingw32ce. That's going to have to be someone actively involved in using mingw32ce and the wince OS. That ain't me. And given that your original post was 2 months ago, with little response, it looks like very few of the list denizens, other than yourself, have the expertise to directly tackle the problem. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool under windows and cygwin
Andreas Otto wrote:
>
> as special restriction I use the build-tools from cygwin
> but it is no cygwin library at all because I use the
> build-in mingw compiler
>
> gcc -mno-cygwin
This is *not* a "built-in mingw compiler. It's a hack that sometimes
works, but always causes problems. It is deprecated and will be removed
from cygwin's gcc-4 releases. It will be replaced by a true cross
compiler (cygwin-host, mingw-target).
> and the library is a real windows libraray ...
>
> question: howto avoid the cyg prefix ?
Tell configure (and therefore, libtool) that your eventual $host will be
mingw:
configure --build=cygwin --host=mingw CC="gcc -mno-cygwin"
(The CC= part may be required for now, until cygwin begins distributing
a "real" cross-compiler. OR, you could instead invoke the *mingw*
project's CC from a cygwin environment. See the mingw-users mailing
list; there was a discussion about that topic just this week.)
While all of the above may solve your problem for *nix and mingw, what
if you want to build an actual cygwin version? I think you really need
platform-dependent code. My Java's a little rusty, but
MyLoadLibrary(String module_basename)
{
if System.platform() == "cygwin" {
String MODULE_PREFIX = "cyg"
} else {
String MODULE_PREFIX = "lib"
}
System.loadLibrary(MODULE_PREFIX + module_basename)
}
Naturally, you can make this a lot cleaner with additional abstraction
(a portability class, where MODULE_PREFIX is a final member so the
System.platform() test only happens once). You could do fancy things in
MyLoadLibrary so that module_basename can have the "lib" prefix and it
just gets stripped off and replaced with MODULE_PREFIX only when
necessary -- this way the rest of your code can "pretend" that it always
uses "libfoo". etc. etc.
--
Chuck
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool wrapper script changes basename(argv[0])
Brandon Philips wrote: > Is there a way to make the libtool wrapper create an executable with > the same "progname" as the final executable? Not that I know of. However, the Smart People[tm] over at the gnulib project seem to simply work around it. In the their progname module: http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/progname.c they explicitly check for /.libs/lt- and strip it. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
Ralf Wildenhues wrote: > (On most w32 systems, > a script without an .exe extension would match such a rule as well, but > that's not the case for example on GNU/Linux -> w32 cross compiles and > with some weird Cygwin mount options.) ...such as the default (only) mount mode under the upcoming cygwin-1.7 release. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: documetation on Linux -> Windows cross (libtool + stuff) needed/offered
Ralf Wildenhues wrote: >> If, however, such step by step examples already exist, please point me >> to them and, if the chapter/link with them is not yet in the documentation, >> please put the info into documentation. > > Well, there isn't much in the Libtool manual at all, and only general > information about cross compilation in the Autoconf manual. Documentation help is always appreciated. However, there are a number of pending patches specifically for the linux->cygwin and linux->mingw cross cases that are still outstanding. These patches, once reviewed and accepted, will change in some ways the "right" way to do a cross build for these $hosts. (Mostly, they *should* help make it "just work" like it does for other $build/$host combinations). But don't let that stop you from contributing documentation that is accurate for *existing* libtool. It's always easier to update documentation to reflect changes than to create it from scratch. So if you want to do the hard part (e.g. "from scratch") that'll make my job easier later! -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: purpose of the c wrapper
Ralf Wildenhues wrote: > Vincent, you're contradicting yourself over the course of this work. > I thought at one point we got the wrapper to work on mingwce. I mean > that's the reason we added those __MINGW32CE__ ifdefs in the first > place. If they fail to work properly now, then we should fix *that*, > not hack around it. Or you should come out straight and say "we tried > to get the wrapper to work, but it failed for reasons X and Y which we > cannot solve, so how about we punt and not generate a wrapper?". IIRC, first we just tried to ensure that the wrapper *compiled* without error on wince. We always knew it would be non-functional (apparently, there is no spawn() or exec() functionality on that $host!) The contradiction here is in the assumptions. Originally it was assumed that "just compile, baby!" was enough. Now, it appears that we have additional requirements (do we actually want a functional wrapper of some kind -- e.g. a shell script that works on $build?), so that compilation of the wrapper executable without error is not sufficient. Since (a) we need "more" that simple compile-without-error (b) the wrapper servers no *functional* purpose for these $hosts -- it makes sense to just not build the wrapper in that case. The only caveat I would make is the following: $EXEEXT is .exe for wince $hosts. Therefore the makefile rules expect targets that end with .exe. The shell script wrapper -- if generated in $builddir and not $builddir/.libs! -- won't have that extension. So, for wince you're back to the old "why does make rebuild everything all the time" problem (unless you name the wrapper *script* "foo.exe" which is just...evil). Worse, if $build is a win32 platform, NOW you have an even worse issue...there's a $host executable in $builddir/.libs, or maybe in $builddir itself. AND you have a shell script wrapper for it (in $builddir itself or maybe in $builddir/.libs) -- which may or may not have a "fake" name that ends with $EXEEXT. This is bound to cause problems -- especially if $build is cygwin-1.7. But one thing at a time: it looks like "don't build the wrapper executable on wince" is the right choice. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Different object lists for static and shared libraries
I have a library that I'm building using libtool. When built statically, I want it to include a certain list of object files. When linking that library dynamically, I want to add an additional object (windows resources, compiled using windres). I already have it working so that BOTH versions get the resource object (e.g. special rules to invoke windres, etc). How can I exclude that object from the static archive? The best I could come up with is this: IN the source code for the object, do - top of file - #if defined(BUILDING_MY_LIBRARY) && defined(DLL_EXPORT) stuff #endif - end of file - This way, the object is included in both the static and shared libraries, but in the former case it doesn't have any contents. Is there a better way? -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Different object lists for static and shared libraries
Ralf Wildenhues wrote: > * Charles Wilson wrote on Sun, Jun 28, 2009 at 12:54:59AM CEST: >> Is there a better way? > > Not that I know of. The current code might cause the object list for > the static library to be a larger set than that for the shared library > (because it won't add objects compiled with -static/--tag=disable-shared > to $non_pic_objects), but not vice versa; but my guess is that was only > done to avoid relocation errors. > > With a suitably smart linker, your approach shouldn't cause a larger > final shared library product, however. Well, as it happens windres does not like empty files. So, I hacked up this approach: %.lo : %.rc $(LTRCCOMPILE) -i $< -o $@ $(COMPILE) -x c -c $< -o $(*D)/$(*F).o where the second line forces to recreate the "static" .o by using gcc to compile it as a C file (without -DRC_INVOKED), where the .rc source looks like: #if defined(RC_INVOKED) stuff #endif Since automake doesn't yet put rules for .rc files into Makefile.in, I had to do it manually anyway -- so the hack above is not TOO bad. Anyway, it seems to do the right thing. However...now I have noticed a different problem related to creating both static and shared libraries from (the same) convenience archives. I'll start a new thread. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Creating shared and static libraries with convenience libraries
I ran in to a problem using libtool to generate both shared and static libraries with convenience archives (on cygwin, but I believe this is cross-platform). Working with git-master xz utils, with some local patches, I saw the following: /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -Wall -Wextra -Wformat=2 -Winit-self -Wstrict-aliasing -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls -Werror -g -O2 -version-info 0:0:0 -no-undefined -Xlinker --output-def -Xlinker liblzma.def.in -o liblzma.la -rpath /usr/local/lib common/libcommon.la check/libcheck.la lz/liblz.la lzma/liblzma2.la rangecoder/librangecoder.la delta/libdelta.la simple/libsimple.la liblzma_w32res.lo ... Creating library file: .libs/liblzma.dll.a : libtool: link: (cd .libs/liblzma.lax/libcommon.a && ar x "/usr/src/packages/xz/git/_build/src/liblzma/common/.libs/libcommon.a") libtool: link: (cd .libs/liblzma.lax/libcheck.a && ar x "/usr/src/packages/xz/git/_build/src/liblzma/check/.libs/libcheck.a") ... Note the various convenience libraries, such as common/libcommon.la. In $build/common/ there exist a lot of .o and .lo files, while $build/common/.libs contains a lot of (other) .o files. As expected, the first set of .o's were all compiled with "normal" flags, while the second set were compiled with the pic flags (which for cygwin are -DDLL_EXPORT -DPIC). However, for each of those convenience archives, only a single .a is created -- e.g. $build/common/.libs/libcommon.a, and it contains only the "pic" .o's from $build/common/.libs/. The associated .la file looks like this: ... # The name that we can dlopen(3). dlname='' # Names of this library. library_names='' # The name of the static archive. old_library='libcommon.a' ... So, when we get around to linking the actually installable library, both the DLL and the "static' archive contain the same .o's -- the ones compiled with the "pic" flags -DDLL_EXPORT and -DPIC. This is a problem, because now the "static" archive contains declspec(dllexport)-decorated symbols. (a) Is this a known issue, a new bug, or a design decision? (b) I can work around it by avoiding convenience archives entirely, and using subdir objects instead. However, I'm unsure which released automake version first *successfully* supported those...I know they were introduced in 1.9, but IIRC proper operation required a patch that wasn't merged until 1.10. Is my recollection correct? (c) longer term, if this IS a bug, then should it be fixed? How? The relevant code is a maze of twisty passages, all alike... -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Creating shared and static libraries with convenience libraries
Bob Friesenhahn wrote: > On Sun, 28 Jun 2009, Charles Wilson wrote: >> >> So, when we get around to linking the actually installable library, both >> the DLL and the "static' archive contain the same .o's -- the ones >> compiled with the "pic" flags -DDLL_EXPORT and -DPIC. >> >> This is a problem, because now the "static" archive contains >> declspec(dllexport)-decorated symbols. It might also be an issue if you use -DPIC to determine whether to use gcc-4.x's visibility specifiers, for non-win32. Not sure about that, tho. I've verified that this behavior (pulling in the .libs/.o's into the "static" archive, when convenience libs are used) also occurs with 1.5.x. As it happens, liblzma itself does not export any data items, so in MY mingw 3.4.5 builds I don't actually see the problem. However, Lasse does see it in his mingw 4.4.0 builds, and this seems to be the reason. > Interesting. I think that it is assumed that "PIC" code will work in a > static archive. Apparently this is a wrong assumption for "decorated" > DLL code. Most open source projects ported to Windows rely on GCC's > automatic DLL import feature. Unless you're using MinGW to build a DLL (that exports data items?), and is intended for use with MSVC. Or your name is Bruno, and you don't like auto-import: http://www.haible.de/bruno/woe32dll.html >> (b) I can work around it by avoiding convenience archives entirely, and >> using subdir objects instead. However, I'm unsure which released >> automake version first *successfully* supported those...I know they were >> introduced in 1.9, but IIRC proper operation required a patch that >> wasn't merged until 1.10. Is my recollection correct? > > I know that I used it successfully for a large non-recursive build with > subdir objects prior to 1.10 being released. That would have been when > the Automake feature was still "bleeding edge". Problems I noticed in > those days were libtool's fault and not Automake's fault. Thanks for the data point. It appears upstream is using 1.10 for their distribution tarballs, so as long as they are happy to *require* 1.10 or above (for developers who want to autoreconf), then we're good to go. The main downside of always avoiding convenience libraries is they are the only way to get per-object compile flags... -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning and ABI
Michel Briand wrote: > This last variable is crafted "crafted"? This is your mistake. > to reflect the usual versioning. I.e. if > I want the version to 1.22.5, Why? Why do you CARE what the internal ABI version number is? It's just a tag; you shouldn't care WHAT it is, only that it changes ONLY when it actual has to, to reflect binary (in)compatibility. libfoo.so.27.1.2 is part of foo-3.1.2. Big deal. There's no need that it MUST be libfoo.so.3.1.2 with SONAME "libfoo.so.3" > I must put 23:5:22 in the _LTVERSION > variable (effectively doing substractions ;^^). No, you must change your GNU/Linux/ELF-centric thinking about shared libraries. == 7.4 Managing release information Often, people want to encode the name of the package release into the shared library so that it is obvious to the user which package their programs are linked against. This convention is used especially on GNU/Linux: trick$ ls /usr/lib/libbfd* /usr/lib/libbfd.a /usr/lib/libbfd.so.2.7.0.2 /usr/lib/libbfd.so trick$ On `trick', `/usr/lib/libbfd.so' is a symbolic link to `libbfd.so.2.7.0.2', which was distributed as a part of `binutils-2.7.0.2'. Unfortunately, this convention conflicts directly with libtool's idea of library interface versions, because the library interface rarely changes at the same time that the release number does, and the library suffix is never the same across all platforms. == Basically, you are accustomed to a particular quirk of ELF DSOs and the way Linux distributors have been packaging them. But that "quirk" is NOT a fundamental part of the idea of shared libraries -- and they do not work that way on many, many platforms. The SONAME should distinguish the major (ABI breaking) versions of the library. When FOSS projects are *careful*, many times this does, in fact, correspond with actual major releases of the package itself. (e.g. foo-2.x.y breaks binary compatibility with foo-1.x.y). They are not always careful. And, just because ABI compatibility is preserved on one specific class of system (32bit GNU/Linux) does not mean that 1.x+1.y or even 1.x.y+1 doesn't break ABI compatibility on some other system. ABI version != package version. Stop thinking that they are. (It is, of course, good manners to *bump* the major package version when you deliberately modify the ABI. But just because "change package version from X.Y.Z to X+1.Y.Z, whenever SONAME S changes", that doesn't mean that X = S. In fact, if you are using libtool, many times the SONAME will jump by more than one: foo-1.7.2-version-info 15:2:5 SONAME libfoo.so.10 S = 10 make one ABI-breaking change, and the "rules" say that version info becomes -version-info 16:0:0 SONAME libfoo.so.16 S = 16 It's good manners to release this new version as foo-2.0.0 (not foo-16.0.0) And your typical linux distribution would package the results as old: libfoo-devel-1.7.2-- libfoo10-1.7.2-- foo-1.7.2-- new: libfoo-devel-2.0.0-- libfoo16-2.0.0-- foo-2.0.0-- See? No relation between "1.7.2" and "10", nor between "2.0.0" and "16". -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning and ABI
Michel Briand wrote: > Thank you, but, sorry, I'm not convinced. Remember what I said a > few mails ago: that's all of interface contract = same concept as > your... > > Does anyone uses "10" or "16" to refer to their ABI ? Hum... So those > numbers have to be managed somewhere... Yes. Here are a few libraries on my linux box: libalsa2-1.0.15-0.rc1.4mdv2008.0 ABI=2, pkgver=1.0.15 libamarok0-scripts-1.4.7-9mdv2008.0 ABI=0, pkgver=1.4.7 libamrnb2-6.1.0.3-1plf2008.0 ABI=2, pkgver=6.1.0.3 libao2-0.8.8-2mdv2008.0 ABI=2, pkgver=0.8.8 libapplewm7-1.0.0-5mdv2008.0 ABI=7, pkgver=1.0.0 libavformats51-0.4.9-3.pre1.8994.2plf2008.0 ABI=51, pkgver=0.4.9 libavutil49-0.4.9-3.pre1.8994.2plf2008.0 ABI=49, pkgver=0.4.9 and that's just the liba*'s. Managing those numbers is part of maintaining a library, and you do it in the Makefile[.am], documentation, and (.spec|.deb|pkglist). It's just part of the job. In case you're wondering, here's the contents of libavformats51-0.4.9-3.pre1.8994.2plf2008.0: /usr/lib/libavformat.so.51<< SONAME, S = 51 /usr/lib/libavformat.so.51.12.1 << derived from -version-info. None of these numbers has anything to do with "0.4.9". The -version-info 63:1:12 is managed completely independently of the decision-making process for "hey, should we call this release 0.4.9 or 2.7.1? (except, of course, for the politeness aspect that (a) totally random version numbers are stupid and something only Microsoft w95/w98/Me/2k/XP/Vista/7 does, not a FOSS thing, and (b) it's nice to *increment* (net "set equal to a specific value") the major version number of the package when the SONAME changes due to internal ABI breakage. > If developers and users are ok with X.Y.Z then the CURRENT, REVISION > and AGE is a different scheme to learn and to implement in the build > system: that need to be managed in parallel. Yes, that's exactly what were trying to help you understand. With the exception of the "niceness" aspect above, *package* numbers are basically marketing, even in FOSS. However, library interface numbers are wholly TECHNICAL. If you change the code in /this way/ then the library interface changes /that way/, according to specific rules; these rules may then also drive a change in the SONAME. > That's to say that if dev > makes some changes in ABI and bumps the version up (say X.Y.Z+1), > someone has to think about the weird libtool thing and update the > libtool's versioning, making substractions and the like... No, you've got it exactly backwards. (Now, what happens during ongoing CVS/git/hg/bzr development is different; the "rules" only apply for actual releases. Otherwise you just get way too many version number changes for no purpose. The point of library versioning is to foster interoperatability across compatible *public* interfaces of your library to *outside* clients. So, really, you basically apply the rules below during the runup to an actual release. But, in principle: If a developer changes the ABI, then the -version-info does NOT change as X.Y.Z+1. The developer must modify the -version-info according to these rules: == from libtool documentation 1. Start with version information of `0:0:0' for each libtool library. 2. Update the version information only immediately before a public release of your software. More frequent updates are unnecessary, and only guarantee that the current interface number gets larger faster. 3. If the library source code has changed at all since the last update, then increment REVISION (`C:R:A' becomes `C:r+1:A'). 4. If any interfaces have been added, removed, or changed since the last update, increment CURRENT, and set REVISION to 0. 5. If any interfaces have been added since the last public release, then increment AGE. 6. If any interfaces have been removed since the last public release, then set AGE to 0. *_Never_* try to set the interface numbers so that they correspond to the release number of your package. This is an abuse that only fosters misunderstanding of the purpose of library versions. *[ed: Read that paragraph again. Go ahead. I'll wait here.] == from libtool documentation Okay, so you've done all that. And now your team decides that it's time to cut a release. You need to pick the *package* version number. This is marketing (modulo the "nice" bump-majver-if-abi-changed behavior). Pick a number. Increment X. Increment Y. Increment Z. do whatever you want. It's NOT a technical decision. > And no matter the operating system : on most the .so will have no > number at all. No, that's wrong. The .so is just the linktime pointer that is found when you link some client using -lfoo. It points to the actual library, which is (as
Re: libtool versioning and ABI
Michel Briand wrote: >> libavutil49-0.4.9-3.pre1.8994.2plf2008.0 >> ABI=49, pkgver=0.4.9 >> > > Please give me the way to learn those ABI number you cite. libavutil49-0.4.9- ^^ is usually used by the distribution (Red Hat? Debian?) to indicate that this package (.rpm? .deb?) contains the shared runtime library of libavutil with SOVERSION 49. That is, it probably contains a "real" file named libavutil.so.49.x.y and closely related items, such as the runtime symlink needed by ld.so for on-demand loading: libavutil.so.49 -> libavutil.so.49.x.y It usually does NOT contain the *linktime* symlink needed by ld when compiling clients with -lavutil: libavutil.so -> libavutil.so.49.x.y because that's in the libavutil-devel-0.4.9- package. The libavutil49-0.4.9- package may also contain a postinstall script to run ldconfig appropriately. The point is, what you've been calling the "major version" (here, 49) is the ABI number, properly speaking, or in libtool terms, the *interface* major version [*], not the *package* major version. (that's "0" from "0.4.9" above). [*] but even that's cheating, because we usually don't like to talk about "major/minor/patch" with regards to API/ABI. We prefer these compatibility indications current, revision, age because it's a more appropriate vocabulary. 'age' tells you how many of the previous ABI's before current, that 'current' is compatible with. 'revision' tells you how many internal code modifications have occured on the implementation of the 'current' ABI, but which have had zero impact on the public ABI itself. Therefore, in this context, ABI "major" version is just "the earliest ABI instance prior to 'current' with which 'current' is backwards-compatible." That is, 7:3:2 --> "major" is 5, and curr = 7 is compatible with 5 6 is compatible with 5 5 is compatible with 5 so the SONAME for all three -version-infos would be libfoo.so.5. and that's why libtool "major" interface numbers skip. If we follow the rules with an ABI change, the next -version-info would be 8:0:0 whose "major" is 8 --> libfoo.so.8 because interfaces #7 and #6 were backwards-compatible with #5, so we skip them. "minor" and "patch" don't *explicitly* tell you any of these things. and "major" only tells you about ABI compatibility if the project managers are very careful. > I've looked into many OSS and found in Makefile.am only 2 cases : > > - version-info 1:0:0 (the guys there didn't want to bother with > libtool versioning apparently... ;)) > > - version-info with the X.Y.Z version "back crafted" to make > the soname version read the same as X.Y.Z You're not looking in the right places. Sure, there are a lot of misconfigured projects out there. But almost all of the GNU projects Do It Right. Hunt around here: http://ftp.gnu.org/pub/gnu/ > Practice usually prevails in software. And when you have the opportunity at the beginning of a project, to do detailed upfront design, so that "in practice" you don't end up "in the ditch", is better. It's real easy to write a quick and dirty makefile that builds 'project bar' on linux. then, you start hacking around with various make rules to ensure that it builds on BSD. Then Darwin. Then, God help you, you try to hack around your custom makefile to get it to work on win32 (and I'm just talking build system, not actual code porting here). And then you try to retrofit it with VPATH so that out-of-sourcedir builds work. The you try to fix the Makefile to support cross-builds. OR leverage decades of work from the automake team, and write a Makefile.am once, up front, even when all you care about is linux, that looks like: bin_PROGRAMS = bar bar_SOURCES = bar.c helper.c man_MANS = bar.1 and it basically works unchanged when you decide to worry about other platforms. Now, if you're really smart and experienced, you could hand-code a Makefile that does all these things up front, the right way, so that it works later on BSD and win32 and with VPATH and crossbuilds. But it is HARD. Three lines of Makefile.am is EASY. And the payoff is huge. Similarly, if you're really smart and work hard, you could hand-craft rules to build your shared library, and even special case for the wild-and-wacky cygwin/mingw DLL issues. Or, you could just use libtool. Ditto, you could think really hard about how to ensure proper ABI numbering and compatibility, and explicitly tie those values to your package version numbers (thus linking the two). Or, you could rely on the effort for supporting shared library builds on 129 different $hosts that has been expended over 15 or more years by people smarter than both of us put together. (Fer instance, did you know it is *illegal* to have a SOVERSION of zero on IRIX? libfoo.so.0 won't work. libtool knows this, and computes ABI major as 'current - age + 1' for that platform. So, how would you package libfoo-0.1.1.tar.gz on IRIX, if y
Re: How do I export only specific symbols? What name should I pass to lt_dlopen?
Stephano Mariani wrote: > Hello, > > I am using the current libtool with cygwin 1.3.9 (all packages up to > date as of this morning): > libtool 20010531a-1 > libtool-devel 20020202-1 > libtool-devel-src 20020202-1 > libtool-stable 1.4.2-2 > > My project has to run on windows (NT/2000/XP) and Linux (2.4.9) and > Solaris (8). > > Here is the relevant portion of the makefile Makefile.am: > > [snip] > > lib_LTLIBRARIES = libsk.la > libsk_la_SOURCES = ... > libsk_la_LDFLAGS = -no-undefined -export-dynamic -version-info 1:0:0 > -module -export-symbols sk.sym > libtool uses '--export-all-symbols' in its link command, which apparently overrides your '-export-symbols sk.sym' option. (BTW, -export-dynamic seems to have no effect in cygwin binutils.) However, including a .def file in the list of objects to be linked will override '--export-all-symbols'. I think. > [/snip] > > However, when examining the libsk.dll.a on windows, ALL the symbols are > exported! I have yet to see if the patched libtool even works on Linux > or Solaris. It works on Linux, for me. > > How do I specify a .def file for windows targets? The .sym seems to make > no difference. You need to figure out how to add the .def file to libsk_la_OBJECTS -- I'm not sure how to do that. As far as doing it conditionally (e.g. only on windows) -- first things first: figure out how to add it AT ALL...then worry about conditionalizing it. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Specifying a .def file for use with libtools libraries
You do know that there are TWO (or more) different versions of libtool in the cygwin distribution, right? One is based on libtool-1.4.2 and uses dlltool to generate the DLL. The other is based on libtool-cvs(2002-02-02) and uses gcc/ld directly to build the DLLs. (Note that there are TWO commands to generate DLLs: "archive_cmds" and "archive_expsym_cmds". Which one is used depends on a bunch of stuff). Finally, there's whatever version of libtool was used in the package you are working on: most libtoolized packages ship with a ltmain.sh file already. If you didn't explicitly re-libtoolize the package, then you are using whatever version of libtool the upstream maintainer used. If you DID explicitly relibtoolize, then you are EITHER using 1.4.2 or 2002-02-02, depending on what the wrapper script detects from your configure.in/ac file. If you didn't understand that (what's all this about wrapper scripts??), then you REALLY need to read /usr/doc/Cygwin/auto*.README, /usr/doc/Cygwin/libtool*.README and check out THIS email message: http://cygwin.com/ml/cygwin-announce/2001/msg00177.html Now, which version of libtool are you REALLY using? --chuck P.S. with respect to the cygwin "devel" libtool, it is a work in progress. It works for everything *I've* tried so far: "normal" C and C++ dlls. I haven't attempted to hide symbols (as you are doing) so I can neither confirm nor deny that it works/breaks. Of course, I don't know if even the OLD libtool-1.4.2 method *really* allows that, so this may not be a "regression" per se. Also, Ralf Habacker *previously* problems wrt KDE DLLs using the 20010531 cygwin "devel" libtool, but I don't know whether the 20020202 cygwin "devel" libtool fixes those problems for him. (Again, this is not a regression because 1.4.2 can't build the KDE DLLs at all, so...) Stephano Mariani wrote: > Yes, I have, and unfortunately, it does not work! > > I have been looking through the source code of the libtool generated by > configure... it seems that it generates an .exp file using the following > command: > > /usr/bin/nm -B .libs/libfile_somefile.o | sed -n -e 's/^.*[ > ]\([ABCDGISTW][ABCDGISTW]*\)[ ][ > ]*\(_\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | sed 's/.* //' | sort > | uniq > .libs/libfile.exp > > And passes it to ld via gcc using -Wl,-retain-symbols-file > -Wl,.libs/libfile.exp > > This seems flawed to me since ld simply ignores it as far as I can see! > > Stephano Mariani > > >>-Original Message- >>From: Charles Wilson [mailto:[EMAIL PROTECTED]] >>Sent: Monday, 18 February 2002 7 14 >>To: Stephano Mariani >>Cc: [EMAIL PROTECTED] >>Subject: Re: Specifying a .def file for use with libtools libraries >> >>This is kindof a kluge, but try this: >> >>libname_la_LDFLAGS = foo.def <-no-undefined and other link flags> >> >>--chuck >> >>Stephano Mariani wrote: >> >> >>>Hello, >>> >>>Is there a way to use something similar to .def files with libtool. >>> > I > >>>have no way of limiting the export list, and the -export-symbols >>> > > >>>directive in the libname_la_LDFLAGS seems not to work. >>> >>>I could go and rename all the symbols to avoid conflicts, but I >>> > would > >>>rather not... there has to be a way to do this using libtool. >>> >>>Please help! I am fast getting desperate enough to drop libtool >>>altogether. >>> >>>Thanks in advance, >>> >>>Stephano Mariani >>> >>> >>>-- >>>Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >>>Bug reporting: http://cygwin.com/bugs.html >>>Documentation: http://cygwin.com/docs.html >>>FAQ: http://cygwin.com/faq/ >>> >>> >>> > > ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool, cygwin: static archives have duplicate .o's
So I was building automake-1.6.1 and ran its self tests, which uncovered a bug in libtool (CVS 20020316). Automake's pr300-ltlib test: Fails in 'make install-strip' because 'strip --strip-debug' on a static library goes berzerk when the library contains two copies of the same object file. Due to a bug in libtool-20020316, the test statlib DOES contain two copies of "a.o": ar cru subdir/.libs/libb.a .libs/a.o a.o The fix is to correct libtool so that it doesn't include bot PIC and nonPIC object files...or to make 'strip.exe' tolerant of the problem. How strip fails: it unpacks the static archive into a temporary directory. However, somehow during the process, because there are two files with the same name (pathnames are not preserved), the unpacked object file gets created without a security descriptor (CYGWIN=ntsec, using NTFS filesystem) -- and "permission denied" to even 'ls' the file... I think the problem in libtool is here: line 4259 in ltmain.in (4758 in libtool): oldobjs="$oldobjs$old_deplibs $non_pic_objects" well, $non_pic_objects=a.o, but $oldobjs=.libs/a.o so both object files get ar'ed into the static lib. I'm not sure what the problem is: should we prevent .libs/a.o (the PIC object) from getting added to $oldobjs, or should this line actually read: oldobjs="$non_pic_objects" and nothing else? If the former, how?? --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Some fixes for cygwin
Oops. Missed a few in that last patch: 2002-05-03 Charles Wilson <[EMAIL PROTECTED]> * tests/pdemo-inst.test: use hell_static instead of hell.static * tests/pdemo-exec.test: ditto --Chuck Index: pdemo-exec.test === RCS file: /cvsroot/libtool/libtool/tests/pdemo-exec.test,v retrieving revision 1.2 diff -u -r1.2 pdemo-exec.test --- pdemo-exec.test 6 Jun 2001 14:53:29 - 1.2 +++ pdemo-exec.test 3 May 2002 14:21:54 - @@ -20,9 +20,9 @@ echo "Executing uninstalled programs in ../pdemo" status=0 -if ../pdemo/hell.static| grep 'Welcome to GNU Hell'; then : +if ../pdemo/hell_static| grep 'Welcome to GNU Hell'; then : else - echo "$0: cannot execute ../pdemo/hell.static" 1>&2 + echo "$0: cannot execute ../pdemo/hell_static" 1>&2 status=1 fi Index: pdemo-inst.test === RCS file: /cvsroot/libtool/libtool/tests/pdemo-inst.test,v retrieving revision 1.2 diff -u -r1.2 pdemo-inst.test --- pdemo-inst.test 6 Jun 2001 14:53:29 - 1.2 +++ pdemo-inst.test 3 May 2002 14:21:54 - @@ -25,9 +25,9 @@ echo "= Executing installed programs" status=0 -if $prefix/bin/hell.static | grep 'Welcome to GNU Hell'; then : +if $prefix/bin/hell_static | grep 'Welcome to GNU Hell'; then : else - echo "$0: cannot execute $prefix/bin/hell.static" 1>&2 + echo "$0: cannot execute $prefix/bin/hell_static" 1>&2 status=1 fi
Some fixes for cygwin
I tried sending these to libtool patches, but it's been four days and the moderator still hasn't allowed them to be posted, so I'll try here. There are two patches; the next one will follow. Having wrestled with libtool for a few days, I've found a number of additional fixes needed for operation on cygwin. These patches, however, won't get you "perfect" operation. You also need a modified automake, because the Makefile's generated by automake within the testsuite don't clean up after themselves very well. When building a statically-linked executable in a directory where a previous build of dynamically-linked exe left a wrapper script behing, well, problems ensue. This happens often in the testsuite. See this message and the thread following it: http://mail.gnu.org/pipermail/automake-patches/2002-May/000785.html Anyway, that's orthogonal to this: 2002-05-03 Charles Wilson <[EMAIL PROTECTED]> * libtool.m4: use $NM to create the symbol list on cygwin, not $ltdll_cmds as on mingw. For all tags, (and host=cygwin) set allow_undefined_flag="" so that the --auto-import magic works properly. For all tags (and host=cygiwn) set always_export_symbols=no -- it is unnecessary thanks to binutils' auto-export magic. * libltdl/ltdl.c: Don't force cygwin to use the LoadLibrary wrapper; use cygwin's builtin implementatino of dl*. * cdemo/Makefile.am: the downside of unsetting 'allow_undefined_flag' -- we must include -no-undefined in the _la_LDFLAGS variable. * depdemo/l1/Makefile.am: ditto * depdemo/l2/Makefile.am: ditto * depdemo/l3/Makefile.am: ditto * depdemo/l4/Makefile.am: ditto * mdemo/Makefile.am: ditto * tagdemo/Makefile.am: ditto * demo/Makefile.am: ditto. But also, we must make special provision to clean up the hell0 wrapper script. * pdemo/Makefile.am: ditto -no-undefined. ditto hell0. And use 'hell_static' instead of 'hell.static' * demo/configure.ac: use -all-static, not -static. * depdemo/configure.ac: ditto * mdemo/configure.ac: ditto * pdemo/configure.ac: ditto * tests/build-relink2.test: look for installed libl3.la in $prefix/lib/ as well as $prefix/lib/extra/. Most of it should be pretty self-explanatory, but a few specific notes: demo/Makefile.am and pdemo/Makefile.am: hell0 wrapper script. Even with the new-and-improved automake, that only takes care of wrappers and executables that are part of bin_PROGRAMS. since hell0 is in EXTRA_PROGRAMS, it is "cleaned up" by a special ad hoc "CLEANFILES" variable. However, only one of its two incarnations gets cleaned up this way -- and then, only when building statically. When building dynamically, hell0.exe doesn't exist at all -- but that's what CLEANFILES ends up having thanks to some transforms in the Makefile. So, explicitly add 'hell0' to CLEANFILES. It won't get transformed there, so at worst you just try to remove the same file twice. Also, since the dynamically-linked exe is actually in .libs/hell0.exe, the 'rm -rf .libs' in the 'clean-libtool' rule will clean that up for you. The configure.ac changes: libtool 'eats' the "-static" argument; you have to feed "-all-static" to libtool, in order to convince it to put "$link_static_flag" in the gcc command line. Otherwise, hell_static.exe is actually linked to the DLL. I suspect this is probably true on other platforms, too... build-relink2.test: This was one problem with the test -- libl3.la doesn't get installed into _inst/lib/extra, and it isn't supposed to. So look for it in the right place, _inst/lib/. However, that didn't fix the OTHER problems that cygwin has with that test... I've attached the patch, as well as my running notes when I was doing the tests and investigating the failures (I figure those should go here just to get them "on the record"). --Chuck ? .build ? .inst ? .sinst ? autom4te.cache ? COPYING ? CYGWIN-PATCHES ? INSTALL ? install-sh ? missing ? mkinstalldirs ? cdemo/autom4te.cache ? demo/autom4te.cache ? depdemo/autom4te.cache ? libltdl/autom4te.cache ? libltdl/config-h.in ? mdemo/autom4te.cache ? pdemo/autom4te.cache ? tagdemo/autom4te.cache Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/libtool.m4,v retrieving revision 1.254 diff -u -u -r1.254 libtool.m4 --- libtool.m4 2 May 2002 14:22:51 - 1.254 +++ libtool.m4 3 May 2002 04:34:08 - @@ -2575,8 +2575,8 @@ # _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless, # as there is no search path for DLLs. _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir' -
Re: C++ exceptions don't work from Cygwin DLLs?
Bob Friesenhahn wrote: > I am attempting to get ImageMagick to work properly using Cygwin DLLs. > The C++ component is built as a DLL using the binutils auto-import > feature and CVS libtool. The library works fine with the glaring > exception that any C++ exception thrown from the library causes an > immediate core dump. I have verified that C++ exceptions do work if > they are not thrown from a DLL, and the library passes all tests > (including C++ exceptions) if it is built as a static library. > > Do you believe that C++ exceptions should be working with Cygwin DLLs? No, not yet. I don't know a whole lot about this, but I think that we need to have a gcc and libg++ that supports threads; and we don't have that yet. But that is supposedly a high priority. I think. I'm forwarding this message to Robert Collins; he may be able to clariy my confusion. Robert -- what's the deal with C++ and exceptions under cygwin, again? --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Some fixes for cygwin -- PING
Can someone with checkin priveleges please review the patches I posted to this list last week (I tried to send them to libtool-patches five days before THAT but couldn't as I am not subscribed). I mentioned in the first email (of three) that you also need a fixed automake. However, that is needed merely for better libtool-test results -- the patches I posted for *libtool* are in no way dependent on fixing automake, and the problems corrected by the automake changes are NOT introduced by these libtool patches; there is no need to "wait" before committing the libtool changes. (However, FWIW, the appropriate fixes HAVE been committed to automake CVS) Thanks, Chuck Wilson ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Proposed libtool patch for MinGW
Bob Friesenhahn wrote: > The attached patch to FSF CVS libtool is intended to make libtool > (mostly) behave as it does for Cygwin when executed with MinGW. It > consists of contributions from Elizabeth Barham, and my own efforts. > > The DLLs are installed to $(libdir)/../bin as they currently are under > Cygwin. Any change to this scheme should be common to both Cygwin & > MinGW unless there is a reason for behaving differently. > > This patch allows a shared library build of ImageMagick (using both C > & C++) to successfully build and install under MinGW using the MSYS > shell environment. I have not tried to build libtool modules with it > yet (should be interesting). > > I am posting this patch with the expectation that concerned parties > will inspect it, test it, and send any fixes so that it can be > incorporated in libtool 1.5. quick question: what pattern is used to name the dlls, implibs, and statlibs? (I don't care, I just want to avoid confusion with the cygwin DLL names). On cygwin, we use: cyg-.dll (where number= 'current' - 'age') lib.dll.a (import lib) lib.la(libtool lib) lib.a (static lib) if mingw's names conflict with cygwin's names for the import lib, libtool lib, and static lib -- that's ok, since even if both are installed on the same system, one assumes that they are in separate paths, and a user can control which is picked up during a downstream link by using appropriate -L commands. But, since this patch borrows a lot of cygwin code, I'm concerned about conflicts on the DLL name. (Plus, you *really* don't want mingw libs named "cygfoo-1.dll" do you?) I'd like to see "mgw-.dll" for libtool libs generated on mingw -- but that's a very cygwin-centric idea. As I understand it, the default convention on mingw for DLL names is "lib.dll" or maybe just ".dll". Whatever, I don't really care, and don't want to start a flamewar. Just make sure you don't use "cyg.dll" by accident. :-) --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Proposed libtool patch for MinGW
Bob Friesenhahn wrote: > > The MinGW patch uses lib-.dll for DLL naming, otherwise > the naming is the same as Cygwin. Cool. I'm happy. > This problem has already been anticipated and addressed. Good to know. > The patch looks for an existing Cygwin installation and tries to > overwrite any existing DLL files. Just kidding. :-) Lovely! Sounds perfect. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Deprecate AC_LIBTOOL_WIN32_DLL?
When the AC_LIBTOOL_WIN32_DLL macro was originated, it was necessary to add dllexport decorations to library source code in order to build a DLL. When AC_LIBTOOL_WIN32_DLL was added to configure.in, it enabled a few Windows specific tests, but most importantly, it enabled building libraries as DLLs. Due to binutils enhancements made in the past two years, both Cygwin and MinGW are able to build DLLs without dllexport decorations. In my opinion, this makes AC_LIBTOOL_WIN32_DLL obsolete. The few remaining functions from this macro can be moved elsewhere in libtool.m4 so that packages can automatically support building DLLs. On cygwin, it is completely unnecessary *now* (with latest autoconf, automake, and CVS libtool). The following are sufficient to build DLLs -- no need for any "definitions" to be migrated, AFAIK. At least for cygwin. configure.ac -- AC_INIT(cdll.c) AC_PREREQ(2.52) AM_INIT_AUTOMAKE(dllhelpers-c_autotools, 0.4.0) AC_PROG_CC AM_PROG_LIBTOOL AC_HEADER_STDC AC_OUTPUT([Makefile]) --- Makefile.am --- INCLUDES = -I$(top_builddir) -I$(builddir) -I$(top_srcdir) -I$(srcdir) pkginclude_HEADERS = cdll.h lib_LTLIBRARIES = libcdll.la libcdll_la_SOURCES = cdll.c libcdll_la_LDFLAGS = -version-info 1:0:1 -no-undefined bin_PROGRAMS= usedll usedll_SOURCES = usedll.c usedll_LDADD= libcdll.la The one remaining niggle is this: you *must* specify -no-undefined, or libtool won't even attempt to build a DLL. Yes, it's true that for windows platforms you are not allowed to have any undefined symbols in shared libs (DLLs). But, the requirement that you must actually specify, so to speak, "I hereby represent that the designated source files to be used to build the shared library do not have any undefined symbols" is kinda redundant. either it'll work -- in which case "-no-undefined" was correct, and there WERE no undefined symbols, and you get a DLL. Or it'll fail -- the linker will report that there were "undefined symbols" and you get no DLL. So why bother with requiring the -no-undefined flag? It seems a waste of time to me... But anyway, -no-undefined is a whole separate issue. As far as AC_LIBTOOL_WIN32_DLL, from the cygwin perspective it can be killed. However, given that there are a lot of projects out there that probably have it in their configure.in's already, perhaps you should leave a dummy (empty) definition? Or is that not kosher libtool procedure? --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Deprecate AC_LIBTOOL_WIN32_DLL?
Earnie Boyd wrote:
Is it still true that global variables exported from a dll must have a
dllimport directive for applications? AC_LIBTOOL_WIN32_DLL would
perhaps indicate a package has addressed this issue (by whatever
means) and is therefore dll safe.
While this is required by MSVC, to my knowledge, it is not required by
Cygwin or MinGW anymore since binutils takes care of it automatically.
AFAIK, only cygwin has completely seamless support. Complex array
exports - like long long variables - won't reference properly without a
runtime fixup by the loader. Mind you, as I'm not on the mingw lists, I
may be out of date.
Then provide examples to support your claim.
See attached example. It doesn't work on any officially released version
of binutils on cygwin. From what I understand, the necessary patches
from Egor to support this sort of thing (imported long long variables,
imported structs, etc) involve two pieces (chicken-and-egg):
1) some patches to binutils -- which have not yet been accepted by cgf
(or, at least, even if cgf has accepted them, he hasn't released an
official binutils package that includes the patches)
2) runtime support -- e.g. patches to cygwin1.dll.
cgf hasn't accepted the #1 patches, because they require the #2 patches
to work properly (although Egor went to some pains to insure that
"premature" iclusion of the binutils patches wouldn't *adversely* affect
systems in which runtime support (e.g. #2 patches) were not present)
I had expected the #2 patches to be present in cygwin-1.3.13/14 -- but
AFAIK they have not been added. I think we're still waiting for the
Russian mail system to handle Egor's copyright assignment.
Now, on the mingw side, you guys would need the #1 patches, plus your
own version of the runtime support (in mingwex.dll?) Obviously you
can't use cygwin1.dll...
I've included the most recent copy in my possession of Egor's proposed
patches and his example. However, I haven't been paying a whole lot of
attention -- Egor's patches may have evolved beyond this.
I've BCC'ed cgf and Egor -- hopefully they will chime in to confirm my
statements -- or correct them :-)
--Chuck
begin 664 long_long_example.tar.bz2
M0EIH.3%!6293615A,O``$>__EOVQ`@!?__^___?_Y/___^H``(``A`"`"&`,
M??;MKJV7%#G7=<=""1"A0`!%5!0NQIT-`IHT`35/]5/TQ(AZFQ0]1ZAH`-``
M,@T$`T2:9"GE`-`!D```>H&@'&ADTTR:`!@@#09-``,F@``!DR`:
M")(IB)A$]$U`PU'J-,1L4T9#330-&F@`TTTR`!QH9--,F@`8(`T&30`#)H``
M`9,@&@D1$",F@$T`GH4TU-,C$'J9#0](VIZ1H`T#1H'X@>!\/-]ENC_W37U:
MWC("FB0B)-`*!U./#&U>>GD!4"@%%YYB'-D.9G?<@.0#0(:1:@#!'*0&DP*N
M3QS\9I_+40HV(UMC]ZC9G38@Y53X>M)M#4:Z=?6:Q(P:#)0_5B&UZQD/]&\6
MHB"8Z#AMF6#Q%4D$#S:J&%E>[=?-,S3P:/5*KT551Y,]GTP?>==9]
MZ(L,*:I)%=8:WVPUQ/<'J"?-R%C9^;XJ5KAUIA+%]5-&.VN2+D0RX7D`T"_"
M,ZN[>S;&@T<5MW*50_N!$#5)%208IK'A&@Z.A*D;O0,0`T#1
M6R?W:'XD5'QT43%S!G,+C!",F+B(F[RL1LB:8A@T,_NE[OM"IA%C1N%M2[M8
ML`L`.=)K2C76H%/8:S;(MZTFD)JME"(5074B$PP0;P@]>RBINV^O]%+OY^NT
MIQY@HCR@RH,[+#F^MVDMPV]P*8
M@!I!.B1N\+DQ;C=^K.\Z[[PU68L>`5372^K-:-+J+(\#7*M;8@MHP1DD
M2,@,\"0$ED)%*KFJSYKFA1J,(@)=6^#WG:
MM#7&KN>!%EV\J;)YGA\&9ED;(+XCKL`%TI27`$)HB`*0M5,-N%9UT(L]PQ6N
M$+CW:-)G@&6Y.\[:=M>.^5G'G"TF"!`WE`&*E5'@!T3-M#[\K:(TSYJ8W9*W
M($(W@W*Z=UZ\O&-,&0,S
ME7$`:+8&2@$'A*@%A2+Y-%!>@2.JDGTE.=YXKJPQW-;ZF^%O`(;*$2E<4B$.
M7ADG^01HA:%HP.^V&03AC>(2!M(`G;U[LLS
M#[9'2[^S'?7X6.=.;
M@-A&0&AY\WI87&65R`AO9-5!=#5/Q7W.`!.Y&+T,X;&96X,71%I/'1OV3_&T
M$(ALF34)"F!(!`T"":S`9$FTTQXOW9HL@;`_8MHRA\1R2ATBN4)`2M3S$OC,
MT'W'H][D4B"BM:7!90?:#80L[]5THAD)>'J`]/H$6"3!#/B`7Q`2`5Y2E(!G
M]&Y^ZKA86`0W!#^4P/SU`I5*
M(G&AQ7QQW,4P),&93!!HBE0+K(`C$CV75L,*TN+2I90J-S4NFZ8MI,U)4NTA
M-T*H*-41($@0V5DI6B"M=BP6;2@.LRY^;OYAV4L^=7H/U"F9&.P%-6^KX0Q[
ML;D5N%:8Y>$H`UC&TJ,3V+SV^[_/<=+V8&I(B??"0.WU0[SJN9!OG<[`AXDS
M'73JB0S/6#%Y.N_Q4*95/D"JDSU1=W!NB?A"[FA($DD@0C)R6\>42>(
M&IU9ODKR6A1*IM*QT>5TCSF`W?B9&1#-VMNU=E\(?,)+JF'?$,V\;\76B.`+
M-*
M]JN$J2=N*I3MAQH4[I]EU*&P,`-(8YOG'E.>$ARO7&"'1#@8#$@./,!O]!#M
M`0$@!`#VP.JTJ/(W9(QA"CZ,3ZRP@9^F!/CF/9!I[$LV')B)4;*\OW&DDQ]*
MTW;@/8O?;3P!'PY:)`)8V-@V-KZN_LID?[$/,O(*%^,HS@BK@"U)*K"S@O6D
M*PNML$E=_GH^FU>7QXSZ'!V:1C!B/,&=.7%YJDQ')<,&/N`T%JV&M]41O.O'
M-`*#!+E?-"S]R8QQ!B%)07E^WRY91>(/RG!OT;6BK3@PJH7@S$5%P>F>RQM9
M"4FO*T[[7,YAG"V\WD):J4TV2C.B1"#YW4IO504)(AZ\PP/$"ZMKLLIIHM8.
M*V2#H\"(D*M$CF%8R7#0AKKBPT`7A6_JHMV%5]#AK""+L)>M<:@#3IDL]6BL
M$-2X0C(,9-KMS,E-4R2`R`>:9F[>S(#?>PWL)F'L0;N1GDV!X\^_Q[(5@[0<
M:XVH1+%W>'<%JL7,BR*8O>[[0;0-6+"31@HYM$X%D]-SN.VK`U12RF65U\PS
M"%AAK[J"1>T&DN@;(KE3'15"/K***8L-+8PLOB!+X!JJP5R-PR_TO:]6WV].
M*-W!FYFFL`0=ZQW'AY\0P#;V6F9HIKY:M3J$"N*9VC6_3=TD4OT$)XJI#!7I
M%Z,=`[K:\0+DM]V)=>',?=W$'!H]76JBF/$KO$(INKZ;!-T8GZ!>`%5TUMBR
M@/!Z2U!9J*#8BY@ID-+7-B2"]5_;[]/)=!H2..@N)0EI++MQM.ID)6+C1T.;
M5^J$CXFAL`Z1M`X9$/RE$L;ZPNBTAD/O!:Q)=Z[V=6TLZ9H%F?<
M2'0@8&K#L#%QQ`DFQ1DUVS`7=&I*;D])R]4^6SCA,P\P.ZFOAFMXA&%RN!8,
M1T5HA'RU';JBF9P9?S,;RWLQY+8F1M00"&TUH&($0(!@"X]]T]?
M:CG0Z63,50B'":ADZ4&05UGM6O=LB
M6*VE;R/=!.>BZ3V`@'38'&1$A%3/'8Z-B!N[5BF`E'7DEU[80F=-BBYK!&%(
M4^>9J#"*P:9T%!!"Y8"SDTC]6\HB36D4@(;',2A0Y2+`
M4DM;(HRM6!+=QLM19H(QC`0@D5))CGJ
Re: Deprecate AC_LIBTOOL_WIN32_DLL?
Oops. Looks like the uuencoded version of egor's stuff got scrambled. I've MIME-atteched them here. --Chuck egor-patches-example.tar.bz2 Description: Binary data long_long_example.tar.bz2 Description: Binary data
Cygwin List O' Issues...
This is the first of four messages. There are three significant issues with regards to libtool support on cygwin, even after tonight's inclusion of the patches I submitted. I will describe these problems briefly here, and then start three new subthreads that more completely describe the problems -- complete with examples! - 1. C++ (actually, all tags except C) is broken. This is because the non-C tags extract the list of runtime stdlibs from the compiler, and then explicitly add them to the link command (while using -nostdlibs). This has the effect of requiring that the runtime libs satisfy the "is it dynamic?" check in $file_magic_cmd. Since the cygwin gcc/g++/g77 compiler suite provides only static versions of libgcc, libstdc++, libsupc++, libg2c, etc, this means that ALL shared libs written in those languages fail to build. (Strangely, the C tag does NOT behave this way. Inconsistency...) But the lack of a shared version of the runtime libs should NOT preclude building DLLs on windows -- and in fact, it probably shouldn't preclude them on Linux or Solaris, either (shared libs containing non-PIC runtime code just runs a little slower, that's all). This bug can also affect other platforms (but most platforms' compiler suite supply shared versions of the runtime libs, so the behavior is not as visible). - 2. 'make install DESTDIR=' fails (or relinks to an old version of a dependent lib) when the project contains dependent libraries. This bug affects all platforms. - 3. relinking .exe's. Over and over and over and over. This doesn't really cause project builds to FAIL, but it is HIGHLY annoying -- and has the possibility of an infinite dependency loop. This bug is win32-platform (cygwin, mingw, pw, ...) specific. - Unfortunately, I really have no idea how to fix these problems -- but I thought I'd bring them up here, just in case somebody else had a bright idea. And I'd *really* like to see them corrected before 1.5 is released. :-) Three more messages follow, one for each of the three problems. Please reply to those messages, not this one. Thanks, Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cygwin List O' Issues...[static runtime libs]
1. C++ (actually, all tags except C) is broken. This is because the non-C tags extract the list of runtime stdlibs from the compiler, and then explicitly add them to the link command (while using -nostdlibs). This has the effect of requiring that the runtime libs satisfy the "is it dynamic?" check in $file_magic_cmd. Since the cygwin gcc/g++/g77 compiler suite provides only static versions of libgcc, libstdc++, libsupc++, libg2c, etc, this means that ALL shared libs written in those languages fail to build. (Strangely, the C tag does NOT behave this way. Inconsistency...) But the lack of a shared version of the runtime libs should NOT preclude building DLLs on windows -- and in fact, it probably shouldn't preclude them on Linux or Solaris, either (shared libs containing non-PIC runtime code just runs a little slower, that's all). This bug can also affect other platforms (but most platforms' compiler suite supply shared versions of the runtime libs, so the behavior is not as visible). The attached example is based on libtool's tagdemo test. Demonstrates the severe brokenness of C++ support, at least on cygwin. The problem is, libtool treats C++ and the other tags differently than C. In C, only explicitly listed dependent libraries are tested for 'sharedness'. If any are static, then libtool will refuse to create a shared lib that depends on them. However, this does NOT include the 'stdlib' libgcc. If libgcc.a is static (and there is no shared version) -- libtool doesn't care (in tag C). It creates the sharedlib anyway. In C++, libtool uses -nostdlib in the link command. It (somehow) gets a list of the libs that WOULD be added by g++ if nostdlib were NOT used, and explicitly adds those libs to the link command. Then, the $file_magic_cmd is used to determine if they are all shared. If not, the link "fails" and libtool falls back to building a static lib. I assume the other tags behave like C++. I think the behavior, with respect to the runtime libs, should be like C, not C++. (I'm a bit biased; on cygwin, except for the cygwin kernel itself, all of our gcc-provided runtime libs are available as static libs only. The C++ behavior means that we cannot have ANY C++ shared libs. The current behavior is asymetric. Either ALL tags should extract the stdlibs, use -nostdlib, and add the stdlibs explicitly to the link line -- and check their 'sharedness' via $file_magic_cmd -- or NONE should. This inconsistent behavior is bad. Of course, consistently checking the runtime libs (incl. libgcc) in all tags would make libtool unusable on cygwin. I really think that "The Right Thing" is the following: 1) create a new "official" libtool variable (like $max_cmd_len) that appears in every tag. "check_for_runtime_shlibs". Defaults to "no". "yes" is current behavior (mostly -- see 3). 2) If "no", then avoid -nostdlibs. Behave like the current C tag. This way, static runtimes are ok, even if building a sharedlib. cygwin/windows would set this "no". Maybe linux/solaries. I dunno. 3) If "yes", then all tags should behave like C++ does now (*** including *** the C tag). Figure out the name of the runtime libs for this tag (GNU C++: libgcc libstdc++ libsupc++. GNU F77: libg2c. etc). Use -nostdlibs, but explicitly add the libs back to the command line, and let the "$file_magic_cmd" take over. But I don't have any clue how to implement this... -- To run the example, you need a recent version of autoconf and automake. Also, you need a recent CVS version of libtool. Unpack the archive, and ./bootstrap ./configure --prefix=/usr make You'll see that the build fails to create a sharedlib (on cygwin, since standard linux and solaris installations HAVE shared versions of their runtime libs). To completely clean up, use ./unbootstrap My (partial) results: -- /bin/bash ./libtool --mode=link g++ -g -O2 -o libfoo.la -rpath /usr/lib -version-info 1:0:1 -no-undefined foo.lo *** Warning: linker path does not have real file for library -lstdc++. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libstdc++ and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib/libstdc++.a.2.10.0 *** Warning: linker path does not have real file for library -lgcc. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libgcc and none of the candidates passed a file format test *** using a fi
Re: Cygwin List O' Issues...[make install DESTDIR=]
Geez, I have no idea what happened to the formatting of the preceding message... 2. 'make install DESTDIR=' fails (or relinks to an old version of a dependent lib) when the project contains dependent libraries. This bug affects all platforms. Demonstrates the problems with dependent shared libraries and 'make install DESTDIR=...' This problem affects all platforms, not just cygwin/windows. To run, unpack, and ./bootstrap ./configure --prefix=/usr make make install DESTDIR=`pwd`/inst You'll see that after installing libone into inst/usr/lib, it tries to relink libtwo using -L/usr/lib -lone. But libone is not IN /usr/lib. It's in DESTDIR. And the link fails. Worse, in a real life situation, you could silently SUCCEED, but by linking against an OLD version of libone in that IS in /usr/lib. To completely clean up, use ./unbootstrap --Chuck destdir-relinklib-demo.tar.bz2 Description: Binary data
Re: Cygwin List O' Issues...[relinking exe's]
Oops. Forgot the example. --Chuck relinkprog-demo.tar.bz2 Description: Binary data
Re: Cygwin List O' Issues...[relinking exe's]
Charles Wilson wrote: 3. relinking .exe's. Over and over and over and over. This doesn't really cause project builds to FAIL, but it is HIGHLY annoying -- and has the possibility of an infinite dependency loop. This bug is win32-platform (cygwin, mingw, pw, ...) specific. I notice that Earnie just reported this problem, and proposed a (possible?) solution: http://mail.gnu.org/pipermail/libtool/2002-October/007131.html Demonstrates the problems with executables and shared libraries in the same tree, when using 'make install DESTDIR=...' (Actually, DESTDIR has little to do with this problem, but I really didn't want people using this demo to clobber their /usr/lib... :-0 . This is a cygwin/windows problem; exe's are relinked every time 'make ANYTHING' is run.) To run, unpack, and ./bootstrap ./configure --prefix=/usr make make install DESTDIR=`pwd`/inst You'll see that after installing libone into inst/usr/lib, it relinks program.exe for no apparent reason... While this appears to be a minor issue, it is REALLY annoying, especially if there are a lot of object files. You relink all of the executables in a project EVERY time you do ANYTHING. make check. make install. make dist. make info. ANYTHING. Sometimes, in complicated projects, interlocking dependencies between exe's will cause multiple relinks of both exe's over and over and... This needs fixing. To completely clean up, use ./unbootstrap ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cygwin List O' Issues...
Bob Friesenhahn wrote: You missed mentioning one major bug related to C++. Although libtool warns that it can't create a shared library due to depending on a static library, libtool proceeds to try to build a shared library anyway. This is the worst of the bugs since it results in total failure. Yes, but I only saw that once. I have not verified that it always happens. It might've been a fluke. Have you seen this 'go ahead and build the shared lib even though I just finished complaining that I couldn't' behavior, too? E.g. if you look at the testcase output I reproduced in this message: http://mail.gnu.org/pipermail/libtool/2002-October/007133.html you'll see that libtool complains, and then only builds the static lib. It doesn't try to bull thru and build a shared after complaining. However, if you have independent confirmation... --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cygwin List O' Issues...
Bob Friesenhahn wrote: Yes, but I only saw that once. I have not verified that it always happens. It might've been a fluke. Have you seen this 'go ahead and build the shared lib even though I just finished complaining that I couldn't' behavior, too? Yes, I have. In this particular case, the library depends on another project library (with .la file). Ah -- like IM. The C shared lib builds fine, and then the dependent C++ lib complains, but tries to build anyway? Okay, I'll whip up a simple testcase... -- Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cygwin List O' Issues...[make install DESTDIR=]
David I. Lehn wrote: Could someone -please- either let all of us know how to properly deal with this relink issue or just apply the ltmain.sh patches in the latest Debian libtool package to CVS? Or at least comment on how it should be modified if it's not acceptable. Thanks. Grab the latest diffs from one of: http://packages.debian.org/unstable/devel/libtool.html http://packages.qa.debian.org/libt/libtool.html I'll take a look at them, unless somebody beats me to it. However, that patch is 282k against libtool-1.4.3. It is going to be quite difficult to extract the portion that fixes this problem, and then integrate it into libtool CVS (which has seen massive changes since 1.4.x). Any chance that the debian maintainer could give some advice on how to proceed? --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cygwin List O' Issues...[make install DESTDIR=]
Heh... just need the ltmain.sh part. Use filterdiff from patchutils: zcat libtool_1.4.3-2.diff.gz | filterdiff -i \*ltmain.sh Patch attached. It just patches ltmain.sh... I haven't looked to see if there are other related fixes. Notice also the "exit 1" vs "continue" when a relink fails... is there a good reason not to exit? It does leave the -already-installed- files broken if the relink fails, which can easily be missed unless you know to scan install log files for it. A little digging in the debian bug archives (I'm not a debian user, so this is all new to me...) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=57087 reveals a reference that Ossama Othman (debian libtool maintainer) submitted a similar patch on Jul 10 2002: http://mail.gnu.org/pipermail/libtool-patches/2002-July/002061.html Of course, this IS against 1.4.2...because that's what debian uses. I believe the reason this patch got ignored is because it was submitted during the period in July when the libtool mailing lists were all scrogged (I know, because some of my patches were dropped too. But I was more persistent about them than Ossama was. :-) Anyway, I'll see if I can't update it to apply cleanly to current CVS, and see if it fixes the problem. Let's postpone discussion of the 'exit 1' vs 'continue' until after we have a version that applies to HEAD, and appears to fix the main problem. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cygwin List O' Issues...[make install DESTDIR=]
Charles Wilson wrote: A little digging in the debian bug archives (I'm not a debian user, so this is all new to me...) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=57087 reveals a reference that Ossama Othman (debian libtool maintainer) submitted a similar patch on Jul 10 2002: http://mail.gnu.org/pipermail/libtool-patches/2002-July/002061.html Anyway, I'll see if I can't update it to apply cleanly to current CVS, and see if it fixes the problem. Let's postpone discussion of the 'exit 1' vs 'continue' until after we have a version that applies to HEAD, and appears to fix the main problem. Okay, I've updated Ossama's patch to apply to HEAD, and tested it against the example posted earlier in this thread. It worked properly -- and the contents of the 'installed' .la files were correct, and contained the 'final' paths, not the 'DESTDIR' paths. as required. Okay, now's the time to talk about the 'exit 1' vs. 'continue' when the relink fails... 2002-10-30 Ossama Othman <[EMAIL PROTECTED]> * ltmain.in: add support for installing into temporary staging area (e.g. 'make install DESTDIR=...') --Chuck Index: ltmain.in === RCS file: /cvsroot/libtool/libtool/ltmain.in,v retrieving revision 1.308 diff -u -r1.308 ltmain.in --- ltmain.in 31 Oct 2002 00:52:39 - 1.308 +++ ltmain.in 31 Oct 2002 04:27:43 - @@ -841,6 +841,7 @@ linker_flags= dllsearchpath= lib_search_path=`pwd` +inst_prefix_dir= avoid_version=no dlfiles= @@ -973,6 +974,11 @@ prev= continue ;; + inst_prefix) + inst_prefix_dir="$arg" + prev= + continue + ;; release) release="-$arg" prev= @@ -1189,6 +1195,11 @@ continue ;; + -inst-prefix-dir) + prev=inst_prefix + continue + ;; + # The native IRIX linker understands -LANG:*, -LIST:* and -LNO:* # so, if we see these flags be careful not to treat them like -L -L[A-Z][A-Z]*:*) @@ -2243,6 +2254,14 @@ add="$dir/$linklib" elif test "$hardcode_minus_L" = yes; then add_dir="-L$dir" + # Try looking first in the location we're being installed to. + if test -n "$inst_prefix_dir"; then + case "$libdir" in + [\/]*) + add_dir="-L$inst_prefix_dir$libdir $add_dir" + ;; + esac + fi add="-l$name" elif test "$hardcode_shlibpath_var" = yes; then add_shlibpath="$dir" @@ -2301,6 +2320,14 @@ else # We cannot seem to hardcode it, guess we'll fake it. add_dir="-L$libdir" + # Try looking first in the location we're being installed to. + if test -n "$inst_prefix_dir"; then + case "$libdir" in + [\/]*) + add_dir="-L$inst_prefix_dir$libdir $add_dir" + ;; + esac + fi add="-l$name" fi @@ -4467,7 +4494,7 @@ fi done # Quote the link command for shipping. - relink_command="(cd `pwd`; $SHELL $0 --mode=relink $libtool_args)" + relink_command="(cd `pwd`; $SHELL $0 --mode=relink $libtool_args +@inst_prefix_dir@)" relink_command=`$echo "X$relink_command" | $Xsed -e "$sed_quote_subst"` # Only create the output if not a dry run. @@ -4768,12 +4795,33 @@ dir="$dir$objdir" if test -n "$relink_command"; then + # Determine the prefix the user has applied to our future dir. + inst_prefix_dir=`$echo "$destdir" | sed "s%$libdir\$%%"` + + # Don't allow the user to place us outside of our expected + # location b/c this prevents finding dependent libraries that + # are installed to the same prefix. + # At present, this check doesn't affect windows .dll's that + # are installed into $libdir/../bin (currently, that works fine) + # but it's something to keep an eye on. + if test "$inst_prefix_dir" = "$destdir"; then + $echo "$modename: error: cannot install \`$file' to a directory not ending +in $libdir" 1>&2 + exit 1 + fi + + if test -n "$inst_prefix_dir"; then + # Stick the inst_prefix_dir data into the link command. + relink_comman
Re: Cygwin List O' Issues...[make install DESTDIR=]
Tim Van Holder wrote: On Thu, 2002-10-31 at 05:38, Charles Wilson wrote: Charles Wilson wrote: @@ -2243,6 +2254,14 @@ add="$dir/$linklib" elif test "$hardcode_minus_L" = yes; then add_dir="-L$dir" + # Try looking first in the location we're being installed to. + if test -n "$inst_prefix_dir"; then + case "$libdir" in + [\/]*) This should use [\\/]. IIRC some versions of bash have a bug in their matching that causes them not to match a backslash if it is not doubled. okay, but ... Also, since this is probably an 'is_absolute' check, it should really be [\\/]* | ?:[\\/]* ) (cfr the File System Conventions chapter in the autoconf manual's portability section). This part won't work. It's possible we need a separate case for A:style paths. Because the rest of the patch does: + add_dir="-L$inst_prefix_dir$libdir $add_dir" E.g. prepend the inst_prefix. But A:/inst_prefix/A:/usr/lib is NOT a valid path; for A:style paths you'd need to strip the drive specifier from $libdir before prepending $inst_prefix... Help solicited... --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cygwin List O' Issues...[make install DESTDIR=]
Earnie Boyd wrote: This part won't work. It's possible we need a separate case for A:style paths. Because the rest of the patch does: + add_dir="-L$inst_prefix_dir$libdir $add_dir" E.g. prepend the inst_prefix. But A:/inst_prefix/A:/usr/lib is NOT a valid path; for A:style paths you'd need to strip the drive specifier from $libdir before prepending $inst_prefix... Help solicited... IMO, it's not worth supporting. A requirement of libtool and other autotools is a POSIX shell, so ... err, not that I'm complaining, but POSIX shell doesn't really mean that you have single-root filesystems and use '/' as a separator, does it? I mean, MSYS and cygwin shells both obey that restriction, and I'd be perfectly happy to NOT have to worry about A:this and B:that. But the POSIXness of the shell doesn't really address file system structure. On balance, however, I agree that (a) given that all current windows-based used of the autotools is done from systems that provide some sort of emulated / root and use '/' as the dirseparator, (b) there's probably a LOT of places already in libtool where we implicitly assume both of those things, that it is just too much trouble to worry about a:style paths in this location -- that sort of audit, if it is ever done, should be done as a separate patch and change LOTS of places in the libtool code. Right now it's neither advantageous, necessary, or worth the effort. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Cygwin List O' Issues (take 2): #4 complain-then-attempt-anyway RESOLVED
this problem has been resolved. See patch on libtool-patches. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Cygwin List O' Issus (take 2): #1 static runtime libs
Restating the remaining issues since (a) it's a new month for the mailman archiver (b) some issues have been resolved (yay!) > 1. C++ (actually, all tags except C) is broken. This is because the > non-C tags extract the list of runtime stdlibs from the compiler, > and then explicitly add them to the link command (while using > -nostdlibs). This has the effect of requiring that the runtime libs > satisfy the "is it dynamic?" check in $file_magic_cmd. > > Since the cygwin gcc/g++/g77 compiler suite provides only static > versions of libgcc, libstdc++, libsupc++, libg2c, etc, this means > that ALL shared libs written in those languages fail to build. > (Strangely, the C tag does NOT behave this way. Inconsistency...) > But the lack of a shared version of the runtime libs should NOT > preclude building DLLs on windows -- and in fact, it probably > shouldn't preclude them on Linux or Solaris, either (shared libs > containing non-PIC runtime code just runs a little slower, that's > all). > > This bug can also affect other platforms (but most platforms' > compiler suite supply shared versions of the runtime libs, so the > behavior is not as visible). The attached example is based on libtool's tagdemo test. Demonstrates the severe brokenness of C++ support, at least on cygwin. The problem is, libtool treats C++ and the other tags differently than C. In C, only explicitly listed dependent libraries are tested for 'sharedness'. If any are static, then libtool will refuse to create a shared lib that depends on them. However, this does NOT include the 'stdlib' libgcc. If libgcc.a is static (and there is no shared version) -- libtool doesn't care (in tag C). It creates the sharedlib anyway. In C++, libtool uses -nostdlib in the link command. It (somehow) gets a list of the libs that WOULD be added by g++ if nostdlib were NOT used, and explicitly adds those libs to the link command. Then, the $file_magic_cmd is used to determine if they are all shared. If not, the link "fails" and libtool falls back to building a static lib. I assume the other tags behave like C++. I think the behavior, with respect to the runtime libs, should be like C, not C++. (I'm a bit biased; on cygwin, except for the cygwin kernel itself, all of our gcc-provided runtime libs are available as static libs only. The C++ behavior means that we cannot have ANY C++ shared libs. The current behavior is asymetric. Either ALL tags should extract the stdlibs, use -nostdlib, and add the stdlibs explicitly to the link line -- and check their 'sharedness' via $file_magic_cmd -- or NONE should. This inconsistent behavior is bad. Of course, consistently checking the runtime libs (incl. libgcc) in all tags would make libtool unusable on cygwin. I really think that "The Right Thing" is the following: 1) create a new "official" libtool variable (like $max_cmd_len) that appears in every tag. "check_for_runtime_shlibs". Defaults to "no". "yes" is current behavior (mostly -- see 3). 2) If "no", then avoid -nostdlibs. Behave like the current C tag. This way, static runtimes are ok, even if building a sharedlib. cygwin/windows would set this "no". Maybe linux/solaries. I dunno. 3) If "yes", then all tags should behave like C++ does now (*** including *** the C tag). Figure out the name of the runtime libs for this tag (GNU C++: libgcc libstdc++ libsupc++. GNU F77: libg2c. etc). Use -nostdlibs, but explicitly add the libs back to the command line, and let the "$file_magic_cmd" take over. But I don't have any clue how to implement this... -- To run the example, you need a recent version of autoconf and automake. Also, you need a recent CVS version of libtool. Unpack the archive, and ./bootstrap ./configure --prefix=/usr make You'll see that the build fails to create a sharedlib (on cygwin, since standard linux and solaris installations HAVE shared versions of their runtime libs). To completely clean up, use ./unbootstrap My (partial) results: -- /bin/bash ./libtool --mode=link g++ -g -O2 -o libfoo.la -rpath /usr/lib -version-info 1:0:1 -no-undefined foo.lo *** Warning: linker path does not have real file for library -lstdc++. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libstdc++ and none of the candidates passed a file format test *** using a file magic. Last file checked: /usr/lib/libstdc++.a.2.10.0 *** Warning: linker path does not have real file for library -lgcc. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did chec
Cygwin List O' Issues (take 2): #2 make install DESTDIR= RESOLVED
this problem has been resolved. See patch on libtool-patches. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Cygwin List O' Issues...
Charles Wilson wrote: Bob Friesenhahn wrote: Yes, but I only saw that once. I have not verified that it always happens. It might've been a fluke. Have you seen this 'go ahead and build the shared lib even though I just finished complaining that I couldn't' behavior, too? Yes, I have. In this particular case, the library depends on another project library (with .la file). Ah -- like IM. The C shared lib builds fine, and then the dependent C++ lib complains, but tries to build anyway? Okay, I'll whip up a simple testcase... The testcase is attached, but that's not important. The real problem is that the LACK of a -no-undefined switch doesn't prevent building a sharedlib on cygwin/mingw. That's becauss of this change (one of mine. Sigh.) 2002-05-31 Charles Wilson <[EMAIL PROTECTED]> * libtool.m4: ... For all tags, (and host=cygwin) set allow_undefined_flag="" so that the --auto-import magic works properly. ... It appears that this bogosity is no longer necessary, and in fact now causes problems. The attached patch reverts. I will also post this to libtool-patches. 2002-11-01 Charles Wilson <[EMAIL PROTECTED]> * libtool.m4 (AC_LIBTOOL_LANG_CXX_CONFIG): restore setting allow_undefined_flag=unsupported for cygwin and mingw. (AC_LIBTOOL_PROG_LD_SHLIBS): ditto, for both "normal" gcc/ld and for the (unmaintained?) MSVC case. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/libtool.m4,v retrieving revision 1.273 diff -u -r1.273 libtool.m4 --- libtool.m4 31 Oct 2002 00:52:39 - 1.273 +++ libtool.m4 1 Nov 2002 01:34:18 - @@ -2645,6 +2650,7 @@ # _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless, # as there is no search path for DLLs. _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir' +_LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported _LT_AC_TAGVAR(always_export_symbols, $1)=no if $LD --help 2>&1 | egrep 'auto-import' > /dev/null; then @@ -2657,6 +2663,7 @@ mingw* | pw32* ) _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir' +_LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported _LT_AC_TAGVAR(always_export_symbols, $1)=no if $LD --help 2>&1 | egrep 'auto-import' > /dev/null; then @@ -4649,6 +4656,7 @@ # _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless, # as there is no search path for DLLs. _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir' + _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported _LT_AC_TAGVAR(always_export_symbols, $1)=no if $LD --help 2>&1 | egrep 'auto-import' > /dev/null; then @@ -4877,6 +4877,7 @@ # hardcode_libdir_flag_spec is actually meaningless, as there is # no search path for DLLs. _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=' ' + _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported # Tell ltmain to make .lib files, not .a files. libext=lib # FIXME: Setting linknames here is a bad hack. complain-then-attempt-anyway-demo.tar.bz2 Description: Binary data
Cygwin List O' Issues (take 2): #3 relinking exe's
Restating the remaining issues since (a) it's a new month for the mailman archiver (b) some issues have been resolved (yay!) > 3. relinking .exe's. Over and over and over and over. This doesn't > really cause project builds to FAIL, but it is HIGHLY annoying -- > and has the possibility of an infinite dependency loop. > > This bug is win32-platform (cygwin, mingw, pw, ...) specific. I notice that Earnie just reported this problem, and proposed a (possible?) solution: http://mail.gnu.org/pipermail/libtool/2002-October/007131.html Demonstrates the problems with executables and shared libraries in the same tree, when using 'make install DESTDIR=...' (Actually, DESTDIR has little to do with this problem, but I really didn't want people using this demo to clobber their /usr/lib... :-0 . This is a cygwin/windows problem; exe's are relinked every time 'make ANYTHING' is run.) To run, unpack, and ./bootstrap ./configure --prefix=/usr make make install DESTDIR=`pwd`/inst You'll see that after installing libone into inst/usr/lib, it relinks program.exe for no apparent reason... While this appears to be a minor issue, it is REALLY annoying, especially if there are a lot of object files. You relink all of the executables in a project EVERY time you do ANYTHING. make check. make install. make dist. make info. ANYTHING. Sometimes, in complicated projects, interlocking dependencies between exe's will cause multiple relinks of both exe's over and over and... This needs fixing. To completely clean up, use ./unbootstrap relinkprog-demo.tar.bz2 Description: Binary data
Re: Cygwin List O' Issus (take 2): #1 static runtime libs
Resolved? See patch on libtool-patches. There are a few extensions to that patch that could be added, but they will change current behavior -- and will affect platforms I can't test on. So I'm not the one to propose them. I took the conservative approach with the patch -- "do no harm". It fixes the cygwin/C++ problem, while minimally disturbing other architectures and tags. In the future, other architectures could join cygwin and set _LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=yes in various tags. Further, somebody "in charge" might decide that C should behave more like C++ -- in that it should define an output_verbose_link_cmd call AC_LIBTOOL_POSTDEP_PREDEP([tagname]) (which would add the "hidden" libs to $postdeps, $predeps, etc), and change all link commands (for tag=C) to use -nostdlibs But that's a radical change and not one I'm comfortable making on my own -- and AC_LIBTOOL_POSTDEP_PREDEP really should get a shakedown on other platforms, restricted to tag=C++, first. Currently, the patch does the minimum required to solve cygwin's C++ problem and not hurt other platforms/tags. But the infrastructure is there to expand to other tags, and platforms. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions, was RE: solving of name conflicts in included . a]
Boehne, Robert wrote: and any WIN32 specific code can be only included when WIN32 is detected at run time (via ". some_here_document_containing_win32_shellfuncs") Until all the Autotool maintainers decide to abandon support for non-shell function bourne shells we need to support them as well. No flames from me. I actually brought this issue up when I submitted my patches: Charles Wilson wrote: Since $file_magic_cmd is called with different arguments ($file_magic_test_file in one place, \"\$potlib\" in another), we need some construct that can take an argument, and then run a sequence of shell commands on it. The only choices I see are a shell function, or use a HERE document to generate an ancillary script. Seems like a shell function is the obvious choice -- but I notice that libtool doesn't seem to use them. Is there a policy against shell functions? (I hope not...) I can rework the patch as needed to support Robert's proposed change, but what is the best way to do that? A separate script that is installed by libtoolize alongside ltmain.sh (on all platforms), or a here doc that is generated during configure? And what if you're trying to build for cygwin, using a cross compiler on buildhost X? We need the shell function/external script when building FOR cygwin, but the buildhost's shell might not support them... Now, we can simply say: cygwin targetted cross compilers using libtool are not supported on ancient hosts with no shellfunction support. Or, every "shell function" can be a separate script...blech. See Paragraph 1 above. - I'm sorry to see that the autoconf people have decided against shell functions, but I agree that libtool needs to remain "at the same level" as autoconf. So, if autoconf doesn't use 'em, neither should we (except in special circumstances, rigidly separated from "general" use. E.g. Robert's "separate file" solution.) Point of order: the shell function needed for windows support is not *used* (e.g. called) by any other platform. However, as currently configured it is *parsed* on every platform -- thus leading to errors on those platforms whose shells don't support shellfunctions. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions, was RE: solving of name conflicts in included . a]
On the other hand, autoconf's most recent release sez (as ADL pointed
out before I finished composing this message):
** Plans for 2.56
...
- shell functions
Shell functions will gradually be introduced, probably starting with
Autotest. If you know machines which are in use that you suspect
*not* to support shell functions, please run the test suite of
Autoconf 2.55 on it, and report the results to
[EMAIL PROTECTED]
-
When will libtool-1.5 be released? Before or after ac-2.56? (given
that ac-2.55 will be released next week).
Assuming that the autoconf people have not repudiated their plan to
integrate shell functions starting in 2.56, then the decision to use
them in libtool or not could be better stated as
"Shall libtool-1.5 require autoconf-2.56?"
Because, if autoconf-2.56 uses shell functions, then if libtool-1.5
requires ac-2.56 then ipso facto libtool-1.5 is also permitted to use
shell functions.
The next question is how gracefully should libtool degrade if the
buildhost shell doesn't support shell functions. Blindly adding them
into ltmain.sh or into the macros in libtool.m4 (like my patch did) --->
breaks libtool completely even on platforms that don't themselves use
the shell functions (if the platform's shell doesn't support ...)
That's probably not a good idea during the transitional period (assuming
there will be a transition at all, e.g. assuming ac-2.56 will follow
through on its promise to start using shell functions)
Searching the libtool archives reveals that this topic has come up
before. Somebody (Gary?) once suggested using some mechanism to either
declare the shell functions, or create separate standalong scripts for
each shell function on buildhosts that don't support them...for example:
libtoolize will copy into the :
/ltmain.sh
/ltshfunc.sh
during configure, while building libtool:
if shell functions supported, then
. ltshfunc.sh
else
and turns it into a set of separate, appropriately
named, scripts>
endif
Downside: in the "use shell funcs" case, libtool would contain code like
result=`win32_libid $bob $george`
which works fine when win32_libid is a shell function. But if we have a
script called "win32_libid" in the same directory where libtool is, then
that won't work. You'd need to do
tdir=`echo "$0" | sed 's%[\\/][^\\/][^\\/]*$%%'`
test "x$tdir" = "x$0" && tdir=.
sdir=`cd $tdir; pwd`
sdir="${sdir}/"
...
result=`${scriptdir}win32_libid $bob $george`
or somesuch.
--Chuck
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions, was RE: solving of name conflicts in included . a]
Bob Friesenhahn wrote: "Shall libtool-1.5 require autoconf-2.56?" I don't see that introducing shell functions into libtool has any bearing on the version of autoconf that libtool requires. The argument you pose is political rather than technical. Yes. The decision itself is a political one. "Shall libtool (and autoconf) continue to support museum pieces?" I was just posing the question in a different way -- trying to make the point (poorly, apparently) that the decision has already been made for us. I really should've said "Shall libtool-1.5 be forever frozen at autoconf versions < 2.56" which is not quite the same thing. And of course, the answer to that question is no. The only question that needs answering is if using shell functions will hurt libtool users, or if it will help libtool users. There's a novel concept. :-) Libtool's configure script is a wopping 584K. The configure script for ImageMagick is 1.1M, about half of which may be blamed on libtool. It is not uncommon these days to find packages where the configure script dwarfs the rest of the package. If shell functions can allow configure scripts which are 1/10th the size, and run 5X as fast, then perhaps that should take precedence over the ability to run libtool on a V7 system in a museum. Well, I like shell functions. And I think this whole decsion has been taken out the libtool-maintainers' hands, given the decision of the autoconf team. Since autoconf (>= 2.56) will only work on systems whose shells support shell functions, and libtool requires autoconf, then libtool will only work on those same systems. Which means shell functions are available and we *can* use them. Whether we *should* use them or not is then a technical decision, resting on the arguments you put forward above. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions, was RE: solving of name conflicts in included.a]
[EMAIL PROTECTED] wrote: Let them install BASH and get out of our way. Both of them. Bash uses configure. And so does ash :-( which was my first thought for working around this problem. On the other hand, is it so terrible to ask that those who wish to continue using systems with 20-year-old shells build bash/ash on a modern system using a cross-compiler? One massive painful thing -- for "both" of those users, as Bruce puts it -- and then they have a modern shell on their ancient machine, and then these "two" users will be able to continue using modern autoconf/libtool tools. (assuming "modern" versions start using shell functions). As far as "who did it first" -- does it really matter? This isn't about finger pointing, it's about solving problems. Right now, one of the problems is the gigantic size and slow runtime of configure. Both problems will be helped to a certain degree (unknown how much) by the use of shell functions. And some problems -- like the one addressed by win32_libid -- can be solved (cleanly) by shell functions, or very badly by the use of additional shell scripts and/or HERE documents. Blech. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS libtool package issues
There are a number CVS libtool package issues which should be
addressed before libtool 1.5 is released.
Also, check the 'In the Near Term" section here:
http://www.gnu.org/software/libtool/future.html
Of the four bullet points, AFAIK only one ("Robert Collins...") has
actually been achieved.
1) 'make distclean' does not work unless 'make test' has
been performed since otherwise there are no Makefiles
in the test directory.
Dunno. I always run make check.
3) The Makefile.am files used by the libtool demos are not
compatable with any version of Automake newer than 1.6.2
due to this error:
Makefile.am: object `longer_file_name_hello.lo' created both with
libtool and without
Makefile.am: object `longer_file_name_foo.lo' created both with
libtool and without
4) With Autoconf 2.56 and Automake 1.7.1, automake fails with the
error:
tests/Makefile.am:73: FFLAGS was already defined in condition TRUE,
which implies condition HAVE_F77_TRUE ...
configure.ac:111: ... `FFLAGS' previously defined here.
Are you sure? I've seen both messages, but I always thought they were
warnings, not errors. I had no problems building and testing, even
after the appearance of those messages. (cygwin-over-w2k)
--Chuck
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
