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 file 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: 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: cygbase-number.dll (where number= 'current' - 'age') libbase.dll.a (import lib) libbase.la(libtool lib) libbase.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 mgwbase-number.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 libvarious stuff.dll or maybe just various stuff.dll. Whatever, I don't really care, and don't want to start a flamewar. Just make sure you don't use cygstuff.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 libbase-number.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?
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==1A0`!%5!0NQIT-`IHT`35/]5/TQ(AZFQ0]1ZAH`-`` M,@T$`T2:9GE`-`!D```H@'ADTTR:`!@@#09-``,F@``!DR`: M)(IB)A$]$U`PU'J-,1L4T9#330-F@`TTTR`!QH9--,F@`8(`T30`#)H`` M`9,@@D1$,F@$T`GH4TU-,C$'J9#0](VIZ1H`T#1H'X@!\/-]ENC_W37U: MWC(FB0B)-`*!U./#UGD!4@%%YYB'-D.9G?@.0#0(:1:@#!'*0DP*N M3QS\9I_+40HV(UMC]ZC9G38@Y53XM)M#4:Z=?6:Q(P:#)0_5BUZQD/]\6 MHB8Z#AMF6#Q%4D$#S:J%E[=?-,S3P:/5*KT551Y,]GTP?==9]C##$2 MZ(L,*:I)%=8:WVPUQ/'J?-R%C9^;XJ5KAUIA+%]5-.VN2+D0RX7D`T_ M,ZN[S;@T5MW*50_N!$#5)%208IK'A@Z.A*D;O0,0`T#1C[E\FQ9F0 M6R?W:'XD5'QT43%S!G,+C!,F+B(F[RL1LB:8A@T,_NE[OMIA%C1N%M2[M8 ML`L`.=)K2C76H%/8:S;(MZTFD)JME(5074B$PP0;P@]RBINV^O]%+OY^NT MIQY@HCR@RH,[+#F^MVDMPV]P*8YVV]39H7,-@!'?N.SO:H3F*,LPR3*(D: M@!I!.B1N\+DQ;C=^K.\Z[[PU68L`5372^K-:-+J+(\#7*M;8@MHP1DDQ9 M2,@,\0$ED)%*KFJSYKFA1J,(@)=6^#WG:Y6R.@4M-I/TV*8!85A*,SM:7* MM#7KN!%EV\J;)YGA\9ED;(+XCKL`%TI27`$)HB`*0M5,-N%9UT(L]PQ6N M$+CW:-)G@6Y.\[:=M.^5G'GTF!`WE`*E5'@!T3-M#[\K:(TSYJ8W9*W M($(W@W*Z=UZ\O-,0,SYUR-(\L74H=*9(0!@!TD2-7()JU;4683WPJIJ ME7$`:+82@$'A*@%A2+Y-%!@2.JDGTE.=YXKJPQW-;ZF^%O`(;*$2E4B$. M7ADG^01HA:%HP.^V03AC(2!M(`G;U[LLSZ$D`1ZTD#.]D#0;4G'N^ZF/ M#[9'2[^S'?7X6.=.;G-9J57*TN]T?$,;NM*8G7O298(Q\LB+.0 M@-A0AY\WI8765R`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][D4BBM:7!90?:#80L[]5THAD)'J`]/H$63!#/B`7Q`2`5Y2E(!G M]Y^ZKA86`0W!#^4P/SU`I5*E`'0)I+5;4QBY(C:9FU?G8KZ2IQAD/(YV] M(GAQ7QQW,4P),93!!HBE0+K(`C$CV75L,*TN+2I90J-S4NFZ8MI,U)4NTA M-T*H*-41($@0V5DI6BM=BP6;2@.LRY^;OYAV4L^=7H/UF9.P%-6^KX0Q[ ML;D5N%:8Y$H`UCTJ,3V+SV^[_/=+V8I(B??0.WU0[SJN9!OG[`AXDS M'73JB0S/6#%Y.N_Q4*95/DJDSU1=W!NB?A[FA($DD@0C)R6\42(/V=` MIU9ODKR6A1*IM*QT5TCSF`W?B91#-VMNU=E\(?,)+JF'?$,V\;\76B.`+ M-*G?T;_C`L::@9H3X+S0X!L7$##=[P=6=RJ?-?_8'T2*7#%#;$U)EF\ M]JN$J2=N*I3MAQH4[I]EU*P,`-(8YOG'E.$ARO7'1#@8#$@./,!O]!#M M`0$@!`#VP.JTJ/(W9(QACZ,3ZRP@9^F!/CF/9!I[$LV')B)4;*\OWDDQ]* MTW;@/8O?;3P!'PY:)`)8V-@V-KZN_LID?[$/,O(*%^,HS@BK@U)*KS@O6D M*PNML$E=_GH^FU7QXSZ'!V:1C!B/,=.7%YJDQ'),/N`T%JVM]41O.O' M-`*#!+E?-S]R8QQ!B%)07E^WRY91(/RG!OT;6BK3@PJH7@S$5%PFRQM9 M4FO*T[[7,YAGV\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[J1TDN@;(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?W)UMEIX M2'0@8K#L#%QQ`DFQ1DUVS`7=I*;D])R]4^6SCA,P\P.ZFOAFMXA%RN!8, M1T5HA'RK6)C;9YU';JBF9P9?S,;RWLQY+8F1M00TUH($0(!@X]]T]?
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
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 file magic. Last file
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...
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 12 + exit 1 + fi + + if test -n $inst_prefix_dir; then + # Stick the inst_prefix_dir data into the link command. + relink_command=`$echo $relink_command | sed +s%@inst_prefix_dir@%-inst-prefix-dir $inst_prefix_dir%` + else + relink_command=`$echo $relink_command | sed s%@inst_prefix_dir@%%` + fi + $echo $modename: warning: relinking \`$file' 12 $show $relink_command if $run eval $relink_command; then : else $echo $modename: error: relink \`$file' with the above command before installing it 12 - continue + exit 1 fi fi
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' 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 21 | 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 21 | 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 21 | 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
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]
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: CVS libtool package issues
Bob Friesenhahn wrote: 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. This page seems to be rather out of date. Okay, but it duplicates a lot of what is in the TODO file (speaking of which, TODO needs a housecleaning...) It is not always clear what is a warning and what is an error, regardless, libtool should work cleanly with the Autoconf Automake which are current at the time of release. Fair enough. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
DESTDIR installs
Ummm, if I understand your problem, this has been fixed in CVS HEAD: http://mail.gnu.org/pipermail/libtool-patches/2002-November/002159.html and following thread. However, it was never committed on the 1.4.x branch, even though it was submitted prior to the 1.4.3 release. Unfortunately, 1.4.x is now officially dead, so if you're using that series you'll need to patch your libtool yourself, using Ossama's patch from http://mail.gnu.org/pipermail/libtool-patches/2002-July/002061.html --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Mingw-users] Re: Solving the relink exe's libtool problem[take3]
Bruce Korb wrote: Earnie Boyd wrote: This patch passes my test. What do we need to do to get this accepted into libtool cvs HEAD? + newargz[0] = xstrdup(/bin/sh); This may not be the shell and there is no point allocating it. It is fine to use it from static memory. Okay, the second comment (use static string, not allocated memory) is easy enough. But what's the best way to use the shell? Do a unquoted replacement (EOF, not EOF) e.g. ... newargz = XMALLOC(char *, argc+2); EOF $echo $cwrappersource EOF newargz[0] = \$SHELL\; EOF $echo $cwrappersource EOF newargz[1] = fnqualify(argv[0]); ... ? --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1,000 year backward compatability of tools
Bruce Korb wrote: Paul Eggert wrote: Alex Hornby [EMAIL PROTECTED] writes: On a related note, does the restriction of not using shell functions in autoconf macros still remain, For Autoconf itself, we still avoid shell functions. But of course you can use shell functions in your own macros, if you don't care about porting to shells that lack shell functions. Personally I'm becoming more inclined to start using shell functions. Perhaps in Autoconf 3. If my memory serves, GCC has finally said, Enough with KR already! but everyone is still saying, You first. and No, after you. It's silliness. The only people squawking are the ones jealously looking out for someone who maybe might be using the stuff. Sweating KR-isms and copying shell text to avoid functions is a waste of developer time. Even if money isn't paid, there's still a big cost. It's past time. I think libtool went first. I submitted a patch a few months ago to help re-enable building DLLs on cygwin; that patch contained a shell function. This spawned a huge debate which meandered across the various autotool lists (this debate, I note, seems to crop up about every six months on one autotool list or another...) Eventually, the patch was accepted, and libtool (CVS HEAD) now has a shell function in it. I think the winning argument was as follows: for archaic systems whose shell does not support shfuncs, 'somebody' should create a snapshot of bash with a frozen autotool version. then, if you needed to use new autotools on that ancient system, then simply download and install the bootstrap bash package, and then use that. Recall that just because NEW autotools will/may use shell functions, that doesn't retroactively break all existing packages that are already out there. So, the poor Ultrix user will only need bootstrap bash if she wants to compile new software that uses new autotools -- otherwise, she's fine as is. However, AFAIK, nobody has actually created that bootstrap bash package, or if they have, it has not been widely publicized. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: bug in libtool --mode=install with EXEEXT
This is obviously correct; please check in. I'm sorry I missed this,
when I submitted the original patch. I'll go hide, now.
--Chuck
Schleicher Ralph (LLI) wrote:
2003-02-27 Ralph Schleicher [EMAIL PROTECTED]
* ltmain.in: Only append a dot to the wrapper script when
building on cygwin/MSYS (check for $build, not $host).
diff -u libtool-20030219/ltmain.in.orig libtool-20030219/ltmain.in
--- libtool-20030219/ltmain.in.orig Tue Feb 18 18:12:39 2003
+++ libtool-20030219/ltmain.in Thu Feb 27 14:35:29 2003
@@ -5379,7 +5379,7 @@
# To insure that foo is sourced, and not foo.exe,
# finese the cygwin/MSYS system by explicitly sourcing foo.
# which disallows the automatic-append-.exe behavior.
- case $host in
+ case $build in
*cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
*) wrapperdot=${wrapper} ;;
esac
@@ -5417,7 +5417,7 @@
# To insure that foo is sourced, and not foo.exe,
# finese the cygwin/MSYS system by explicitly sourcing foo.
# which disallows the automatic-append-.exe behavior.
- case $host in
+ case $build in
*cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
*) wrapperdot=${wrapper} ;;
esac
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and cl
Braden McDaniel wrote: It used to be supported by libltdl, but when GCC implemented the auto-import capability, Gary removed the support. I think it was a bad idea to remove the support. There are plenty of reasons to use the Microsoft compiler rather than GCC under Windows since GCC has limited functionality under Windows. Any chance you recall the last release to include that support? 1.4.3 g Seriously, try CVS prior to May 31, 2001. That's when the first of the auto-import stuff went into CVS AFAIK. But, for the love of pete, PLEASE do not re-add that cruft willy-nilly. Keep it nicely segregated from mingw, cygwin, and pw support; I don't want to see ANY of that creep back into the cygwin execution path. This will require significant refactoring of the code -- especially since May 31, 2001 was ALSO prior to the multi-tag changes. Which means that the old support knows nothing about multiple tags, in addition to its commingled status wrt cygwin/mingw/gcc. Resurrecting that code will be a large chunk of work. Unfortunately, I don't have the time to rebuild on cygwin after every commit to make sure stuff didn't get broken. PLEASE be careful not to disturb the other windows-based compilers. This talk of mucking around with libtool on my platform (e.g. windows; cl/mingw/cygwin/pw are all somewhat related in the underlying OS) this close to 1.5's release gives me the screaming heebie-jeebies. I've waited over two years for a decent libtool -release- on cygwin that *really* supports building shared libs transparently and in the unix way...it works now, and I'd be terribly pissed to see it broken at T-3weeks. With respect to Bob, Gary's decision to remove it was correct at the time. Unmaintained, untested code should NOT simply be carried along because it might be needed later. It would have made development on actual used and tested platforms [e.g. cygwin/mingw] for the past 21 months much harder, for very little benefit. The old code will always be there -- in CVS archives -- if anybody wants to up-port it. But no one did, and no one was available, and apparently no one needed it until now. That's 21 months of pain, avoided. I'm cool with that. Also wrt Bob, concerning mingw vs cl: IMO, if you're using cl and relying on its non-standard extensions to C and C++, then you are obviously not trying to write portable code. In that case, you should simply use the MSVC support for building DLLs and static libs, and NOT use libtool or autoconf or automake at all. Since you're not worried about portability, use the tools MS provides to make your life easier; why go thru the pain of creating a *build* system that is portable, when your *code* is not? The autotools are about portability. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: DESTDIR trouble
Bernd Jendrissek wrote: I realise this may be an FAQ candidate, but I haven't gotten any joy out of google or the mail.gnu.org archives. My problem: I have, say, guile 1.4 installed, with libguile.so.9 in /usr/lib. Now I've tried to build guile 1.6.4 with a DESTDIR=foo install, but then things get linked with the guile libs *in /usr/lib*! (I think most of you should be familiar with the scenario.) So I have new libraries linked to the old ones. I have libtool 1.5 installed, and it *doesn't* work properly with DESTDIR. I've seen DESTDIR-related messages in the archives, but they always seem to wind down with this is fixed in 1.5 or something to that effect. Did you see this message? It details what IS and is NOT fixed in 1.5. with regards to DESTDIR. http://mail.gnu.org/archive/html/libtool/2003-05/msg00026.html Other than identifying the problem, I don't really know how to correct the remaining issue. But in this message http://mail.gnu.org/archive/html/libtool/2003-05/msg00022.html I posted a test case that demonstrates the issue; if anybody can figure out how to fix libtool, they can test their fix with this small testcase rather than trying to build guile. :-) -- Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Is libtool being maintained at all?
Scott James Remnant wrote: On Sun, 2003-07-06 at 11:18, Dalibor Topic wrote: http://ftp.debian.org/debian/pool/main/libt/libtool/libtool_1.4.3-10.diff.gz etc. As the Debian Libtool package maintainer, I'd like to know whether it would be possible to gain CVS commit access to the libtool repository. Not necessarily to merge in our (fairly hefty, now) patch, but to at least help with some of the work. NOTE: the following is not authoritative; it's just my (informed?) opinion... I'd guess not. It appears that debian's changes are all on the 1.4.3 branch, which is permanently and irrevocably dead. We really really really don't want to provide anybody with more excuses to stay on 1.4.3. If John Q. Developer wants new-and-improved libtool functionality, then we want JQD to use 1.5.x. We don't want to re-open the 1.4.x branch for more fixes, since that will just keep JQD using that dead branch longer. Death to 1.4.3! -- Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
Alexandre Duret-Lutz wrote: R For several _YEARS_, packagers for software were very troubled because R of not-completely-working staging install. I really hope this issue can R be sorted out, once and for all. One way to address the once for all part would be to write a test case. I don't think this ia test case that can be made part of the testsuite, unfortunately. The problem is, you ONLY see the problem if all of the following are true: 1) you have multiple dependent constructs in a single project -- e.g. a sharedlib and an executable that depends on it, or two sharedlibs where one depends on the other, etc. 2) you are doing a DESTDIR install 3) you have PREVIOUSLY done a real install -- so that the sharedlib on which the second construct depends already exists in the final destination. Then, relinking will pick up the pre-existing sharedlib in the final location, rather than the one in the DESTDIR. In order to make #3 true, you have to muck with things outside of the testsuite tree...which kinda violates the whole premise of self-contained testing. But, if anyone would like to give it a try, they are welcome to adapt any of the following standalone testcase if it is useful. http://mail.gnu.org/archive/html/libtool/2003-05/msg00022.html --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: DESTDIR trouble
Bernd Jendrissek wrote: I get this: /tmp/destdir-relinklib-demo-1.0.1: LD_LIBRARY_PATH=/tmp/relinkdemo/usr/lib ldd /tmp/relinkdemo/usr/lib/libtwo.so.1.1.1 libone.so.2 = /tmp/relinkdemo/usr/lib/libone.so.2 (0x40002000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x40012000) libc.so.6 = /lib/libc.so.6 (0x4001a000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) Is there any reason why I shouldn't just apply this patch to my libtool? Um, I think there is a reason -- I think that this patch could cause non-DESTDIR patches to pick up incorrect dependencies. We don't want to rob peter to pay paul, here. --Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Is libtool being maintained at all?
Bob Friesenhahn wrote: A fork is totally unnecessary. Libtool maintainers seem to ebb and flow like the tide. Perhaps we are simply in an ebb period at the moment. Yes, it appears so. Personally, I was suprised at the relative lack of activity after 1.5.0 was released. (Sure, there were patches -- almost entirely related to the darwin port in my non-scientific survey -- but no new releases). libtool-1.5.0 came out on 14 Apr 2003 -- that's three months ago. given that it was the culmination of 2.5 years of work, and is a major departure from the 1.4.x codebase, I expected a flurry of bug reports and patches (which we got) followed by a flurry of rolling releases (which we didn't get). 1.5.1, 1.5.2, 1.5.3, 1.5.4 every two weeks or so, until the bugreports tapered off. But I guess the maintainers figured Whew, that's done. Now we can rest for a while. Maintainers, please come back. We like you. :-) -- Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
relink command needs --tag
I'm not sure exactly where in libtool to put this, so I can't provide a patch. However, see the attached testcase... This testcase -- and the original problem -- were discovered on a cygwin system (so you'll see references to .dll's) but the problem should also occur on linux/etc. I stumbled on this problem trying to build ncurses with the newly-added libtool support. Ncurses uses the system libtool script and does NOT build its own copy. Further, ncurses does NOT use automake; rather it uses autoconf and hand-tooled Makefile.in's. The issue crops up because: 1) the system libtool knows that CXX should be g++ 2) ncurses configury detects CXX as c++ (because old-style autoconf-2.13 searches in this order: c++ g++ , but new-style autoconf-2.57, used to build the system libtool, searches for g++ first.) So, you end up with a compile command of /usr/bin/libtool c++ ... but where the default compiler (as far as libtool is concerned) for C++ code is 'g++'. In this circumstance, libtool requires the --tag=CXX flag. That's fine; the hand-tooled Makefile.in's ensure that libtool gets what it wants. The problem is, when doing 'make install' the C++ library is relinked, and thus the relink_cmd is triggered. And the relink_cmd does NOT contain --tag=CXX, even tho the original command that linked the uninstalled library in the first place DID have --tag=CXX. And so it breaks. Somehow, the relink_cmd that is stored in the uninstalled la file must propogate the --tag argument (if any) -- but it doesn't. You can see this by unpacking the attached test case. It is a bit contrived, and does some bad automake things -- but I needed to do that in order to make the test case self-contained. My test case does not use 'your' system libtool -- but demonstrates the same problem I found with ncurses+systemlibtool. After unpacking the testcase, run the bootstrap script. Then, configure as usual. Next, do: 'make CXX=c++' This works fine -- and you'll see that C++ files are compiled and linked using --tag=CXX. (I assume that on 'your' system, you have both g++ and c++ [where c++ could be a symlink to g++], and that autoconf is 2.57 or above. That way, the libtool thus constructed will believe that g++ is the default compiler thanks to the autoconf-2.57 compiler search order.) Now, inspect the cxx/libcxxdll.la file -- you'll see that the relink_cmd variable does NOT contain --tag. Finally, do: 'make install DESTDIR=/tmp' The install fails, because of the missing --tag. Can someone smarter than me please fix this, so that --tag= is included in relink_cmd whenever it is passed on the original --mode=link command line? -- Chuck no-tag-demo.tar.bz2 Description: BZip2 compressed data ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS libtool fails under MinGW 1.0
Bob Friesenhahn wrote: Libtool (probably the 1.5 release) did used to work under MinGW. A recent libtool from CVS does not work properly under MinGW. The symptom is that libtool checks a DLL's validity using the 'file' command. This fails so use of the DLL library is rejected. The MinGW MSYS environment does not provide a 'file' command so libtool shouldn't be trying to use file magic tests. It is questionable if it is really necessary to test a file with a .DLL extension to verify that what it most likely is. I assume that a recent Cygwin enhancement to be more exacting is causing MinGW builds to fail. Perhaps this stanza (around line 2109 in libtool.m4): cygwin* | mingw* | pw32*) # win32_libid is a shell function defined in ltmain.sh lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL' lt_cv_file_magic_cmd='win32_libid' ;; should be split up into separate mingw and cygwin sections. I still think it's a good idea to disallow inclusion of .a's into dlls (unless they are local convenience libs) because of the havoc that auto-EXport can wreak. And cygwin users have proven over and over to be a bit too cavalier about renaming files specifically to fool the compiler for me to be comfortable with a test file name only approach. (And is a given '.a' file really a static library, or the import stub of a DLL?) So, for cygwin, I think win32_libid should still be used. But mingw/MSYS is free to do whatever they like -- including providing a port of 'file'... -- Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool HEAD doesn't build on cygwin
loader-loadlibrary.c: In function `sys_wll_open': loader-loadlibrary.c:98: error: dereferencing pointer to incomplete type loader-loadlibrary.c:104: error: dereferencing pointer to incomplete type loader-loadlibrary.c:109: error: dereferencing pointer to incomplete type This is because the windows code accesses cur-module where cur is of **opaque** type lt_dlhandle. It appears, to me at least, that sys_wll_open() should be moved to somewhere on the inside so that it has access to these opaque definitions; but I'm not really sure where Gary is going with this refactoring. So I figured I'd just raise the issue on the list, and let Gary fix it. :-) -- Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Ping: Cygwin libtool / assembler problem with -DPIC
Gerrit P. Haase wrote: Noah Misch wrote: There was a thread about this general topic awhile ago. That GMP actively uses -DPIC to select the correct assembly came up: http://lists.gnu.org/archive/html/libtool/2003-01/msg00060.html I saw that -DPIC was used on Cygwin to compile assembly and it couldn't be linked. Also I read in the GMP sources somewhere that libtool adds this flag where it is a noop on Cygwin when not compiling assembler code where it breaks things, so the conclusion was to remove the flag entirely when platform is Cygwin, I was able to build GMP and thats it. Unfortunately I have no logs, but I tracked it down and realized that this flag is the culprit and removing it resolves my problem. Even more bad that the demo I suspect to show the error doesn't build at all with the recent Cygwin release (demos/expr). Anyway, this flag is used where it is completely useless, so please remove it, patch was already submitted to the Cygwin libtool maintainer. Okay, I looked at the x86-defs.m4 file in the gmp distro. It turns out that they specifically say: Libtool gives -DPIC -DDLL_EXPORT to indicate a cygwin or mingw DLL. We undefine PIC since we don't need to be position independent in this case and definitely don't want the ELF style _GLOBAL_OFFSET_TABLE_ etc. ifdef(`DLL_EXPORT',`undefine(`PIC')') Now, on *mingw*, we do indeed (up to now) define both DLL_EXPORT and PIC which compiling .lo's. However, for cygwin, we no longer define DLL_EXPORT, but continue to define PIC. So the little rule above is ineffective, and gmp ends up compiling the wrong assembler code. Now, I'd call this a case -- maybe -- of gmp assuming too much about the internals of libtool. OTOH, libtool emitting -Dcodes means that those codes are supposed to be USED, right? I'm not convinced that it is a BAD thing to emit a -Dcode indicating when a source file is being compiled for a shared object, even when just considering cygwin alone. I can see cases where one might want to implement something differently within a shared lib vs. a static lib. If we unilaterally remove -DPIC on cygwin, we can never do anything like that. What gmp is doing is using the fact that -DDLL_EXPORT is defined to indicate that the target platform is cygwin or mingw. It does this because gmp knows that it DOESN'T want to use the special PIC-guarded code on cygwin|mingw, *even* when building .lo's on those platforms. (The fun part is gpm-h.in specifically says libtool's DLL_EXPORT is NOT used. Errr...bzzt. Yes it is!) However, DLL_EXPORT is an unreliable platform indicator, as we've obviously seen here; it's only true when building .lo's on mingw now. But I don't think just turning -DDLL_EXPORT back on for cygwin is the answer, either. (I don't really remember when this stopped being on for cygwin, but whatever). I think gmp's x86-defs.m4 needs to use $host (or whatever analogue it can conjure up) to determine when the platform is cygwin or mingw, and use THAT to decide when to undefine PIC. Gerrit, if you change the line in x86-defs.m4 to ALWAYS undefine PIC, does that fix your build problem even when libtool still -DPIC's? If so, then certainly we can come up with a better way for gmp's config.m4 machinery to determine its target platform, right? -- Chuck ___ Libtool mailing list [EMAIL PROTECTED] http://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 `prefi.dll', where `prefix' is set by the `ld' option `--dll-search-prefix=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 PASS:
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 $export_symbols' +
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 opts 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 ] export_symbols_cmds: 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
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-long string.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.63r2=1.64cvsroot=automakef=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: NONE /usr/bin/automake-1.4 - priority 10 slave aclocal: /usr/bin/aclocal-1.4 slave automake-info: NONE /usr/bin/automake-1.5 - priority 15 slave aclocal: /usr/bin/aclocal-1.5 slave automake-info: NONE /usr/bin/automake-1.6 - priority 20 slave aclocal: /usr/bin/aclocal-1.6 slave automake-info: NONE /usr/bin/automake-1.7 - priority 30 slave aclocal: /usr/bin/aclocal-1.7 slave automake-info: NONE /usr/bin/automake-1.8 - priority 40 slave aclocal: /usr/bin/aclocal-1.8 slave automake-info: NONE /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,PIC resolver 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 how incompatible x and y are. But on how many systems are BOTH of the following true: (1) to build shared
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 an oldlib (e.g. static archive) machinery, but jiggers with the list-of-objects. If so, then this task will be rather tricky (I think), because the build-a-convenience-lib codeflow will need to be disentangled, so that it has its own implementation
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 21; 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 21 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 thisdir.
+if test \x\$destdir\ != \x\$file\; then
+ case \\$destdir\ in
+ [/]* | [A-Za-z]:[/]*) thisdir=\\$destdir\ ;;
+ *) thisdir=\\$thisdir/\$destdir\ ;;
+ esac
+fi
+
+file=\`\$ECHO \X\$file\ | \$Xsed -e 's%^.*/%%'\`
+file=\`ls -ld \\$thisdir/\$file\ | ${SED} -n 's/.*- //p'\`
+ done
+
+ # Try to get the absolute directory name.
+ absdir=\`cd \\$thisdir\ pwd\`
+ test -n \\$absdir\ thisdir=\\$absdir\
+
+
+ if test $fast_install = yes
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: 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
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 ... link DLL Creating library file: .libs/liblzma.dll.a link static archive: 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: 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-relver-pkgfmt libfoo10-1.7.2-relver-pkgfmt foo-1.7.2-relver-pkgfmt new: libfoo-devel-2.0.0-relver-pkgfmt libfoo16-2.0.0-relver-pkgfmt foo-2.0.0-relver-pkgfmt 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.1derived 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 in the case above):
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-stuff ^^ 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-stuff package. The libavutil49-0.4.9-stuff 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. g 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 your Makefile explicitly ties the
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:\mingw-inst-dir\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: sysroot subsystem=mingw32 path=%R / sysroot subsystem=MSYS path=%R/msys/1.0 / To this: sysroot subsystem=mingw32 path=%R / sysroot subsystem=MSYS path=C:/msys/1.0 / The default configuration will install a new MinGW into whereever mingw-get is, and a new MSYS into whereever mingw-get-is/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 wherever-mingw-get-is/*. 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=200665atid=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=2435atid=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: bug-libtool_gnu.org 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
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 4:22 PM, Alon Bar-Lev wrote:
On Fri, Oct 1, 2010 at 3:35 PM, Charles Wilson
please-don't-feed-the-spammers 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
install on her linux box, and it would all end up in
/usr/i686-pc-mingw32/sys-root/mingw/{include,lib,...}
just like it's supposed to. Then, when she uses her i686-pc-mingw32-gcc
to build the bar.exe client of libfoo (for the mingw $host), the new
libs and headers will be found. Now, the libfoo.la file in
/usr/i686-pc-mingw32/sys-root/mingw/lib
might contain
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: -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: 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 bfrie...@simple.dallas.tx.us 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/23/2011 11:03 AM, Vadim Zeitlin wrote: On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn bfrie...@simple.dallas.tx.us 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 before and after... -- 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: cross compilation to w32
Ralf Wildenhues wrote:
Does anybody see easy ways out?
Well, for the second problem there are two solutions. (1) always ensure
that the script is emitted with unix line endings, or (2) specify
$TARGETSHELL=/emulation/environment/sh when cross-compiling.
Obviously, (2) is the easiest, because getting rid of the requirement
for an emulator is going to take a bit more work. (1) is slightly more
difficult, and doesn't solve the emulator problem -- but at least
doesn't compound the problem.
For cygwin/msys, (1) means for --lt-dump-script, using setmode() on
stdout here:
if (strcmp (argv[i], dumpscript_opt) == 0)
{
setmode here?
printf (%s, script_text);
return 0;
}
and for normal operation, changing this:
/* note: do NOT use wt here! -- defer to underlying
* mount type on cygwin
*/
if ((shwrapper = fopen (newargz[1], w)) == 0)
to
/* always use binary mode */
if ((shwrapper = fopen (newargz[1], wb)) == 0)
Both cygwin and msys's shell will work with unix line endings,
regardless of cygwin's underlying mount type, etc.
Of course, both of these suggestions (setmode, and using wb) are
win32-isms, and will only work as written above if we continue to use
$LTCC as described below:
# we should really use a build-platform specific compiler
# here, but OTOH, the wrappers (shell script and this C one)
# are only useful if you want to execute the real binary.
# Since the real binary is built for $host, then this
# wrapper might as well be built for $host, too.
$opt_dry_run || {
$LTCC $LTCFLAGS -o $cwrapper $cwrappersource
$STRIP $cwrapper
}
As Ralf has pointed out, the comment above is not currently correct: we
currently do need to execute the binary wrapper, even if we don't want
to run the actual target, because the next step is:
# Now, create the wrapper script for func_source use:
$opt_dry_run || {
$cwrapper --lt-dump-script
$func_ltwrapper_scriptname_result
}
=== emulator problem
(1) guard win32-isms in the binary wrapper source code against non-win32
build environment
(2) use build environment compiler to compile binary wrapper
(3) this means that you CAN'T use an emulator environment at all, if you
wanted to run the tests -- because the emulator won't be able to execute
the binary wrappers
Okay. So that's not really a solution. What we really need is the
capability to extract (or emit) the shell wrapper during the link phase
(or earlier), just so libtool can source it back in and parse the contents.
One important note: for win32 targets, there are TWO different copies
(with different names) of the shell wrapper. One is created during the
link phase, and is only present so that it can be sourced back in by
libtool and parsed. The other (ephemeral) copy is (re)created each time
the binary wrapper is executed, and the binary wrapper then execs it.
Our problem is the first one. How about, when cross-compiling for win32
targets, keep most things as they are (with perhaps some of the
line-ending changes described above). However, just change this bit:
# Now, create the wrapper script for func_source use:
func_ltwrapper_scriptname $cwrapper
$RM $func_ltwrapper_scriptname_result
trap $RM $func_ltwrapper_scriptname_result; exit
$EXIT_FAILURE 1 2 15
$opt_dry_run || {
$cwrapper --lt-dump-script
$func_ltwrapper_scriptname_result
}
so that when cross-compiling for win32, we use the normal method of
creating $func_ltwrapper_scriptname_result -- direct creation from libtool:
func_emit_wrapper no $func_ltwrapper_scriptname_result
Here's a possible (completely untested) patch.
--
Chuck
Index: ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.99
diff -u -r1.99 ltmain.m4sh
--- ltmain.m4sh 5 Mar 2008 20:14:43 - 1.99
+++ ltmain.m4sh 8 Mar 2008 18:54:53 -
@@ -2513,6 +2513,7 @@
#ifdef _MSC_VER
# include direct.h
# include process.h
+# include io.h
#else
# include unistd.h
# include stdint.h
@@ -2523,6 +2524,7 @@
#include string.h
#include ctype.h
#include errno.h
+#include fcntl.h
#include sys/stat.h
#if defined(PATH_MAX)
@@ -2556,6 +2558,7 @@
#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
defined (__OS2__)
# define HAVE_DOS_BASED_FILE_SYSTEM
+# define FOPEN_WB wb
# ifndef DIR_SEPARATOR_2
# define DIR_SEPARATOR_2 '\\'
# endif
@@ -2577,6 +2580,17 @@
# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2)
#endif /* PATH_SEPARATOR_2 */
+#ifdef __CYGWIN__
+# define FOPEN_WB wb
+#endif
+
+#ifndef FOPEN_WB
+# define FOPEN_WB w
+#endif
+#ifndef _O_BINARY
+#
libtool ChangeLog libltdl/config/ltmain.m4sh
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/07 08:47:12 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh Log message: * ltmain.m4sh (func_emit_libtool_wrapper_script): add code block to handle cases when wrapper script is in $objdir. (func_emit_libtool_cwrapperexe_source): replace DEBUG() macro with namespace-safe LTWRAPPER_DEBUGPRINTF(). Call func_emit_libtool_wrapper_script() with appropriate filters to embed script text in C char* static variable. (f_e_l_c_s: main): add new option --lt-dump-script, parse argv[] for it, and take appropriate action. Call chase_symlinks() on argv[0], in case this.exe was launched via one. Use chased value to determine full absolute pathname of wrapper script, in $objdir. Unconditionally write script out to this pathname and set permission bits. Remove extraneous ';' from debugging loop. (f_e_l_c_s: main) [mingw]: DOS-ize $SHELL before populating newargv[0]; if $TARGETSHELL environment variable is set, use it instead of $SHELL and do not DOS-ize. Ensure newargv[1] (wrapper script absolute path) uses only '/', not '\'. Make sure to call execv() with DOS-ized $SHELL (or un-DOS-ized $TARGETSHELL, if set) (f_e_l_c_s: make_executable): new function (f_e_l_c_s: chase_symlinks): new function (no-op if !S_ISLNK) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2465r2=1.2466 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/config/ltmain.m4sh?cvsroot=libtoolr1=1.76r2=1.77 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool ChangeLog libltdl/config/ltmain.m4sh
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/07 08:50:17 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh Log message: * ltmain.m4sh (func_emit_libtool_cwrapperexe_source): ensure that generated source follows GCS as nearly as possible. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2466r2=1.2467 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/config/ltmain.m4sh?cvsroot=libtoolr1=1.77r2=1.78 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool ChangeLog libltdl/m4/libtool.m4
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/17 20:16:04 Modified files: . : ChangeLog libltdl/m4 : libtool.m4 Log message: * libltdl/m4/libtool.m4 (LT_CMD_MAX_LEN): ensure stderr is redirected even when getconf does not exist. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2468r2=1.2469 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/m4/libtool.m4?cvsroot=libtoolr1=1.105r2=1.106 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool ChangeLog libltdl/config/ltmain.m4sh te...
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/19 05:43:16 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh tests : destdir.at Log message: * libltdl/config/ltmain.m4sh: Add new magic variable for use with cwrapper. (func_ltwrapper_script_p): New function. (func_ltwrapper_executable_p): New function. (func_ltwrapper_scriptname): New function. (func_ltwrapper_p): Accomodate both wrapper scripts and wrapper executables. (func_mode_execute): Handle $file that is a wrapper script and $file that is a wrapper executable differently. (func_mode_install) [cygwin|mingw]: If $file is a wrapper executable, use func_ltwrapper_scriptname to determine wrapper script name. Afterwards, always use func_ltwrapper_script_p instead of func_ltwrapper_p. (func_emit_libtool_wrapper_script): Rename to... (func_emit_wrapper): ...this. All callers changed. (func_emit_libtool_cwrapperexe_source): Rename to... (func_emit_cwrapperexe_src): ...this. All callers changed. Embed new magic_exe variable into source. Private transient wrapper script now called foo_ltshwrapperTMP, not foo_ltshwrapper. (func_emit_cwrapperexe_src) [main, mingw]: Use _spawnv and return child's exit code manually rather than rely on broken execv. (func_mode_link) [cygwin|mingw]: Don't call dirname and basename directly; use func_dirname and func_basename when computing cwrapper names. Use cwrapper to generate wrapper script, and use pathname returned by func_ltwrapper_scriptname instead of $output. (func_mode_link) [NOT cygwin|mingw]: move wrapper script generation for non-win32 inside case statement, as default case. (func_mode_uninstall) [$name's extension != .lo|.la]: 'clean' mode must handle $file differently if it is a libtool wrapper script, or if it is a libtool wrapper executable. * tests/destdir.at [Simple DESTDIR install]: $EXEEXT fixups. * tests/destdir.at [DESTDIR with in-package deplibs]: Ditto. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2471r2=1.2472 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/config/ltmain.m4sh?cvsroot=libtoolr1=1.79r2=1.80 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/destdir.at?cvsroot=libtoolr1=1.5r2=1.6 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool AUTHORS ChangeLog
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/06/19 06:22:02 Modified files: . : AUTHORS ChangeLog Log message: * AUTHORS: Add myself. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/AUTHORS?cvsroot=libtoolr1=1.17r2=1.18 http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2472r2=1.2473 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool ChangeLog libltdl/config/ltmain.m4sh li...
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/07/13 07:21:39 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh libltdl/m4 : libtool.m4 Log message: * libltdl/m4/libtool.m4 (func_dirname_and_basename) XSI: New function. (func_dirname_and_basename) !XSI: New function. * libltdl/config/ltmain.m4sh (func_ltwrapper_scriptname): Call it. Also, take advantage of missed optimization using func_dirname's additional arguments. (func_mode_compile): Call it. (func_mode_install): Call it. (func_mode_link): Call it. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2485r2=1.2486 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/config/ltmain.m4sh?cvsroot=libtoolr1=1.84r2=1.85 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/m4/libtool.m4?cvsroot=libtoolr1=1.111r2=1.112 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool ChangeLog tests/cdemo-exec.test tests/d...
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson07/07/16 22:53:06 Modified files: . : ChangeLog tests : cdemo-exec.test demo-deplibs.test demo-exec.test demo-inst.test demo-relink.test depdemo-exec.test depdemo-inst.test depdemo-relink.test f77demo-exec.test fcdemo-exec.test mdemo-exec.test mdemo-inst.test mdemo2-exec.test pdemo-exec.test pdemo-inst.test tagdemo-exec.test Log message: * tests/cdemo-exec.test: use $EXEEXT where appropriate to correct mingw cross-compile issues. * demo-deplibs.test: Ditto. * demo-exec.test: Ditto. * demo-inst.test: Ditto. * demo-relink.test: Ditto. * depdemo-exec.test: Ditto. * depdemo-inst.test: Ditto. * depdemo-relink.test: Ditto. * f77demo-exec.test: Ditto. * fcdemo-exec.test: Ditto. * mdemo-exec.test: Ditto. * mdemo-inst.test: Ditto. * mdemo2-exec.test: Ditto. * pdemo-exec.test: Ditto. * pdemo-inst.test: Ditto. * tagdemo-exec.test: Ditto. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2487r2=1.2488 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/cdemo-exec.test?cvsroot=libtoolr1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/demo-deplibs.test?cvsroot=libtoolr1=1.8r2=1.9 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/demo-exec.test?cvsroot=libtoolr1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/demo-inst.test?cvsroot=libtoolr1=1.16r2=1.17 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/demo-relink.test?cvsroot=libtoolr1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/depdemo-exec.test?cvsroot=libtoolr1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/depdemo-inst.test?cvsroot=libtoolr1=1.13r2=1.14 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/depdemo-relink.test?cvsroot=libtoolr1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/f77demo-exec.test?cvsroot=libtoolr1=1.11r2=1.12 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/fcdemo-exec.test?cvsroot=libtoolr1=1.2r2=1.3 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/mdemo-exec.test?cvsroot=libtoolr1=1.21r2=1.22 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/mdemo-inst.test?cvsroot=libtoolr1=1.22r2=1.23 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/mdemo2-exec.test?cvsroot=libtoolr1=1.9r2=1.10 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/pdemo-exec.test?cvsroot=libtoolr1=1.14r2=1.15 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/pdemo-inst.test?cvsroot=libtoolr1=1.15r2=1.16 http://cvs.savannah.gnu.org/viewcvs/libtool/tests/tagdemo-exec.test?cvsroot=libtoolr1=1.11r2=1.12 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
libtool ChangeLog libltdl/config/ltmain.m4sh
CVSROOT:/sources/libtool Module name:libtool Changes by: Charles Wilson cwilson08/03/13 04:46:09 Modified files: . : ChangeLog libltdl/config : ltmain.m4sh Log message: * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file scope]: additional #includes and #defines to support... (func_emit_cwrapperexe_src) [main]: ensure stdout is set to binary mode for cygwin|mingw builds. Ensure temporary script file is written in binary mode for cygwin|mingw builds. (func_mode_link) [cygwin|mingw]: cross-build support - only use cwrapper to generate shell wrapper if building native; otherwise use func_emit_wrapper() CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/libtool/ChangeLog?cvsroot=libtoolr1=1.2617r2=1.2618 http://cvs.savannah.gnu.org/viewcvs/libtool/libltdl/config/ltmain.m4sh?cvsroot=libtoolr1=1.100r2=1.101 ___ Libtool-commit mailing list Libtool-commit@gnu.org http://lists.gnu.org/mailman/listinfo/libtool-commit
[SCM] GNU Libtool branch, master, updated. v2.2.4-3-ga50bd8f
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via a50bd8f5bf1d358353b34f42fa75c43938f26984 (commit) from fc6191fe1f582517bd529f9d376773fd1c33817a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit a50bd8f5bf1d358353b34f42fa75c43938f26984 Author: Charles Wilson [EMAIL PROTECTED] Date: Mon May 5 20:23:05 2008 -0400 Ensure $OBJDUMP is defined * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures that $OBJDUMP is always defined sanely. (_LT_SYS_DYNAMIC_LINKER): call it. (_LT_CHECK_MAGIC_METHOD): call it. --- Summary of changes: ChangeLog |8 libltdl/m4/libtool.m4 | 14 ++ 2 files changed, 22 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 15ffae1..6784cb5 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2008-05-06 Charles Wilson [EMAIL PROTECTED] + + Ensure $OBJDUMP is defined + * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures + that $OBJDUMP is always defined sanely. + (_LT_SYS_DYNAMIC_LINKER): call it. + (_LT_CHECK_MAGIC_METHOD): call it. + 2008-05-05 Gary V. Vaughan [EMAIL PROTECTED] Fix libtoolize test failure with aclocal 1.10.1 diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4 index 4ceb7f1..4d31e80 100644 --- a/libltdl/m4/libtool.m4 +++ b/libltdl/m4/libtool.m4 @@ -2035,6 +2035,7 @@ m4_defun([_LT_SYS_DYNAMIC_LINKER], [AC_REQUIRE([AC_CANONICAL_HOST])dnl m4_require([_LT_DECL_EGREP])dnl m4_require([_LT_FILEUTILS_DEFAULTS])dnl +m4_require([_LT_DECL_OBJDUMP])dnl m4_require([_LT_DECL_SED])dnl AC_MSG_CHECKING([dynamic linker characteristics]) m4_if([$1], @@ -2956,6 +2957,7 @@ _LT_DECL([], [reload_cmds], [2])dnl # -- PORTME fill in with the dynamic library characteristics m4_defun([_LT_CHECK_MAGIC_METHOD], [m4_require([_LT_DECL_EGREP]) +m4_require([_LT_DECL_OBJDUMP]) AC_CACHE_CHECK([how to recognize dependent libraries], lt_cv_deplibs_check_method, [lt_cv_file_magic_cmd='$MAGIC_CMD' @@ -6970,6 +6972,18 @@ AC_SUBST([GREP]) ]) +# _LT_DECL_OBJDUMP +# -- +# If we don't have a new enough Autoconf to choose the best objdump +# available, choose the one first in the user's PATH. +m4_defun([_LT_DECL_OBJDUMP], +[AC_CHECK_TOOL(OBJDUMP, objdump, false) +test -z $OBJDUMP OBJDUMP=objdump +_LT_DECL([], [OBJDUMP], [1], [An object symbol dumper]) +AC_SUBST([OBJDUMP]) +]) + + # _LT_DECL_SED # # Check for a fully-functional sed program, that truncates hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.2.4-5-gfae9496
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via fae94962aa3c36f3cee00a453c2a7d01baaf4ff0 (commit)
from d34008adff36714b3a593da2377202df0d94bffe (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit fae94962aa3c36f3cee00a453c2a7d01baaf4ff0
Author: Charles Wilson [EMAIL PROTECTED]
Date: Sat Apr 26 16:03:50 2008 -0400
[mingw|cygwin] Modify cwrapper to invoke target directly.
* libltdl/config/ltmain.m4sh (func_to_native_path):
New function. If $host is mingw, and $build is mingw
or cygwin, convert path to mingw native format.
(func_to_native_pathlist): New function. Ditto, for
:-separated pathlists.
(func_emit_cwrapperexe_src) [__CYGWIN__ __STRICT_ANSI__]:
Ensure putenv and setenv are declared. Define HAVE_SETENV.
(func_emit_cwrapperexe_src) [main]: Add new constants to
hold desired PATH settings; initialize and use functions
above to convert to $host format if necessary. Add new
command-line options --lt-env-set, --lt-env-prepend, and
--lt-env-append. No longer emit wrapper script as integral
part of launching child. Remove support for (now) unnecessary
$TARGETSHELL. Exec actual target executable directly.
(func_emit_cwrapperexe_src) [lt_setenv, lt_extend_str]
[lt_split_name_value, lt_opt_process_env_set]
[lt_opt_process_env_prepend, lt_opt_process_env_append]
[lt_update_exe_path, lt_update_lib_path]: New functions.
---
Summary of changes:
ChangeLog | 22 ++
libltdl/config/ltmain.m4sh | 564 ++--
2 files changed, 511 insertions(+), 75 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 81f532e..5bc51f7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,25 @@
+2008-05-13 Charles Wilson [EMAIL PROTECTED]
+
+ [mingw|cygwin] Modify cwrapper to invoke target directly.
+ * libltdl/config/ltmain.m4sh (func_to_native_path):
+ New function. If $host is mingw, and $build is mingw
+ or cygwin, convert path to mingw native format.
+ (func_to_native_pathlist): New function. Ditto, for
+ :-separated pathlists.
+ (func_emit_cwrapperexe_src) [__CYGWIN__ __STRICT_ANSI__]:
+ Ensure putenv and setenv are declared. Define HAVE_SETENV.
+ (func_emit_cwrapperexe_src) [main]: Add new constants to
+ hold desired PATH settings; initialize and use functions
+ above to convert to $host format if necessary. Add new
+ command-line options --lt-env-set, --lt-env-prepend, and
+ --lt-env-append. No longer emit wrapper script as integral
+ part of launching child. Remove support for (now) unnecessary
+ $TARGETSHELL. Exec actual target executable directly.
+ (func_emit_cwrapperexe_src) [lt_setenv, lt_extend_str]
+ [lt_split_name_value, lt_opt_process_env_set]
+ [lt_opt_process_env_prepend, lt_opt_process_env_append]
+ [lt_update_exe_path, lt_update_lib_path]: New functions.
+
2008-05-11 Charles Wilson [EMAIL PROTECTED]
Ensure cwrapper compiles without warnings under -std=c99.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 09dc434..0bfae76 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2511,6 +2511,122 @@ func_emit_wrapper ()
}
+# func_to_host_path arg
+#
+# Convert paths to build format when used with build tools.
+# Intended for use with native mingw (where libtool itself
+# is running under the msys shell). Ordinarily, the (msys) shell
+# automatically converts such things for non-msys applications
+# it launches, but that isn't available from inside the cwrapper.
+# Similar accommodations are necessary for $host mingw and $build
+# cygwin. Calling this function does no harm on other $build or
+# for other $host.
+#
+# ARG is the path (on $build) that should be converted to
+# the proper representation for $host. The result is stored
+# in $func_to_host_path_result.
+func_to_host_path ()
+{
+ func_to_host_path_result=$1
+ if test -n $1 ; then
+case $host in
+ *mingw* )
+lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
+case $build in
+ *mingw* ) # actually, msys
+# awkward: cmd appends spaces to result
+lt_sed_strip_trailing_spaces=s/[ ]*\$//
+func_to_host_path_tmp1=`( cmd //c echo $1 |\
+ $SED -e $lt_sed_strip_trailing_spaces ) 2/dev/null || echo `
+func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
+ $SED -e $lt_sed_naive_backslashify
[SCM] GNU Libtool branch, master, updated. v2.2.4-12-gaf3b8c5
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via af3b8c515e1e6297294c0c5fb69998274d389653 (commit)
from 0e72f5793bec9624d80261f3cfc1103bb1ca82e7 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit af3b8c515e1e6297294c0c5fb69998274d389653
Author: Charles Wilson [EMAIL PROTECTED]
Date: Thu May 15 00:07:50 2008 -0400
[mingw] Add cross-compile support to cwrapper
* libltdl/config/ltmain.m4sh (func_to_host_path) [$host=mingw]:
If present, use winepath to convert from $build to $host
if $build is neither mingw (msys) nor cygwin. Use unconverted
path as fallback when conversion fails. Also update comments.
(func_to_host_pathlist) [$host=mingw]: Ditto. For fallback case,
use simplistic ':' to ';' path separator translation.
---
Summary of changes:
ChangeLog | 10
libltdl/config/ltmain.m4sh | 121 +++
2 files changed, 97 insertions(+), 34 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 7e00eb9..276d9b6 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,15 @@
2008-05-25 Charles Wilson [EMAIL PROTECTED]
+ [mingw] Add cross-compile support to cwrapper
+ * libltdl/config/ltmain.m4sh (func_to_host_path) [$host=mingw]:
+ If present, use winepath to convert from $build to $host
+ if $build is neither mingw (msys) nor cygwin. Use unconverted
+ path as fallback when conversion fails. Also update comments.
+ (func_to_host_pathlist) [$host=mingw]: Ditto. For fallback case,
+ use simplistic ':' to ';' path separator translation.
+
+2008-05-25 Charles Wilson [EMAIL PROTECTED]
+
Cwrapper should not eat -- arguments
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src)
[file scope]: Defined all option strings in terms of macro
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 888b74b..cfdfdf9 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2513,14 +2513,21 @@ func_emit_wrapper ()
# func_to_host_path arg
#
-# Convert paths to build format when used with build tools.
+# Convert paths to host format when used with build tools.
# Intended for use with native mingw (where libtool itself
-# is running under the msys shell). Ordinarily, the (msys) shell
-# automatically converts such things for non-msys applications
-# it launches, but that isn't available from inside the cwrapper.
-# Similar accommodations are necessary for $host mingw and $build
-# cygwin. Calling this function does no harm on other $build or
-# for other $host.
+# is running under the msys shell), or in the following cross-
+# build environments:
+#$build $host
+#mingw (msys)mingw [e.g. native]
+#cygwin mingw
+#*nix + wine mingw
+# where wine is equipped with the `winepath' executable.
+# In the native mingw case, the (msys) shell automatically
+# converts paths for any non-msys applications it launches,
+# but that facility isn't available from inside the cwrapper.
+# Similar accommodations are necessary for $host mingw and
+# $build cygwin. Calling this function does no harm for other
+# $host/$build combinations not listed above.
#
# ARG is the path (on $build) that should be converted to
# the proper representation for $host. The result is stored
@@ -2546,11 +2553,28 @@ func_to_host_path ()
func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
$SED -e $lt_sed_naive_backslashify`
;;
+ * )
+# Unfortunately, winepath does not exit with a non-zero
+# error code, so we are forced to check stderr for an
+# error message. On the other hand, if the command is not
+# found, the shell will set an exit code of 127. So we
+# must check for both, which explains the odd construction:
+func_to_host_path_winepath_stderr=`winepath -w $1 /dev/null
21`
+func_to_host_path_winepath_exitcode=$?
+if test $func_to_host_path_winepath_exitcode -eq 0 \
+ test -z ${func_to_host_path_winepath_stderr} ; then
+ func_to_host_path_tmp1=`winepath -w $1`
+ func_to_host_path_result=`echo $func_to_host_path_tmp1 |\
+$SED -e $lt_sed_naive_backslashify`
+fi
+;;
esac
if test -z $func_to_host_path_result ; then
func_error Could not determine host path corresponding to
func_error '$1'
func_error Continuing
[SCM] GNU Libtool branch, master, updated. v2.2.6-37-g87cea4b
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 87cea4bf9e8341df8a317f8971fcccdad0cca9f3 (commit)
from 4e7334c7c28e51d3943339f6f3617985c03e3f79 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 87cea4bf9e8341df8a317f8971fcccdad0cca9f3
Author: Charles Wilson [EMAIL PROTECTED]
Date: Sat Nov 15 04:40:26 2008 -0500
Fix --verbose option; add new --no-{silent|quiet|verbose} options.
* libltdl/config/ltmain.m4sh (usage): Document
new options --no-silent/--no-quiet and --no-verbose.
(func_enable_tag): Handle new options.
Modified --verbose to actually activate opt_verbose.
New behavior: --silent disables both normal output and
func_verbose output. --verbose enables both normal
output and func_verbose output. --no-silent enables
normal output, but does not affect func_verbose output.
--no-verbose disables func_verbose output, but does not
affect normal output.
* NEWS: announce new options --no-silent/--no-quiet, and
--no-verbose.
* doc/libtool.texi: document new options --no-silent/--no-quiet
and --no-verbose.
---
Summary of changes:
ChangeLog | 19 +++
NEWS |9 +
doc/libtool.texi | 39 ++-
libltdl/config/ltmain.m4sh | 16 +++-
4 files changed, 81 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b1582fd..cd1b1fa 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,22 @@
+2008-11-21 Charles Wilson [EMAIL PROTECTED]
+
+ Fix --verbose option; add new --no-{silent|quiet|verbose} options.
+
+ * libltdl/config/ltmain.m4sh (usage): Document
+ new options --no-silent/--no-quiet and --no-verbose.
+ (func_enable_tag): Handle new options.
+ Modified --verbose to actually activate opt_verbose.
+ New behavior: --silent disables both normal output and
+ func_verbose output. --verbose enables both normal
+ output and func_verbose output. --no-silent enables
+ normal output, but does not affect func_verbose output.
+ --no-verbose disables func_verbose output, but does not
+ affect normal output.
+ * NEWS: announce new options --no-silent/--no-quiet, and
+ --no-verbose.
+ * doc/libtool.texi: document new options --no-silent/--no-quiet
+ and --no-verbose.
+
2008-11-20 Ralf Wildenhues [EMAIL PROTECTED]
Fix match patterns for cegcc*.
diff --git a/NEWS b/NEWS
index a38bfb3..c00e404 100644
--- a/NEWS
+++ b/NEWS
@@ -6,6 +6,12 @@ New in 2.2.8 2008-??-??: git version 2.2.7a, Libtool team:
- Libtool ships and installs man pages for libtool and libtoolize now.
- New libtool command line flag --help-all.
+ - New libtool command line flag --no-silent (with alternate spelling
+--no-quiet). This flag (re)enables the default informational messages,
+but has no effect on so-called verbose output messages.
+ - New libtool command line flag --no-verbose, which disables only
+the extra verbose output messages and has no effect on the
+default informational messages.
* Bug fixes:
@@ -13,6 +19,9 @@ New in 2.2.8 2008-??-??: git version 2.2.7a, Libtool team:
with Autoconf 2.59 (`possibly undefined macro: LT_LIBEXT').
- Fix 2.2.4 regression that caused arguments with special characters
to be mangled by the compile wrapper for uninstalled programs on MinGW.
+ - libtool command line flag --verbose now also enables explicit
+verbose output, in addition to its previous behavior of (re)enabling
+only the default informational output. See New Features, --no-silent.
* Miscellaneous changes:
diff --git a/doc/libtool.texi b/doc/libtool.texi
index f03adfb..fe9547e 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1207,7 +1207,44 @@ Do not print out any progress or informational messages.
@item -v
@itemx --verbose
-Print out progress and informational messages (enabled by default).
+Print out progress and informational messages (enabled by default),
+as well as additional messages not ordinary seen by default.
+
[EMAIL PROTECTED] --no-quiet
[EMAIL PROTECTED] --no-silent
+Print out the progress and informational messages that are seen
+by default. This option has no effect on whether the additional
+messages seen in @option{--verbose} mode are shown.
+
[EMAIL PROTECTED] --no-verbose
+Do not print out any additional informational messages beyond
+those ordinarily seen by default. This option has no effect
+on whether the ordinary progress
[SCM] GNU Libtool branch, master, updated. v2.2.6-68-g805585f
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 805585f7bffadb85259a3db72a7d368a99e6966c (commit)
from 72cefc2f632b17940307fb841a25f2c4b5ff17bc (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 805585f7bffadb85259a3db72a7d368a99e6966c
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date: Tue Jan 20 17:31:43 2009 -0500
Minor cygwin cleanup
libltdl/config/ltmain.m4sh (func_generate_dlsyms): Correct
case pattern for cygwin.
---
Summary of changes:
ChangeLog |6 ++
libltdl/config/ltmain.m4sh |2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 06004aa..b702907 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2009-01-21 Charles Wilson libt...@cwilson.fastmail.fm
+
+ Minor cygwin cleanup
+ * libltdl/config/ltmain.m4sh (func_generate_dlsyms): Correct
+ case pattern for cygwin.
+
2009-01-19 Ralf Wildenhues ralf.wildenh...@gmx.de
Avoid failure due to Cygwin path detection bug.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 6be529a..760f647 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1987,7 +1987,7 @@ extern \C\ {
eval '$GREP -f $output_objdir/$outputname.exp $nlist
$nlistT'
eval '$MV $nlistT $nlist'
case $host in
- *cygwin | *mingw* | *cegcc* )
+ *cygwin* | *mingw* | *cegcc* )
eval echo EXPORTS ' $output_objdir/$outputname.def'
eval 'cat $nlist $output_objdir/$outputname.def'
;;
hooks/post-receive
--
GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.2.6-75-geaba16e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via eaba16eb3a54b27704799d5bfd2619f6732225ce (commit) from 6631e515bd208d55f45094405ac185cb8e8d66f9 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit eaba16eb3a54b27704799d5bfd2619f6732225ce Author: Charles Wilson libt...@cwilson.fastmail.fm Date: Sat Jan 24 12:04:45 2009 -0500 Add -Wall to cwrapper tests. * tests/cwrapper.at: Add -Wall existing tests. Add additional round of tests with -Wall alone. --- Summary of changes: ChangeLog |6 ++ tests/cwrapper.at |2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 91bf875..424d296 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2009-01-24 Charles Wilson libt...@cwilson.fastmail.fm + Add -Wall to cwrapper tests. + * tests/cwrapper.at: Add -Wall existing tests. Add additional + round of tests with -Wall alone. + +2009-01-24 Charles Wilson libt...@cwilson.fastmail.fm + [cygwin|mingw] cwrapper cleanups. * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file scope]: re-organized includes and portability diff --git a/tests/cwrapper.at b/tests/cwrapper.at index 30e591e..ce4572e 100644 --- a/tests/cwrapper.at +++ b/tests/cwrapper.at @@ -55,7 +55,7 @@ int main (void) orig_CFLAGS=$CFLAGS orig_LIBTOOL=$LIBTOOL -for restrictive_flags in '-std=c89 -Werror' '-std=c99 -Werror'; do +for restrictive_flags in '-Wall -Werror' '-std=c89 -Wall -Werror' '-std=c99 -Wall -Werror'; do CFLAGS=$orig_CFLAGS $restrictive_flags sed s/LTCFLAGS=.*/' $restrictive_flags'/ $orig_LIBTOOL ./libtool LIBTOOL=./libtool hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.2.6-85-g0980a39
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 0980a3993a6138895d4884f92ff9764d426b148d (commit) from 425841cbdee3b690eb89a92403e97b0852f95771 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 0980a3993a6138895d4884f92ff9764d426b148d Author: Akim Demaille demai...@gostai.com Date: Fri Jan 30 02:52:17 2009 -0500 Fix cwrapper warnings from MSVC 2005. * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) [file scope]: define _CRT_SECURE_NO_DEPRECATE. --- Summary of changes: ChangeLog |6 ++ libltdl/config/ltmain.m4sh |3 +++ 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 135229c..fb41b86 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2009-01-30 Akim Demaille demai...@gostai.com + + Fix cwrapper warnings from MSVC 2005. + * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src) + [file scope]: define _CRT_SECURE_NO_DEPRECATE. + 2009-01-29 Akim Demaille demai...@gostai.com Fix bootstrap with older libtool.m4 in reach of aclocal. diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index de63a83..5f66471 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -2712,6 +2712,9 @@ func_emit_cwrapperexe_src () */ EOF cat EOF +#ifdef _MSC_VER +# define _CRT_SECURE_NO_DEPRECATE 1 +#endif #include stdio.h #include stdlib.h #ifdef _MSC_VER hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.2.6-105-g8965cb5
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via 8965cb5fa339aa4f63d0e77fcc91e0e46929348d (commit) from b3072b0b3757910eae01c0b47ee80638f6e84cf5 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - commit 8965cb5fa339aa4f63d0e77fcc91e0e46929348d Author: Charles Wilson libt...@cwilson.fastmail.fm Date: Sun Mar 29 19:25:35 2009 -0400 Improve compatibility with older automake * libltdl/m4/lt~obsolete.m4: Add AC_DEFUNs for _LT_PREPARE_SED_QUOTE_VARS and _LT_PROG_ECHO_BACKSLASH. Report by Yaakov Selkowitz. --- Summary of changes: ChangeLog |7 +++ libltdl/m4/lt~obsolete.m4 |2 ++ 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 0a4ef31..bd09879 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2009-03-29 Charles Wilson libt...@cwilson.fastmail.fm + + Improve compatibility with older automake + * libltdl/m4/lt~obsolete.m4: Add AC_DEFUNs for + _LT_PREPARE_SED_QUOTE_VARS and _LT_PROG_ECHO_BACKSLASH. + Report by Yaakov Selkowitz. + 2009-03-20 Peter Rosin p...@lysator.liu.se LT_OUTPUT should always create the libtool script. diff --git a/libltdl/m4/lt~obsolete.m4 b/libltdl/m4/lt~obsolete.m4 index b60bbd2..5f6a956 100644 --- a/libltdl/m4/lt~obsolete.m4 +++ b/libltdl/m4/lt~obsolete.m4 @@ -92,3 +92,5 @@ m4_ifndef([AC_LIBTOOL_CONFIG], [AC_DEFUN([AC_LIBTOOL_CONFIG])]) m4_ifndef([_LT_AC_FILE_LTDLL_C], [AC_DEFUN([_LT_AC_FILE_LTDLL_C])]) m4_ifndef([_LT_REQUIRED_DARWIN_CHECKS], [AC_DEFUN([_LT_REQUIRED_DARWIN_CHECKS])]) m4_ifndef([_LT_AC_PROG_CXXCPP], [AC_DEFUN([_LT_AC_PROG_CXXCPP])]) +m4_ifndef([_LT_PREPARE_SED_QUOTE_VARS], [AC_DEFUN([_LT_PREPARE_SED_QUOTE_VARS])]) +m4_ifndef([_LT_PROG_ECHO_BACKSLASH], [AC_DEFUN([_LT_PROG_ECHO_BACKSLASH])]) hooks/post-receive -- GNU Libtool
[SCM] GNU Libtool branch, master, updated. v2.2.6-106-g5f2bbb4
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.
The branch, master has been updated
via 5f2bbb494a2753afb2878c399cfd8316b7403a5b (commit)
from 8965cb5fa339aa4f63d0e77fcc91e0e46929348d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
commit 5f2bbb494a2753afb2878c399cfd8316b7403a5b
Author: Yaakov Selkowitz yselkow...@users.sourceforge.net
Date: Sun Mar 29 19:38:58 2009 -0400
Use correct export_dynamic_flag_spec for PE-COFF $hosts
* libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin*|mingw*|pw32*|cegcc*]:
Define export_dynamic_flag_spec as -Wl,--export-all-symbols, as required
by GNU ld for PE-COFF.
Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm
---
Summary of changes:
ChangeLog |8
libltdl/m4/libtool.m4 |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index bd09879..cab76a1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2009-03-29 Yaakov Selkowitz yselkow...@users.sourceforge.net (tiny change)
+ Charles Wilson libt...@cwilson.fastmail.fm
+
+ Use correct export_dynamic_flag_spec for PE-COFF $hosts
+ * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS)
+ [cygwin*|mingw*|pw32*|cegcc*]: Define export_dynamic_flag_spec
+ as -Wl,--export-all-symbols, as required by GNU ld for PE-COFF.
+
2009-03-29 Charles Wilson libt...@cwilson.fastmail.fm
Improve compatibility with older automake
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 477f6e3..15612c0 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4275,6 +4275,7 @@ _LT_EOF
# _LT_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
# as there is no search path for DLLs.
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+ _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-all-symbols'
_LT_TAGVAR(allow_undefined_flag, $1)=unsupported
_LT_TAGVAR(always_export_symbols, $1)=no
_LT_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
hooks/post-receive
--
GNU Libtool
