Fwd: Configure is checking for fortran yet I have no fortran code or checks
Sent for archive purposes. Thanks for the help. -- Forwarded message -- From: Andy Wingo <[EMAIL PROTECTED]box.com>Date: Sep 23, 2005 9:04 AMSubject: Configure is checking for fortran yet I have no fortran code or checks To: [EMAIL PROTECTED]Hey dude, I'm not on the libtool list, but I saw your mail. Check this out: http://cvs.freedesktop.org/gstreamer/common/m4/as-libtool-tags.m4?rev=1.2&view=markup http://cvs.freedesktop.org/gstreamer/gstreamer/configure.ac?r1=1.373&r2=1.374Send a mail to the libtool list so it's archived, please :-)Cheers,--Andy Wingo http://wingolog.org/-- Forwarded message --From: Noah Misch <[EMAIL PROTECTED]ech.edu>Date: Sep 15, 2005 12:35 PM Subject: Re: Configure is checking for fortran yet I have no fortran code or checksTo: Brian <[EMAIL PROTECTED]>Cc: autoconf@gnu.org On Thu, Sep 15, 2005 at 10:59:32AM -0600, Brian wrote:> The title says it all. How can I get rid of these fortran checks? Here> are my program checks:I suspect you use Libtool; Libtool 1.5.X check C, C++, and Fortran compilersunconditionally. Libtool 2.0 will only seek tools relevant to the languagesyour project uses.If you need more information, please contact libtool@gnu.org. -- Forwarded message -- From: Brian <[EMAIL PROTECTED]l.com>Date: Sep 15, 2005 10:59 AMSubject: Configure is checking for fortran yet I have no fortran code or checks To: autoconf@gnu.org The title says it all. How can I get rid of these fortran checks? Here are my program checks:AC_PROG_AWKAC_PROG_YACCAC_PROG_LEXAC_PROG_CXXAC_PROG_CC([gcc]) checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... gcc3 checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... f95 checking whether we are using the GNU Fortran 77 compiler... yes checking whether f95 accepts -g... yes Cheers, Brian Mingus ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool chops valid `-framework OpenGL' on Darwin
Libtool appears to be trying to clean up the command line and in the process removing a valid extension to apple's version of gcc. I can't think of a way I can get around this which means my build process is broken on the mac. Notice that the command sent to libtool is not the command issued bin/sh ../../libtool --tag=CXX --mode=link g++ -I/Developer/qt-mac-free-3.3.5/include -L/usr/lib -o pdp++ pdp__-main.o libpdp.la /Users/mingus/pdp-4.0/src/pdp/../.././src/ta/libta.la /Users/mingus/pdp-4.0/src/pdp/../.././src/css/libcss.la /Users/mingus/pdp-4.0/src/pdp/../.././src/tamisc/libtamisc.la /Users/mingus/pdp-4.0/src/pdp/../.././src/taiqtso/libtaiqtso.la -lz -ldl -lreadline -L/Developer/qt-mac-free-3.3.5/lib -lqt-mt -lSM -lICE -L/usr/X11R6/lib -lX11 -lXext -lXmu -lXt -lXi -framework OpenGL -lCoin -ljpeg -lSoQt g++ -I/Developer/qt-mac-free-3.3.5/include -o pdp++ pdp__-main.o "-framework OpenGL" -Wl,-bind_at_load -L/usr/lib ./.libs/libpdp.a -L/Developer/qt-mac-free-3.3.5/lib -L/usr/X11R6/lib /Users/mingus/pdp-4.0/src/pdp/../.././src/ta/.libs/libta.a /Users/mingus/pdp-4.0/src/pdp/../.././src/css/.libs/libcss.a /Users/mingus/pdp-4.0/src/pdp/../.././src/tamisc/.libs/libtamisc.a /Users/mingus/pdp-4.0/src/pdp/../.././src/taiqtso/.libs/libtaiqtso.a /Developer/qt-mac-free-3.3.5/lib/libqt-mt.dylib -lz -ldl -lreadline -lSM -lICE -lX11 -lXext -lXmu -lXt -lXi -lCoin -ljpeg -lSoQt /usr/bin/ld: Undefined symbols: _glColor3f _glDisable _glPopAttrib _glPopMatrix _glPushAttrib _glPushMatrix _glRectf _glRotatef collect2: ld returned 1 exit status Manually issuing the command works as expected. g++ -I/Developer/qt-mac-free-3.3.5/include -o pdp++ pdp__-main.o "-framework OpenGL" -Wl,-bind_at_load -L/usr/lib ./.libs/libpdp.a -L/Developer/qt-mac-free-3.3.5/lib -L/usr/X11R6/lib /Users/mingus/pdp-4.0/src/pdp/../.././src/ta/.libs/libta.a /Users/mingus/pdp-4.0/src/pdp/../.././src/css/.libs/libcss.a /Users/mingus/pdp-4.0/src/pdp/../.././src/tamisc/.libs/libtamisc.a /Users/mingus/pdp-4.0/src/pdp/../.././src/taiqtso/.libs/libtaiqtso.a /Developer/qt-mac-free-3.3.5/lib/libqt-mt.dylib -lz -ldl -lreadline -lSM -lICE -lX11 -lXext -lXmu -lXt -lXi -lCoin -ljpeg -lSoQt -framework OpenGL -- Cheers,Brian MingusAIM, Skype: BReflectionGoogle talk: [EMAIL PROTECTED]Phone: (720) 771-2599 ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool is "unfatting" my universal binaries
I am trying to make a universal binary out of our software on OSX. The general strategy is to configure with LDFLAGS/CXXFLAGS="-arch i386 -arch ppc". This seems to work for our convenience libraries, which become fat, but when it comes time to make one of our distribution libraries, libtemt, libtool recognizes the convenience libs are fat and "unfats" them! I produced a log: http://pastey.net/74970 I assume I am doing something wrong, although I know that libtool is unaware of mac universal binaries. Does anyone have suggestions for getting my libs to be i386/ppc, without resorting to building on the actual hardware for each and lipo'ing them together? Thanks and cheers, Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool is "unfatting" my universal binaries
Thanks. Can you explain why it only works on the host? I haven't tested it, but it doesn't make any sense to me. Why would the compiler/linker have the capability to produce libraries/binaries for another architecture if you can't run it on that architecture?! On 10/7/07, Benoit SIGOURE <[EMAIL PROTECTED]> wrote: > > On Oct 7, 2007, at 5:07 AM, Brian wrote: > > > I am trying to make a universal binary out of our software on OSX. > > The general strategy is to configure with LDFLAGS/CXXFLAGS="-arch > > i386 -arch ppc". This seems to work for our convenience libraries, > > which become fat, but when it comes time to make one of our > > distribution libraries, libtemt, libtool recognizes the convenience > > libs are fat and "unfats" them! > > > > I produced a log: http://pastey.net/74970 > > > > I assume I am doing something wrong, although I know that libtool > > is unaware of mac universal binaries. Does anyone have suggestions > > for getting my libs to be i386/ppc, without resorting to building > > on the actual hardware for each and lipo'ing them together? > > > > Thanks and cheers, > > Brian > > Hello Brian, > Sorry I'm not able to help you, though I'd like to warn you that > several Free projects have been bitten by universal binaries because > they haven't been careful enough to test the binary produced on both > Intel Macs and PPC Macs. Compiling with "-arch i386 -arch ppc" and > then running make check gives the false impression that the binary > produced work, because people easily forget it works only on the > $host. That's why they often build the the Intel and PPC versions > separately (and thus test them separately) and then `lipo' them > together. > > Cheers, > > -- > Benoit Sigoure aka Tsuna > EPITA Research and Development Laboratory > > > > ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool is "unfatting" my universal binaries
Peter, thanks for your comments. I build libtool from source, and am using 1.5.24. I manually ran the large link command, inserting `-arch i386 -arch ppc' after g++, and it did create a universal library: http://pastey.net/75062 But it's not clear to me what I need to do to get libtool to do this on its own, and also why it's not doing it. I modified CC/CXX in the Makefile to also pass the arch flags at that point, and the only difference is that when libtool is called, it gets them twice, and it proceeds to strip them out of the command twice! On 10/8/07, Peter O'Gorman <[EMAIL PROTECTED]> wrote: > > > On Oct 9, 2007, at 1:02 AM, Peter O'Gorman wrote: > > > > > On Oct 7, 2007, at 5:07 AM, Brian wrote: > > > >> I am trying to make a universal binary out of our software on OSX. > >> The general strategy is to configure with LDFLAGS/CXXFLAGS="-arch > >> i386 -arch ppc". This seems to work for our convenience libraries, > >> which become fat, but when it comes time to make one of our > >> distribution libraries, libtemt, libtool recognizes the > >> convenience libs are fat and "unfats" them! > >> > >> I produced a log: http://pastey.net/74970 > >> > >> I assume I am doing something wrong, although I know that libtool > >> is unaware of mac universal binaries. Does anyone have suggestions > >> for getting my libs to be i386/ppc, without resorting to building > >> on the actual hardware for each and lipo'ing them together? > >> > >> Thanks and cheers, > > > > Libtool is well aware of universal archives. ar x does not work > > with universal archives, so libtool uses lipo(1) to extract the > > objects for each architecture and put them back together again. > > This is because Mac OS X has no equivalent for GNU ld's --whole- > > archive flag. What is the problem, I do not see a failure in your log. > > Ah, I see, the -arch flags are being stripped. Update to a newer > version of GNU libtool (1.5.22 should do), or put the -arch flags in > the CC and CXX environment vars (e.g. ./configure CC='gcc -arch ppc - > arch i386'). > > Peter > -- > Peter O'Gorman > http://pogma.com > > > ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool is "unfatting" my universal binaries
Peter, `autoreconf -fi' fixed it. Thank you! On 10/9/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > On Mon, Oct 08, 2007 at 06:38:11PM -0600, Brian wrote: > > Peter, thanks for your comments. I build libtool from source, and am > using > > 1.5.24. I manually ran the large link command, inserting `-arch i386 > -arch > > ppc' after g++, and it did create a universal library: > > http://pastey.net/75062 > > > > But it's not clear to me what I need to do to get libtool to do this on > its > > own, and also why it's not doing it. I modified CC/CXX in the Makefile > to > > also pass the arch flags at that point, and the only difference is that > > when libtool is called, it gets them twice, and it proceeds to strip > them > > out of the command twice! > > > > Because libtool is included in the package that you are building, you > must ensure that the included libtool is also at a new enough version, > most people choose to use autoreconf to do this. If your package has a > bootstrap or autogen script then you may prefer to use that instead. > > Peter > > > ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool is "unfatting" my universal binaries
It kind of fixed it. Everything is universal, but nothing works because my libs/bins are linked against .out files in /var/tmp ! These files are not even present in that location when I look... [EMAIL PROTECTED]:/Users/mingus/emergent/src/temt/lib/.libs -> !otool otool -L libtemt-4.0.7.1.0.0.dylib libtemt-4.0.7.1.0.0.dylib: /usr/local/lib/libtemt-4.0.7.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/local/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) /var/tmp//ccmGRqIw.out (compatibility version 0.0.0, current version 0.0.0) /usr/local/lib/libgsl.0.dylib (compatibility version 11.0.0, current version 11.0.0) /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/local/lib/libsimage.20.dylib (compatibility version 27.0.0, current version 27.1.0) Inventor.framework/Versions/B/Inventor (compatibility version 46.0.0, current version 46.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) SoQt.framework/Versions/A/SoQt (compatibility version 25.0.0, current version 25.1.0) QtGui.framework/Versions/4/QtGui (compatibility version 4.2.0, current version 4.2.3) QtOpenGL.framework/Versions/4/QtOpenGL (compatibility version 4.2.0, current version 4.2.3) QtCore.framework/Versions/4/QtCore (compatibility version 4.2.0, current version 4.2.3) Qt3Support.framework/Versions/4/Qt3Support (compatibility version 4.2.0, current version 4.2.3) QtXml.framework/Versions/4/QtXml (compatibility version 4.2.0, current version 4.2.3) QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.2.0, current version 4.2.3) QtSql.framework/Versions/4/QtSql (compatibility version 4.2.0, current version 4.2.3) /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 240.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 18.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 22.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) [EMAIL PROTECTED]:/Users/mingus/emergent/src/emergent/bin/.libs -> otool -L ./emergent ./emergent: Inventor.framework/Versions/B/Inventor (compatibility version 46.0.0, current version 46.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) SoQt.framework/Versions/A/SoQt (compatibility version 25.0.0, current version 25.1.0) QtGui.framework/Versions/4/QtGui (compatibility version 4.2.0, current version 4.2.3) QtOpenGL.framework/Versions/4/QtOpenGL (compatibility version 4.2.0, current version 4.2.3) QtCore.framework/Versions/4/QtCore (compatibility version 4.2.0, current version 4.2.3) Qt3Support.framework/Versions/4/Qt3Support (compatibility version 4.2.0, current version 4.2.3) QtXml.framework/Versions/4/QtXml (compatibility version 4.2.0, current version 4.2.3) QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.2.0, current version 4.2.3) QtSql.framework/Versions/4/QtSql (compatibility version 4.2.0, current version 4.2.3) /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 240.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 18.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 22.0.0) /usr/local/lib/libemergent-4.0.7.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/local/lib/libtemt-4.0.7.1.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/local/lib/libgslcblas.0.dylib (compatibility version 1.0.0, current version 1.0.0) /var/tmp//ccmGRqIw.out (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9) /usr/local/lib/libgsl.0.dylib (compatibility version 11.0.0, current version 11.0.0) /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/local/lib/libsimage.20.dylib (compatibility version 27.0.0, current version 27.1.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) On 10/9/07,
Size does matter more than you think!!
Title: She was a really nasty girl, in fact a sadist. Laura made a strident sound.k2e4580n84750at53lpz58b6849vd043m6476g36e2963c886617823917i9 S.URPRISE YOUR L.OVER TODAY! COVER HER WHOLE FACE WITH C.UM! How w.ould you like to SHOOT LIKE THE PO.RN-STARS? Up to 500% more S.PERM! ADD UP_TO 500% MORE SPER.M INCREASED SE.XUAL DESIRE HAVE M.ORE INTENSE 0.RGASMS PRODUCE ST.RONGER E.RECTIONS HAVE A STRONGER 5.EXUAL DESIRE 1.NCREASED S.E..XUAL STAMINA FULLY DO.CTOR APP.ROVED! L.EARN MORE! 100% GUARAN.TEED! NOT SAT1SFIED? YOU GET YOUR MONE.Y BACK! 4m65x87b7in9g428y3ff9930h5604dki7y1190cd2563415276hg0213j5032f6jbz5rk2e4580n84750at53lpz58b6849vd043m6476g36e2She was a really nasty girl, in fact a sadist.Laura made a strident sound.963c886617823917i94m65x87b7in9g428y3ff9930h5604dki7y1190cd2563415276hg0213j5032f6jbz5rk2 To be r3m0v3d from our list, HereShe was a really nasty girl, in fact a sadist.She was a really nasty girl, in fact a sadist.Laura made a strident sound.She was a really nasty girl, in fact a sadist. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
mailing list archives
Hello, according to the http://www.gnu.org/software/libtool/>, the mailing list archives for this mailing list are kept at http://www.geocrawler.com/lists/3/GNU>. However, messages have stopped after mid-September 2000. For instance I can access this message OK: http://www.geocrawler.com/archives/3/404/2000/9/0/4316399/> (although that prediction seems to be overly optimistic now :-(. ) So, is there anything wrong with the mailing list and/or archives, or is there nothing worth getting discussed? -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: mailing list archives
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Brian> Hello, according to the Brian> http://www.gnu.org/software/libtool/>, the mailing Brian> list archives for this mailing list are kept at Brian> http://www.geocrawler.com/lists/3/GNU>. However, Brian> messages have stopped after mid-September 2000. Oh, I found it at http://mail.gnu.org/pipermail/libtool/>. Me thinks you should consider getting your web page up-to-date. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
interdependancies between libraries
rectory `/home/bam/source/cvs/libtool/depdemo/l3' make[2]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l3' make[2]: Nothing to be done for `install-exec-am'. /bin/sh ../../mkinstalldirs /home/bam/source/cvs/libtool/depdemo/a/lib/extra mkdir /home/bam/source/cvs/libtool/depdemo/a/lib/extra /bin/sh ../libtool --mode=install /usr/bin/install -c libl3.la /home/bam/source/cvs/libtool/depdemo/a/lib/extra/libl3.la libtool: install: warning: relinking `libl3.la' cd /home/bam/source/cvs/libtool/depdemo/l3; /bin/sh ../libtool --mode=relink gcc -g -O2 -o libl3.la -rpath /usr/local/lib/extra l3.lo ../l1/libl1.la ../l2/libl2.la gcc -shared l3.lo -Wl,--rpath -Wl,/usr/local/lib -L/home/bam/source/cvs/libtool/depdemo/l1/.libs -L/usr/local/lib -ll1 -ll2 -Wl,-soname -Wl,libl3.so.0 -o .libs/libl3.so.0.0.0 /usr/bin/ld: cannot find -ll2 collect2: ld returned 1 exit status libtool: install: error: relink `libl3.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/local/lib/extra' make[2]: Leaving directory `/home/bam/source/cvs/libtool/depdemo/l3' make[1]: Leaving directory `/home/bam/source/cvs/libtool/depdemo/l3' Making install in l4 make[1]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l4' make[2]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l4' /bin/sh ../../mkinstalldirs /home/bam/source/cvs/libtool/depdemo/a/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libl4.la /home/bam/source/cvs/libtool/depdemo/a/lib/libl4.la libtool: install: warning: relinking `libl4.la' cd /home/bam/source/cvs/libtool/depdemo/l4; /bin/sh ../libtool --mode=relink gcc -g -O2 -o libl4.la -rpath /usr/local/lib l4.lo ../l3/libl3.la -lm gcc -shared l4.lo -Wl,--rpath -Wl,/usr/local/lib/extra -L/home/bam/source/cvs/libtool/depdemo/l1/.libs -L/home/bam/source/cvs/libtool/depdemo/l2/.libs -L/usr/local/lib/extra -ll3 -lm -Wl,-soname -Wl,libl4.so.0 -o .libs/libl4.so.0.0.0 /usr/bin/ld: cannot find -ll3 collect2: ld returned 1 exit status libtool: install: error: relink `libl4.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/local/lib' make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/home/bam/source/cvs/libtool/depdemo/l4' make[1]: Leaving directory `/home/bam/source/cvs/libtool/depdemo/l4' make[1]: Entering directory `/home/bam/source/cvs/libtool/depdemo' make[2]: Entering directory `/home/bam/source/cvs/libtool/depdemo' /bin/sh ./../mkinstalldirs /home/bam/source/cvs/libtool/depdemo/a/bin mkdir /home/bam/source/cvs/libtool/depdemo/a/bin /bin/sh ./libtool --mode=install /usr/bin/install -c depdemo /home/bam/source/cvs/libtool/depdemo/a/bin/depdemo libtool: install: warning: `./l1/libl1.la' has not been installed in `/usr/local/lib' libtool: install: warning: `./l2/libl2.la' has not been installed in `/usr/local/lib' libtool: install: warning: `./l4/libl4.la' has not been installed in `/usr/local/lib' libtool: install: warning: `/home/bam/source/cvs/libtool/depdemo/l3/libl3.la' has not been installed in `/usr/local/lib/extra' libtool: install: warning: `/home/bam/source/cvs/libtool/depdemo/l2/libl2.la' has not been installed in `/usr/local/lib' libtool: install: warning: `/home/bam/source/cvs/libtool/depdemo/l1/libl1.la' has not been installed in `/usr/local/lib' /usr/bin/install -c .libs/depdemo /home/bam/source/cvs/libtool/depdemo/a/bin/depdemo /bin/sh ./libtool --mode=install /usr/bin/install -c depdemo.static /home/bam/source/cvs/libtool/depdemo/a/bin/depdemo.static /usr/bin/install -c depdemo.static /home/bam/source/cvs/libtool/depdemo/a/bin/depdemo.static make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/home/bam/source/cvs/libtool/depdemo' make[1]: Leaving directory `/home/bam/source/cvs/libtool/depdemo' (It took me awhile to notice that errors occurred, shouldn't it stop straight away? Maybe thats my fault for using CVS versions of autoconf and automake). Comments anyone? -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Separate Source Directories
>>>>> "Eric" == Eric Lemings <[EMAIL PROTECTED]> writes: Eric> I know Libtool doesn't currently support this feature but Eric> surely there are some software distributions out there that Eric> already do something like this? You can use convenience libraries... Current versions of libtool are broken (from my experience) in that you PIC code is used for static libraries. I read something in this mailing list about solving this problem, so hopefully it has already been fixed, at least in the CVS repository for version 1.4, but I have not yet tested this. You create a convenience library in Makefile.am (assuming you use automake) with something like: noinst_LTLIBRARIES = libvers.la libvers_la_SOURCES = print_version.c and link libvers.la into the main library. libtool should take care of the rest (this sample taken from Heimdal). (oh, before my patch the upstream version also had: libvers_la_LDFLAGS = -static which meant non-PIC code was compiled in the shared libraries. I didn't like this, so removed it). -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
>>>>> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes: >> On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote: > >> Oh, another observation: installing the libraries in their >> non-final > location (as required for Debian packaging tools, >> probably Redhat too) > simply does not work, as shown below. I >> think some of the required -L > options to the linker might be >> missing. > > Kevin> Some Debian libtool packages (eg. libgtk1.2) seem to get Kevin> away with Kevin> ./configure --prefix=/usr Kevin> but then overriding that for the install Kevin> make prefix=`pwd`/debian/tmp/usr install No - that is what causes this problem. Libraries get installed in `pwd`/debian/tmp, not /usr, where the linker (during "make install") can't find them. (Ok, I may have messed up my example :-(, but the same thing happens, I tried it too). -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
>>>>> "Ganesan" == Ganesan Rajagopal <[EMAIL PROTECTED]> writes: Ganesan> The correct way to do this is actually ./configure Ganesan> --prefix=/usr Ganesan> make install DESTDIR=`pwd`/debian/tmp Hmmm. didn't know this. Lets try it: [624] [snoopy:bam] ~/source/cvs/libtool/depdemo >configure --prefix=/usr [...] [628] [snoopy:bam] ~/source/cvs/libtool/depdemo >make clean [...] [629] [snoopy:bam] ~/source/cvs/libtool/depdemo >make [...] [633] [snoopy:bam] ~/source/cvs/libtool/depdemo >make install DESTDIR=`pwd`/debian/tmp Making install in l1 make[1]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l1' make[2]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l1' /bin/sh ../../mkinstalldirs /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib mkdir /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr mkdir /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libl1.la /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.la /usr/bin/install -c .libs/libl1.so.0.0.0 /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.so.0.0.0 (cd /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib && rm -f libl1.so.0 && ln -s libl1.so.0.0.0 libl1.so.0) (cd /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib && rm -f libl1.so && ln -s libl1.so.0.0.0 libl1.so) /usr/bin/install -c .libs/libl1.lai /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.la /usr/bin/install -c .libs/libl1.a /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.a ranlib /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.a chmod 644 /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl1.a libtool: install: warning: remember to run `libtool --finish /usr/lib' make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/home/bam/source/cvs/libtool/depdemo/l1' make[1]: Leaving directory `/home/bam/source/cvs/libtool/depdemo/l1' Making install in l2 make[1]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l2' make[2]: Entering directory `/home/bam/source/cvs/libtool/depdemo/l2' /bin/sh ../../mkinstalldirs /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib /bin/sh ../libtool --mode=install /usr/bin/install -c libl2.la /home/bam/source/cvs/libtool/depdemo/debian/tmp/usr/lib/libl2.la libtool: install: warning: relinking `libl2.la' cd /home/bam/source/cvs/libtool/depdemo/l2; /bin/sh ../libtool --mode=relink gcc -g -O2 -o libl2.la -rpath /usr/lib l2.lo ../l1/libl1.la gcc -shared l2.lo -L/usr/lib -ll1 -Wl,-soname -Wl,libl2.so.0 -o .libs/libl2.so.0.0.0 /usr/bin/ld: cannot find -ll1 collect2: ld returned 1 exit status libtool: install: error: relink `libl2.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/lib' [...] No, it doesn't work. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
>>>>> "Wesley" == Wesley W Terpstra <[EMAIL PROTECTED]> writes: Wesley> What I've been doing for debs with inter-depends is having Wesley> a local copy of ltmain.sh in my debian packages with the Wesley> patch applied for building my project. Then it adds the Wesley> right -L options. That seems to help the 2nd problem, Thanks. Any ideas on the first problem? -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
>>>>> "Wesley" == Wesley W Terpstra <[EMAIL PROTECTED]> writes: Wesley> Sorry, none. I'm not a libtool hacker though. :-) Maybe Wesley> someone else can solve it. However, the issue I see here Wesley> is that it's hard for libtool to know that you aren't Wesley> using the library that's pulled in by another library. I Wesley> mean, by linking to the library bar which uses library Wesley> foo, you're allowed to access foo's symbols. How is Wesley> libtool to know that you're not - read symbols listed Wesley> unresolved in your app? Yikes No hacks are required here. If you link in the library on the command line, then the code directly uses it. If you don't link the library on the command line, then a dependency is not required. Or put another way, if you specify that proga should be linked against libb (only), then proga should not be linked against libc, even if libb depends on libc, as this will occur at run-time. If the programmer forgets to directly link in an important library, and by pure coincidence it gets linked indirectly at run time, then that is the programmers fault, and libtool shouldn't go out of its way to try and resolve/break the issue. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: interdependancies between libraries
>>>>> "Wesley" == Wesley W Terpstra <[EMAIL PROTECTED]> writes: Wesley> On linux using -L doesn't affect run-time search path, so Wesley> my patch just uses that, but I understand that on other Wesley> archs. it does affect search path (you don't use Wesley> --Wl,rpath,/usr/foo/bar). So my hack won't work there. Yuck. I though -L always been link-time path, and never run-time path. I suspect you might have to treat these platforms as broken cases, and say that certain things might be broken for these platforms. (eg. the run time search path specifying the installation path - at least this way it should work, I think?). No sense in breaking a feature on *all* platforms just because some can't cope... -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
lib*.so symlink
Hello, Following a debate that regularly pops up on debian-policy (see http://bugs.debian.org/83669>), I have a simple (read: hopefully) question regarding the symlinks for shared libraries. (I assume that correct conventions have been used in the version number of the shared library). Currently the convention, at least on Linux is (for the example of libz): /usr/lib/libz.so -> libz.so.1 /usr/lib/libz.so.1 -> libz.so.1.1.3 /usr/lib/libz.so.1.1.3 where several people (including me) have been wondering if a better system would be: /usr/lib/libz.so -> libz.so.1.1.3 /usr/lib/libz.so.1 -> libz.so.1.1.3 /usr/lib/libz.so.1.1.3 The benefit here would be you have a installation like this /usr/lib/libz.so -> libz.so.1.1.2 /usr/lib/libz.so.1 -> libz.so.1.1.3 /usr/lib/libz.so.1.1.2 /usr/lib/libz.so.1.1.3 so programs use the previous version for compiling, but the latest versions for run-time. It is assumed that header files for the correct library have version been installed. I believe that libz.so.1.1.3 means that code compiled for libz.so.1.1.2 should still work fine, but at the same time, compiled code can be transferred to other computers which only has libz.so.1.1.2 installed. (you probably wouldn't want to do the reverse though - If my understanding is correct, code compiled for libz.so.1.1.3 would not run using libz.1.1.2) The only real concern I have with this proposal is libz.la (assuming libz is built with libtool). However, this is already a potential problem (programs designed for libz.so.1 could mistakenly use the libz.la file from libz.so.2 build). So I won't consider these problems here. Any comments? -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lib*.so symlink
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Where, by `correct', I hope you mean those of 1.1.2. Alexandre> Otherwise, 1.1.3's headers might get you using features Alexandre> of 1.1.3. For example, it would be perfectly legal for Exactly. >> The only real concern I have with this proposal is libz.la >> (assuming libz is built with libtool). However, this is already >> a potential problem (programs designed for libz.so.1 could >> mistakenly use the libz.la file from libz.so.2 build). So I >> won't consider these problems here. Alexandre> Presumably, libz.la would be that from the older Alexandre> version, since libz.la is used for linking. And then, Alexandre> because libtool sets dlname to the SONAME of the Alexandre> library, you'd still get the newer version dlopened. Alexandre> The only problem scenario is if you don't have the .la Alexandre> file: you'd probably end up dlopening the .so, that Alexandre> points to the older version. If, for whatever reason, Alexandre> the program is also explicitly linked with the library Alexandre> it dlopens, you'd have two different versions of the Alexandre> same library linked in. I have no idea of what kind of Alexandre> probably might come up. All I know is that I wouldn't Alexandre> like to be there :-) I am somewhat skeptical this problem would ever occur. The only time I have seen dlopen used is for plugin modules, which aren't relevant to this discussion anyway (file.so is the only one installed). Alexandre> So it seems to me that the policies already in place Alexandre> are enough to support this kind of us. The package Alexandre> manager would have be adjusted so as to keep the .so Alexandre> and the .la of the earliest version of a library (as Alexandre> per the lib-dev package), and the .so.MAJOR of the Alexandre> latest version thereof (as per the lib package). Or Alexandre> something like that :-) Agreed. In the discussion on debian-policy, there was some concern that this system would break ldconfig, but it appears that these concerns are not justified. For instance ldconfig will (apparently) update the libz.so.2 symlink to point to the latest version of the library installed, which is exactly what we want. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lib*.so symlink
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Alexandre> Presumably, libz.la would be that from the older Alexandre> version, since libz.la is used for linking. And then, Alexandre> because libtool sets dlname to the SONAME of the Alexandre> library, you'd still get the newer version dlopened. What might go wrong if libz.la points to the newest version, not the oldest version? Anyway, I would like to extend my original proposal slightly: Currently the convention, at least on Linux is (for the example of libz): /usr/lib/libz.la /usr/lib/libz.so -> libz.so.1 /usr/lib/libz.so.1 -> libz.so.1.1.3 /usr/lib/libz.so.1.1.3 proposed: /usr/lib/libz.so -> libz.so.1.1.3 /usr/lib/libz.la -> libz.la.1.1.3 /usr/lib/libz.so.1 -> libz.so.1.1.3 /usr/lib/libz.so.1.1.3 /usr/lib/libz.la.1.1.3 The benefit here would be you have a installation like this /usr/lib/libz.so -> libz.so.1.1.2 /usr/lib/libz.la -> libz.la.1.1.2 /usr/lib/libz.so.1 -> libz.so.1.1.3 /usr/lib/libz.so.1.1.2 /usr/lib/libz.so.1.1.3 /usr/lib/libz.la.1.1.2 /usr/lib/libz.la.1.1.3 So multiple copies of the *.la file can now be installed at the one time, and the *.la symlink is managed in a similar way to the *.so symlink. While this has benefits specific to Debian (the libz.la doesn't need to conflict between multiple packages, eg. when it is required in the run-time library package), I believe it could also help for the general case to (the system administrator can point *.la file to different version if desired for some reason). Any comments? -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lib*.so symlink
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: I will describe the problem, maybe you could think of a better solution. ;-) Current libraries under Debian are made of two sets of packages, for example: libx1: /usr/lib/libx.so.1 (symlink) /usr/lib/libx.so.1.2.3 libx2: /usr/lib/libx.so.2 (symlink) /usr/lib/libx.so.2.2.3 libx-dev: /usr/lib/libx.so(symlink) /usr/lib/libx.la /usr/include/* This is fine for the following situation: Alexandre> (i) when linking with a libtool library, it determines Alexandre> any additional dependencies that have to be linked in. Alexandre> You must make sure it corresponds to the actual Alexandre> dependencies of the library you're using for linking, Alexandre> as well as the one you're going to use at run-time. However, it is not good for this situation: Alexandre> (ii) when dlopening a libtool module, it determines the Alexandre> SONAME to be used, as well as the dependencies that may Alexandre> have to be dlopened before the library itself. You Alexandre> want it to match the library you're using at run-time. As users have to install the -dev library even though they aren't developing/compiling anything. So the obvious solution is to move libx.la (and possible libx.so) into libx1 and libx2, but that means libx1 and libx2 both conflict and cannot be installed at the same time :-( The benefit of the symlink, is it doesn't have to be included in the package, but can be created by some script after installing or removing the library. Then again, I probably should ask how many libraries need to be dlopened, it probably isn't many, so creating a separate package containing only libx.so and libx.la may not be such a big problem. Alexandre> In both cases, changing a single link, either the .so Alexandre> or the .so.MAJOR, would have been enough, while Alexandre> changing the .la file would generally have no effect at Alexandre> all. So just to get matters straight (I am still not quite sure of this). For situation i) what linking libx.la, the version pointer to by libx.so is used? ii) when dlopening libx.la, the version pointed to by libx.so is used? -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lib*.so symlink && patches
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> /usr/lib/libz.so -> libz.so.1.1.3 /usr/lib/libz.la ->
Brian> libz.la.1.1.3 /usr/lib/libz.so.1 -> libz.so.1.1.3
Brian> /usr/lib/libz.so.1.1.3 /usr/lib/libz.la.1.1.3
Me and my big mouth. I went to implement the code for this, but found
it is already done ;-).
Here is the first version of a patch (apply to CVS version of libtool
1.4) which seems to fix the interdependency problem I complained about
earlier. I didn't find it easy to find the correct spot to edit, but
it seems to work fine.
This patch means that libtool relies on Linux to keep track of
interdependencies, instead of trying to manage it itself (with serious
limitations).
This seems to fix all the problems I have bought up recently, except
the *.la issue (which I don't consider as important, yet).
I have labelled a few things with !FIXME! - these are parts which I
think could be done better, but I haven't done either because my
solution would require looking up information from the *.la file, and
I am not really familiar with the best way to do that.
Any questions, please ask.
diff -ruN libtool-1.3c-old/ltmain.in libtool-1.3c/ltmain.in
--- libtool-1.3c-old/ltmain.in Mon Feb 5 09:51:14 2001
+++ libtool-1.3c/ltmain.in Mon Feb 5 12:23:26 2001
@@ -1537,6 +1537,30 @@
*) . ./$lib ;;
esac
+ relink_dependency_libs="$dependency_libs";
+ case "$version_type" in
+ linux)
+ # Linux already supports dependencies internally, so
+ # we don't have to do it ourselves.
+
+ # we only need to keep track of non-installed dependancies
+ # for link time, this is so the linker can find
+ # the library (!FIXME! we should use probably use rpath instead)
+ tmp_libs=
+ for deplib in $dependency_libs; do
+ case "$deplib" in
+ # !FIXME! Could *.la files refer to installed libraries?
+ -l*) deplib=""
+ esac
+ tmp_libs="$tmp_libs $deplib"
+ done
+ dependency_libs="$tmp_libs"
+
+ # At relink time, all dependancies are done for us.
+ relink_dependency_libs="";
+ ;;
+ esac
+
if test "$linkmode,$pass" = "lib,link" ||
test "$linkmode,$pass" = "prog,scan" ||
{ test $linkmode != prog && test $linkmode != lib; }; then
@@ -3760,7 +3784,7 @@
output="$output_objdir/$outputname"i
# Replace all uninstalled libtool libraries with the installed ones
newdependency_libs=
- for deplib in $dependency_libs; do
+ for deplib in $relink_dependency_libs; do
case "$deplib" in
*.la)
name=`$echo "X$deplib" | $Xsed -e 's%^.*/%%'`
--
Brian May <[EMAIL PROTECTED]>
Re: lib*.so symlink
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> If libx is a module, that's unfortunately true: you Alexandre> really can't have them both installed at the same time. Alexandre> You can only have one .la file at a time, and that's Alexandre> all lt_dlopen will look for. It doesn't support Alexandre> versioning. Maybe it should? `lt_versioned_dlopen Alexandre> (libname, current, revision, age)' sounds like a good Alexandre> addition to libltdl. Then, it would make a lot of Alexandre> sense to install versioned copies of libx.la modules. Alexandre> The down side is that we'd have to duplicate the Alexandre> versioning code in libltdl :-( But this looks promising Alexandre> to me. Any takers? If nobody else wants to look at this, I will, after I am satisfied the previous problems have been fixed (with regards to interlibrary dependencies). -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building shared libs as dynamically-loaded perl modules
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> And that's the catch. On some platforms, you just Alexandre> can't link static libraries into shared ones. Not even Alexandre> if they're PIC. Yuck. Alexandre> Convenience libraries, with the Alexandre> abstraction of ``aliases to sets of objects'', should Alexandre> just work. It's just that they are not currently Alexandre> installable. I wish they were. And I wish convenience Alexandre> libraries could still come in PIC and non-PIC versions, Alexandre> just like object files. Currently, every time you Alexandre> create a convenience archive, you don't get the non-PIC Alexandre> objects, unless the PIC objects aren't available. I agree here. I think convenience libraries need to compile two sets of libraries: *.a which contains non-PIC code and *.al which contains PIC code. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
install phase fails
Hello, for some reason this hasn't been a problem (with libtool 1.4) until just now (maybe upgrading to glibc 2.2.3 from 2.2.2 triggered it)? Anyway, the following demo fails badly when installed in a non-standard location (as required by Debian packages): [509] [snoopy:stable:bam] ~/tmp/libtool-1.4/mdemo >make install prefix=$PWD/a make[1]: Entering directory `/home/bam/tmp/libtool-1.4/mdemo' /bin/sh ./../mkinstalldirs /home/bam/tmp/libtool-1.4/mdemo/a/lib mkdir /home/bam/tmp/libtool-1.4/mdemo/a mkdir /home/bam/tmp/libtool-1.4/mdemo/a/lib /bin/sh ./libtool --mode=install /usr/bin/install -c libsub.la /home/bam/tmp/libtool-1.4/mdemo/a/lib/libsub.la /usr/bin/install -c .libs/libsub.so.0.0.0 /home/bam/tmp/libtool-1.4/mdemo/a/lib/libsub.so.0.0.0 (cd /home/bam/tmp/libtool-1.4/mdemo/a/lib && rm -f libsub.so.0 && ln -s libsub.so.0.0.0 libsub.so.0) (cd /home/bam/tmp/libtool-1.4/mdemo/a/lib && rm -f libsub.so && ln -s libsub.so.0.0.0 libsub.so) /usr/bin/install -c .libs/libsub.lai /home/bam/tmp/libtool-1.4/mdemo/a/lib/libsub.la /usr/bin/install -c .libs/libsub.a /home/bam/tmp/libtool-1.4/mdemo/a/lib/libsub.a ranlib /home/bam/tmp/libtool-1.4/mdemo/a/lib/libsub.a chmod 644 /home/bam/tmp/libtool-1.4/mdemo/a/lib/libsub.a libtool: install: warning: remember to run `libtool --finish /usr/local/lib' /bin/sh ./libtool --mode=install /usr/bin/install -c foo1.la /home/bam/tmp/libtool-1.4/mdemo/a/lib/foo1.la /usr/bin/install -c .libs/foo1.so /home/bam/tmp/libtool-1.4/mdemo/a/lib/foo1.so /usr/bin/install -c .libs/foo1.lai /home/bam/tmp/libtool-1.4/mdemo/a/lib/foo1.la/usr/bin/install -c .libs/foo1.a /home/bam/tmp/libtool-1.4/mdemo/a/lib/foo1.a ranlib /home/bam/tmp/libtool-1.4/mdemo/a/lib/foo1.a chmod 644 /home/bam/tmp/libtool-1.4/mdemo/a/lib/foo1.a libtool: install: warning: remember to run `libtool --finish /usr/local/lib' /bin/sh ./libtool --mode=install /usr/bin/install -c libfoo2.la /home/bam/tmp/libtool-1.4/mdemo/a/lib/libfoo2.la libtool: install: warning: relinking `libfoo2.la' cd /home/bam/tmp/libtool-1.4/mdemo; /bin/sh ./libtool --mode=relink gcc -g -O2 -o libfoo2.la -rpath /usr/local/lib -no-undefined -module -export-symbols-regex "libfoo2.*" foo2.lo -lm libsub.la generating symbol list for `libfoo2.la' /usr/bin/nm -B foo2.lo | sed -n -e 's/^.*[]\([ABCDGISTW][ABCDGISTW]*\)[ ][ ]*\(\)\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2\3 \3/p' | sed 's/.* //' | sort | uniq ]> .libs/libfoo2.exp egrep -e "libfoo2.*" ".libs/libfoo2.exp" > ".libs/libfoo2.expT" mv -f ".libs/libfoo2.expT" ".libs/libfoo2.exp" gcc -shared foo2.lo -Wl,--rpath -Wl,/usr/local/lib -lm -L/usr/local/lib -lsub -Wl,-soname -Wl,libfoo2.so.0 -Wl,-retain-symbols-file -Wl,.libs/libfoo2.exp -o .libs/libfoo2.so.0.0.0 /usr/bin/ld: cannot find -lsub collect2: ld returned 1 exit status [ this is where it failed for the first time. It can't find -lsub, because it didn't specify the path using -L. ] libtool: install: error: relink `libfoo2.la' with the above command before installing it libtool: install: warning: remember to run `libtool --finish /usr/local/lib' /bin/sh ./../mkinstalldirs /home/bam/tmp/libtool-1.4/mdemo/a/bin mkdir /home/bam/tmp/libtool-1.4/mdemo/a/bin /bin/sh ./libtool --mode=install /usr/bin/install -c mdemo /home/bam/tmp/libtool-1.4/mdemo/a/bin/mdemo libtool: install: warning: `libsub.la' has not been installed in `/usr/local/lib' /usr/bin/install -c .libs/mdemo /home/bam/tmp/libtool-1.4/mdemo/a/bin/mdemo /bin/sh ./libtool --mode=install /usr/bin/install -c mdemo.static /home/bam/tmp/libtool-1.4/mdemo/a/bin/mdemo.static /usr/bin/install -c mdemo.static /home/bam/tmp/libtool-1.4/mdemo/a/bin/mdemo.static make[1]: Nothing to be done for `install-data-am'. make[1]: Leaving directory `/home/bam/tmp/libtool-1.4/mdemo' [note: this test conducted on a stable Debian system; it also fails on unstable. It use to work on unstable, the only change I can think of is Linux 2.4.4 instead of 2.4.3 and glibc 2.2.3 instead of 2.2.2 ] -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: install phase fails
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> The problem has to do with requiring relinking at Alexandre> install time. This is necessary when one library in Alexandre> the build tree depends on another library in the build Alexandre> tree. The other library must be installed first, and, Alexandre> when the former is to be installed, the other must Alexandre> already be accessible in its previously-specified Alexandre> installation path, which is different from the prefix Alexandre> you have specified at install time. Alexandre> In general, when relinking is necessary, you must not Alexandre> use a different prefix to install than the one used to Alexandre> build. In which case, you are saying that libtool is completely broken and unusable for creating Debian packages? You can't have both set the same, the package has to be created from the build directory, and it gets installed in the correct spot when the package gets installed. I imagine it will be much the same for creating RPMs, too, but I have never done that myself. Also, why did this work with libtool 1.4, but then suddenly stop working? -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: install phase fails
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: Alexandre> In general, when relinking is necessary, you must not Alexandre> use a different prefix to install than the one used to Alexandre> build. Brian> In which case, you are saying that libtool is completely Brian> broken and unusable for creating Debian packages? You can't Brian> have both set the same, the package has to be created from Brian> the build directory, and it gets installed in the correct Brian> spot when the package gets installed. ... or is it possible to prevent/disable this relinking? I really fail to see why relinking is required on Linux (glibc), you should be able to do everything just by setting LD_LIBRARY_PATH as required. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: install phase fails
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> The problem has to do with requiring relinking at
Alexandre> install time. This is necessary when one library in
Alexandre> the build tree depends on another library in the build
Alexandre> tree. The other library must be installed first, and,
Alexandre> when the former is to be installed, the other must
Alexandre> already be accessible in its previously-specified
Alexandre> installation path, which is different from the prefix
Alexandre> you have specified at install time.
Alexandre> In general, when relinking is necessary, you must not
Alexandre> use a different prefix to install than the one used to
Alexandre> build.
Brian> In which case, you are saying that libtool is completely
Brian> broken and unusable for creating Debian packages? You can't
Brian> have both set the same, the package has to be created from
Brian> the build directory, and it gets installed in the correct
Brian> spot when the package gets installed.
I will rephrase my question: what method should I use in order to
temporarily install shared libraries into a different place for
packaging?
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: install phase fails
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> In any case, we do have a problem in libtool; it should Alexandre> somehow help the linker find libsub even though it's Alexandre> not installed in the expected place. I suppose we Alexandre> could just use the uninstalled version to link whatever Alexandre> other libraries depend on it, if we find the library is Alexandre> not installed yet. This will break on HP-UX, but we Alexandre> can probably live with that. In fact, there's no other Alexandre> way around. Alexandre> Patches are welcome :-) There was a patch sent to this mailing list several months ago, when libtool 1.4 was not released. Does that still apply cleanly? (I didn't bother with this before, because my initial tests of libtool 1.4 final said everything was OK - I don't know what has changed since). One quick fix solution might be to give the linker a parameter like: -L$prefix/lib to help it find the installed libraries, even if this is at a non-standard location. However, I would be very cautious, if the linker searched /usr/lib first(??), it might link the wrong version of the library. My preferred fix would be to replace instances of .../path/to/lib/liba.la with something like .../path/to/lib/.libs/liba.so which would be guaranteed to get the correct library. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [marcelo.magallon@bigfoot.com: Re: [Mesa3d-dev] Re: libtool]
Peter Eisentraut wrote: > > Sven M. Hallberg writes: > > > We use the formula > > version-info = Major+minor:Mesa_version:Minor > > to compute proper libtool version-info from the OpenGL version number (1.2) > > and our current Mesa release number (MM.Mm.Mt, e.g. 3.5.0). So, Mesa_version > > is an integer derived from that release number. We'd like to use > > Mesa_version = MM * 10^4 + Mm * 10^2 + Mt > > which would yield something like 30500. However libtool only accepts three > > digits for the REVISION part of the version-info (as Marcelo mentions below). > > You must have missed the part of the documentation that says: > > :*_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. > > (not my emphasis) > > The documentation describes in detail how you are supposed to set the > three version fields. Anything else will be trouble. I'm not going to put a lot of effort into explaining this but here's the story. Mesa's used the convention libGL.so.1.2.xxyyzz for some years now. The "1.2" indicates the library implements the OpenGL 1.2 API. Anything else there would be VERY confusing for end users at this point. The last part "xxyyzz" is usually something like 030402 to indicate Mesa version 3.4.2. With this convention, people can look at their libGL.so.1.2.xxyyzz file and determine which version of Mesa they're using. It also allows various versions of libGL.so.1.2.* to coexist. This very useful for the developers so we may easily switch between versions when doing regression testing. I understand that libtool has a specific versioning convention and we don't want you to change that. It's just that if the REVISION part could accomodate a 6-digit number (with leading zeros) we'd be grateful. -Brian ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Search paths with duplicated .la libraries
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: Alexandre> Yep. In general, you can't have multiple libraries Alexandre> with the same base name. This is a real problem when compiling a package in a non-standard location (eg. when creating Debian packages). If an old copy of the library exists in /usr/lib, then that will get used instead of the library that has just been compiled. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Hack for inter-library dependency (make DESTDIR=... install) problem.
>>>>> "Rob" == Rob Browning <[EMAIL PROTECTED]> writes: Rob> For those stuck on this problem (and presuming we're not just Rob> using libtool improperly in Guile) I've figured out a Rob> temporary hack that will allow you to build and install Rob> packages in temporary (i.e. not --prefix) directories when Rob> you have inter-library dependencies. Rob> I just had to add a spurious -L for the build directory of Rob> the depended on library whereever appropriate. i.e. Rob> libguilereadline_la_LIBADD = ../libguile/libguile.la Rob> became Rob> libguilereadline_la_LIBADD = -L`pwd`/../libguile/.libs Rob> ../libguile/libguile.la Rob> This may add an unwanted -rpath, so if someone has a better Rob> suggestion, I'd be happy to hear it. While this would work, it has the (IMHO) nasty side affect that any libraries previously installed in, say /usr/lib, will take priority (I think) over the library that was just built in the source code tree. It also means hacking around with the Makefiles. -- Brian May <[EMAIL PROTECTED]> ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Slow shell script execution on Cygwin
Tor Lillqvist wrote: > Hmm, but I guess the fork/exec separation makes this harder, Cygwin > can't know when it is emulating fork() whether the child process will > immediately exec() one of the above. Or does the Cygwin shell(s) > already have some special code instead of plain fork()/exec()? I believe that Cygwin's ash used to be compiled to use vfork(), which apparently is faster by some degree under Cygwin. (I don't know the details here.) However as of the last[*] ash release on 2004-01-27 this has been changed so that it's back to standard fork/exec. It seems clear that Cygwin would benefit from some kind of special casing in the shell because of the fork penalty, but apparently no one has the time or is capable of providing this, if it's even feasible. [*] http://marc.theaimsgroup.com/?l=cygwin&m=107520010817415&w=2 Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Slow shell script execution on Cygwin
Brian Dessent wrote: > It seems clear that Cygwin would benefit from some kind of special > casing in the shell because of the fork penalty, but apparently > no one has the time or is capable of providing this, if it's even feasible. Uhh, nevermind. Upon checking it seems that all the old vfork stuff has been ripped out and not used for some time, and vfork = fork. So it really doesn't matter what the shell tries to do, it looks like expensive fork is going to be called regardless. :( Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Unhelpful behaviour on Cygwin when "file" isn't installed
Ralf Wildenhues wrote: > > The user who reported this to me says that cygwin doesn't come with > > file by default either (he'd installed it very recently, so I guess > > he probably has the latest release). I'm a little suprised by this, > > but don't have cygwin myself so I can't check if this really is the > > case. > > Cygwin is very configurable. So you can probably choose to (un)install > file, independently of other choices. Yes, 'file' is in its own individual package so it can be selected/deselected at will. However this package is not in the category 'Base' which means if you just fire up the Cygwin setup utility and accept the default set of packages it will not be installed. However, the 'Base' category includes essentially no development tools (gcc, binutils, make, perl, etc are absent) so it is not intended as a functional starting point for anyone doing development. On the other hand, it would be very easy for someone to select the majority of development tools and still neglect to install 'file'. This is exacerbated by the fact that it is in the category 'Utils' and not 'Devel' so even if you select all of 'Devel' you won't get it. If libtool currently displays somewhat degraded or broken behavior without 'file' then it would be a good idea to at least add 'file' to this 'Devel' category in the Cygwin package DB. This would be a rather simple change and I don't think there would be much trouble getting it done. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Unhelpful behaviour on Cygwin when "file" isn't installed
Olly Betts wrote: > Does the cygwin packaging chooser have the concept of dependencies? > 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. Yes, it does, and that is a much better way of handling this. I will follow up on the appropriate Cygwin list. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Unhelpful behaviour on Cygwin when "file" isn't installed
Olly Betts wrote: > I don't think there's an obvious dependency cygwin could add to help > this (unless perhaps something rather arbitrary like making 'make' > depend on 'file'). So libtool (or rather packages it generates) > probably does need to cope with file not being installed (or perhaps > just check for it in configure and get the user to install it). I think > for now I'll just add such a check to my project's configure. In that case adding 'file' to the 'Devel' category might help, since people seem to like to add whole categories. Although a configure check or some kind of fallback would be best. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Why '-R' option doesn't support relative path?
Hi, experts, I need to build Ekiga on solaris, which uses libtool to do the compiling and linking I need to set '$ORIGIN' in final executable RUNPATH. So user can install Ekiga anywhere he likes. I uses '-R $ORIGIN' to achieve this. But libtool told me that '-R' option doesn't support relative path. Can someone tell me why or if there is a workaround? Thanks Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
handling of missing AR
Hello, (Ralf, thanks for your previous email.) I've had a libtool-related problem reported with a test release of GNU GSL on a Solaris system with gcc & Sun ld, but missing 'ar'. I am using libtool-1.5.22 autoconf-2.59 automake-1.9.6 for GSL. The configure stage on this system gives (coming from AC_PROG_LIBTOOL), checking for ar... false checking for ranlib... : checking for strip... : And the build then fails later (as expected) on the first use of 'ar' with false cru .libs/libutils.a .libs/placeholder.o make[2]: *** [libutils.la] Error 1 The question was asked "Why doesn't configure stop with an error when it finds ar is missing?" I didn't have a good answer to that. For the average user the final error message is a hard to decipher. Is there any reason I shouldn't put a test in the configure script to bail out if ar is not found?---since I'm building static and shared libraries it is always going to be needed I think. Thanks for any insights, -- Brian Gough (GSL Maintainer) http://www.gnu.org/software/gsl/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: handling of missing AR
Ralf Wildenhues writes: > Erm. The user did not have /usr/ccs/bin in $PATH? Right, /usr/ccs/bin was not in the PATH. > Well yes, but sometimes ar is not needed, for example it /may/ not be > needed when --disable-static is given. Okay > Naa. Kean Johnston already suggested adding /usr/ccs/bin to the PATH > for those tests (or was that /usr/ccs/bin/elf or both? I'll go and > check). Could you check with the user that those tools are available > there? Then let's do that to fix the actual failure instead. I've checked and they do have ar in /usr/ccs/bin so that would work. -- Brian Gough ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool: unrecognized option `--tag=CC'
Tomislav Par?ina wrote: > Thank you for quick reply. Those are my versions. > > [EMAIL PROTECTED] ~]# libtool --version > ltmain.sh (GNU libtool) 1.5.16 (1.1220.2.235 2005/04/25 18:13:26) > [EMAIL PROTECTED] ~]# automake --version > automake (GNU automake) 1.9.5 > > So they are not that old. From what you have told me, it won't make any > difference if I upgrade... The versions of the tools on your system are irrelevent unless you are the package's developer, i.e. you are the person that created the source tarball. When just building somebody else's source code you are using whatever version they used to create the package. That is why Ralf said "due to the package using". The normal way that the autotools work is that the distributed tarball is standalone, i.e. it includes copies of all generated files so that the user doesn't even need autoconf/automake/libtool installed on their system. This means the developer of the package decides what versions are used, which is normally a good thing. In your case you might need to regenerate everything, you can normally do this with "autoreconf --install --force". Sometimes though it is not that simple, and in those cases you need to run a script that invokes the tools in the right order with the right options, usually named something like "autogen.sh", "bootstrap.sh", etc. But what you really should do is report the failure to the package's author so that he/she can address the version disparity (if that indeed is the problem.) Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: hardcode_libdir, rpath and DLLs
Robert Szeleney wrote: > Unfortunately, PE DLLs don't support this --rpath option. Is there any > way to tell libtool to use something different for this? > > Probably using LD_LIBRARY_PATH. Though I think that this will not > really work, because whenever you execute glib-genmarshal one would > have to set this path. (Inside the make process this may not be really > a problem, but when executing directly from the shell no one has set > this path yet). > > How does cygwin deal with this? Does this even work on cygwin? Win32 doesn't have any such notion of LD_LIBRARY_PATH, so that is not an option. The DLL search rules are very simple, I think it's essentially 1. current working directory, 2. $PATH, 3. Windows system directory. There may be other obscure modifiers too. The full search order is documented on MSDN under the LoadLibrary() function I think. I suspect the right way to handle this would be to use "libtool --mode=execute" to run the binary, and that should either set the working directory to the dir where the DLL lives or set $PATH. Or maybe libtool uses a wrapper script for the binary. [ Note that Cygwin does actually support LD_LIBRARY_PATH but only when doing dynamic runtime loading of a library with dlopen(), but it can only do this because at that point Cygwin is fully in control of things and can fake it. When simply calling on the operating system to load a binary (in the case of ./foo) there is no way to influence the DLL search process since that is done by the Windows dynamic loader. ] Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: questions about DLLs built with libtool - multiple output files...
Ed Hartnett wrote:
> -rw-rw-rw- 1 ed root 1043050 Jun 1 07:44 libnetcdf.a
> -rw-rw-rw- 1 ed root 360432 Jun 1 07:44 libnetcdf.dll.a
> -rw-rw-rw- 1 ed root 632482 Jun 1 07:44 cygnetcdf-1.dll
libnetcdf.a is the static archive for static linking, and gets placed in
/usr/lib.
libnetcdf.dll.a is the import library for the DLL and also gets placed
in /usr/lib. This is what the linker will actually find when the user
specifies -lnetcdf to link, and it essentially just contains a list of
the functions that the DLL exports -- it does not contain any code.
Both of the above are developer files only needed at link time, not
runtime.
cygnetcdf-1.dll is the dynamic library itself and gets placed into
/usr/bin. This is important because on Windows there is no RPATH
embedded in the library. Instead the search order is pretty much just
"current directory then PATH", with a couple of really obscure
modifiers. This means that DLLs have to be in the PATH, and /usr/lib is
not typically in the path, but /usr/bin is.
Recent versions of ld can link against DLLs directly without needing an
import library, but the traditional way is to include them. This is an
important distinction when you have multiple ABI versions hanging around
-- for example, there might be cygnetcdf-{1,2,3}.dll installed in
/usr/bin to support compiled binaries of various vintages. However, the
import library filename is not versioned, and there is only a singular
one on the system, typically of the current/latest ABI.
There are also some things (such as symbol aliasing) that can only be
achieved with an import library that are not possible by directly
linking to a DLL. There is a section in the ld manual that explains
this.
> Which one do I give to the user as "the" dll for the library.
>
> Also, I seem to recall reading that it was possible to generate dlls
> which either did or did not depend on the cygwin dll being present on
> the machine. True?
It is possible, but it's not quite that simple. There are essentially
two separate toolchains: cygwin and mingw. Cygwin implements its own C
library and POSIX emulation layer (cygwin1.dll), whereas mingw targets
the existing Microsoft-provided C library (MSVCRT.DLL) and provides
essentially zero compatibility/emulation layering.
The tradeoff here is that most posix source code can be compiled
unmodified under Cygwin at the cost of a dependancy on cygwin1.dll.
With Mingw there is no dependance on emulation libraries, however there
is often significant porting work to be done because MSVCRT includes
*very* little of the posix API beyond the minimum required by C89. For
example, fork() and exec() flat out do not exist, and signals are so
crippled as to not exist (see
<http://marc.theaimsgroup.com/?l=mingw-users&m=114338148907578&w=4> for
details on this.) And when using sockets you must use the Winsock API,
which is very similar to the posix socket API, but has some gotchas
(e.g. socket handles are not regular fds and so you can't mix and match
files and sockets in a select().) In summary, when using Mingw you
typically must target -- or at least be aware of -- the Windows API to
accomplish most nontrivial tasks.
Cygwin's gcc provides the necessary framework for using both toolchains
at once, via the -mno-cygwin switch, which is what you are probably
referring to. So it is true that under Cygwin you can create a DLL that
does not depend on cygwin1.dll by simply using -mno-cygwin. However, it
does not just magically remove this dependancy, it switches the compiler
to a very different toolchain, with an associated set of issues as
explained above. This means it's not a magic bullet that can just
surgically remove Cygwin without any other changes.
Also be aware that you can't mix and match cygwin and mingw object files
in a given project, as these two toolchains have entirely different C
runtimes. Invoking -mno-cygwin switches over a completely different set
of system headers and link options, so you should really treat them as
two different compilers. In other words, if you configure with "CC=gcc
-mno-cygwin", do it in its own build tree away from the Cygwin build
tree, just as if you were cross compiling.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: trying to build with MinGW under cygwin, but no luck, can't find dllcrt2.o
Ed Hartnett wrote: First, a note: the Cygwin list generally does not like to field questions about -mno-cygwin because when doing so you are using another project's toolchain, and so it's kind of off-topic. However, I think your problem is actually build-environment related and not gcc related, so I will continue, with reply-to set to the libtool list. > I am trying to build my libtool-based library package on Cygwin, with > the -mno-cygwin option. > > However, I am getting the following problem: > > libtool: link: cc -shared .libs/attr.o .libs/ncx.o .libs/putget.o > .libs/dim.o .libs/error.o .libs/libvers.o .libs/nc.o .libs/string.o > .libs/v1hpg.o .libs/var.o .libs/posixio.o -Wl,--whole-archive > ./.libs/libnetcdf2.a ../fortran/.libs/libnetcdff.a > -Wl,--no-whole-archive -mno-cygwin -o .libs/cygnetcdf-1.dll > -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker > .libs/libnetcdf.dll.a > /usr/bin/ld: dllcrt2.o: No such file: No such file or directory > collect2: ld returned 1 exit status > make[2]: *** [libnetcdf.la] Error 1 > make[2]: Leaving directory `/cygdrive/c/netcdf-3/libsrc' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/cygdrive/c/netcdf-3' > make: *** [all] Error 2 > > I am trying to figure out what is wrong. Does anyone have an easy > answer for me? Something here looks rather broken. First, a non-cygwin DLL should never be named "cygnetcdf-1.dll" because the prefix "cyg" is specifically used for this purpose, i.e. so that they are never found by non-Cygwin apps. A mingw DLL should be named libnetcdf-1.dll. So this makes me think libtool is confused and thinks you're trying to build a native package. Second, dllcrt2.o is a mingw startup file and should be present in /usr/lib/mingw. If not then you certainly have an installation problem. Confirm that you can compile and link a hello world program with "gcc -mno-cygwin" before continuing. It would help if you would post more details, such as how you configured the package. When trying to build a mingw package under Cygwin you are in effect cross compiling, so the configury should probably look something like the following, although there are many ways to skin a cat: ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin CC="gcc -mno-cygwin" (And if you use C++ then CXX="g++ -mno-cygwin", and so on.) Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: g++ linking problem
S3 wrote: > I see other messages similar to this in the mailing list, > but I don't see any resolution yet. > > I am having a problem linking C++ programs. > (I have attached the logs from compiling MySQL and KDE arts.) > The programs compile just fine, but when it tries to link > them, it fails to find all basic C++ symbols, such as those > from libstdc++. I have libstdc++-v3 installed. > When I use g++ ordinarily, it links to libstdc++ just fine. > > Specifically, it can't find: > __cxa_pure_virtual > std::basic_string This is usually caused by the user trying to link by invoking gcc instead of g++ when C++ code is involved. If you link with g++ it knows to include all the necessary flags and options to support C++, which does not happen when invoked as gcc. However, in your case, libtool is being used which adds another layer of indirection on top of things. Unfortunately your configuration (or perhaps the package itself) is invoking "libtool --silent", which means that the libtool wrapper isn't printing the actual command that it's executing, which means those tens of thousands of lines of spew you attached are more or less useless for determining the actual problem. You could have saved everybody reading a lot of time by just incluing the the part that causes the error, which was: /bin/sh ../libtool --silent --tag=CXX --mode=link g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -march=pentium4 -O2 -pipe -fomit-frame-pointer -mmmx -msse2 -fstack-protector -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -ftemplate-depth-99-o libmcop.la -rpath /usr/kde/3.5/lib -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -version-info 1:0 -L/usr/kde/3.5/lib -L/usr/qt/3/lib -L/usr/lib [many .lo files] -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 ../libltdl/libltdlc.la .libs/buffer.o: In function `Arts::Buffer::readString(std::basic_string, std::allocator >&)': buffer.cc:(.text+0x6c1): undefined reference to `std::basic_string, std::allocator >::assign(char const*, unsigned int)' In any case, this is not the right list to post on. I suggest you post this to the libtool list (CC:d), or the mailing list of the package itself. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool + MinGW
Brendon Costa wrote: > Would someone be able to have a look at the script file and let me know > what i am doing wrong? I'm not sure why you are getting the link errors about duplicated symbols, but your testcase in general is not doing what you think it's doing. You'll note that there is not a DLL created anywhere, and this is because you didn't use -no-undefined. On win32 systems this is required to generate shared libraries, owing to the fact that the windows dynamic loader cannot do "lazy" linking -- all referenced symbols must be resolved at link-time. Without this flag libtool cannot assume that you've met this condition, and so it cannot do anything but create a static library, even if it was told to make a shared lib. The message "libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries" when creating libShared and libLTDLopened indicates this. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool + MinGW
Brendon Costa wrote: > Question: Does libtool 1.5.22 for MinGW support shared libraries and > using DLOpened modules without dlpreopening? Of course it supports shared libraries. > If so in the example i gave before for a shared library was created > using ar cru and not g++ -shared and was linked into the app as a static > library. No, your example was flawed because it did not pass -no-undefined, which means you get static libraries unconditionally. If you fix that, then libtool builds both shared and static versions of the library, and it successfully links against the shared library libshared-0.dll. The only one of the four that fails to build is the static plugin version, which dies with the duplicated symbol problem. $ ls -l total 1737 -rwxr-xr-x1 brianAdminist 588238 Jun 11 19:08 LTDLOpened-0.dll -rw-r--r--1 brianAdminist 119454 Jun 11 19:08 LTDLOpened.a -rw-r--r--1 brianAdminist 7902 Jun 11 19:08 LTDLOpened.dll.a -rw-r--r--1 brianAdminist 819 Jun 11 19:08 LTDLOpened.la -rwxr-xr-x1 brianAdminist 585327 Jun 11 19:08 libShared-0.dll -rwxr-xr-x1 brianAdminist 465800 Jun 11 19:08 libltdl-3.dll -rwxr-xr-x1 brianAdminist 606208 Jun 11 19:08 libtool_test.exe -rwxr-xr-x1 brianAdminist 589161 Jun 11 19:08 libtool_test_np.exe -rwxr-xr-x1 brianAdminist 591364 Jun 11 19:08 static_libtool_test_np.exe > I guess i assumed that MinGW platform supported shared libraries using > DLL's. If not are there any plans for this in the future? Mingw would be quite useless if shared libraries did not function. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: questions about DLLs built with libtool - multiple outputfiles...
Ed Hartnett wrote: > ./configure --host=i686-pc-mingw32 --build=i686-pc-cygwin CC="gcc > -no-cygwin" This is a typo, you want "-mno-cygwin" not "-no-cygwin". > But when searching for a compiler, it tells me this: > > checking for i686-pc-mingw32-xlc... gcc -no-cygwin > > What is this i686-pc-mingw32-xlc business? That would appear to be libtool or autoconf searching for a working C compiler, since "gcc -no-cygwin" probably gave an error about incorrect parameters. But that's just a wild guess. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool/ltmain linking wrong stdc++
Taj Morton wrote: > I was hoping for a solution that maybe involved sedding the libtool file, or > something like that. If I can't acomplish it that was, I guess I can just > modify > Autopackage's wrapper around gcc/g++ to link the compilers libstdc++.so. Can't you just build+install a private version of libkdecore with gcc 3.2, and then ensure that that one is found when building your lib by specifying CXXFLAGS/LDFLAGS as appropriate? Or put another way, if you're going to do the "build everything with two separate toolchains" thing then doesn't that mean you have to extend that logic to building not just your app/lib but all dependant libs that are referenced in the final app? It seems like it would be a lot easier just to have a chroot or vmware type setup, with gcc-3.2/libstdc++.so.5/whatever-other-libs-of-that-era all segregated so that no modern libs pollute the build. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Absolute paths generated by libtool.
Duft Markus wrote: > Additionally cygwin does not > correctly work on SMP machines with win2k or higher. Need a shovel for that FUD you're slinging? ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
Bob Rossi wrote: > I know the symbols are in the library because nm tells me so, > $ nm -g /home/bobbybrasko/download/pcre/pcre/install/lib/libpcre.a|grep > compile > libpcre_la-pcre_compile.o: > 5550 T _pcre_compile Note here that this is just a regular symbol, as you would expect with a non-shared library. > -I/home/bobbybrasko/download/pcre/pcre/install/include > C:/WINDOWS/TEMP/ccgGAsIC.o(.text+0x2e): In function `main': > C:/msys/1.0/home/bobbybrasko/download/pcre/pcre/build/tmp/test.c:13: > undefined reference to `_imp__pcre_compile' > But here you're trying to dllimport the symbol. But you don't want to do that in the case of static linking. You'll have to look at the header and see how the dllimport/dllexport is #defined, usually it means you have to add some extra -DSTATIC or similar when you are using the static archive so that the prototypes are not defined dllimport. If libpcre is a libtoolized library and you used libtool to compile instead of invoking gcc yourself it should take care of this for you, though. That's kind of the whole point of libtool, to abstract this away. > Does anyone understand why I'd be getting these errors? Are .def files > important for static windows libraries or only for dll's? Any advice? AFAIK .def files have absolutely nothing to do with static libraries, which are just collections of .o files really. A .def file is used to express what symbols a given .dll exports and imports, but these concepts don't even exist in the case of a static library. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
Bob Rossi wrote: > So, the correct way is to tell the author to remove the declspec's > alltogether from the header file? That will work for both dynamic and > static setup? No, it's not the right way. The right way is to add -DPCRE_STATIC to the CPPFLAGS. When linking against a DLL without __declspec(dllimport), it will still work but it's suboptimal as there will be an extra jump instruction through the function stub (and possibly an extra relocation to resolve, I don't remember.) This means the binary is larger and slower. Although the extent of this is debatable, you don't want to do that if you can avoid it, which you can by just using -DPCRE_STATIC, which is how it was designed to work. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: windows static archive, missing symbols
Howard Chu wrote:
> That's false. It's just an address relocation, performed by the runtime
> linker. Writing code that requires XXX_STATIC macros is nothing but
> ignorant, and hasn't been necessary for at least 5 years.
You know I did actually test this before posting. Go on, do a hello
world that calls a dllimported function. Here is the testcase I used:
#include
void foo(void);
int main()
{
puts("main");
foo();
}
Without any __declspec on the declaration to foo, the disassembly in the
debugger is:
6 {
0x401050: push %ebp
0x401051: mov$0x10,%eax
0x401056: mov%esp,%ebp
0x401058: sub$0x8,%esp
0x40105b: and$0xfff0,%esp
0x40105e: call 0x401090 <_alloca>
0x401063: call 0x401120 <__main>
7 puts("main");
0x401068: movl $0x402000,(%esp)
0x40106f: call 0x401130
8 foo();
0x401074: call 0x401080
9 }
0x401079: leave
0x40107a: ret
And note that 0x401080 is the import stub that calls __imp_foo:
0x401080: jmp*0x404098
Now, add the __declspec(dllimport) and recompile. This is what you get
now:
6 {
0x401050: push %ebp
0x401051: mov$0x10,%eax
0x401056: mov%esp,%ebp
0x401058: sub$0x8,%esp
0x40105b: and$0xfff0,%esp
0x40105e: call 0x401090 <_alloca>
0x401063: call 0x401120 <__main>
7 puts("main");
0x401068: movl $0x402000,(%esp)
0x40106f: call 0x401130
8 foo();
0x401074: call *0x404098
9 }
0x40107a: leave
0x40107b: ret
Note that here you get a direct call to the .idata location of the
imported address (__imp_foo aka 0x0404098) without the extra call.
So, no, it is not the same to omit dllimport, there is a (small) speed
penalty. And there was recently a patch posted and applied to binutils
that will eliminate these stubs if they are not necessary so once you
upgrade your binutils there will be a size penalty to not using
dllimport also.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: problem with libtool's choice in "library_names=" under MingW port- .dll.a and .lib not the same!
Ed Hartnett wrote: > My C library builds fine, but when it tries to build the very first > test, it fails, because it tries to link to libnetcdf.lib instead of > libnetcdf-4.dll. > > This is strange to me. I don't understand why, under MingW, this > works: > > gcc -g -O2 -o .libs/t_nc.exe t_nc-t_nc.o ./.libs/libnetcdf-4.dll > -L/usr/local/lib > > And this doesn't: > > gcc -g -O2 -o .libs/t_nc.exe t_nc-t_nc.o ./.libs/libnetcdf.lib > -L/usr/local/lib > > When libnetcdf-4.dll and libnetcdf.lib are copies of each other. In > fact, the names has to end with ".dll" or the link fails. Here's the > versions of gcc and ld: Something is horribly wrong if the .lib is the same as the .dll. That is not how it works. The .lib file is supposed to be an import library, same as the .dll.a file. They are just two different names for the exact same thing. I don't know why you're bothering with a .def file, either. You can simply do -Wl,--out-implib,foo.dll.a to have the import library created at the same time as the .dll. You can rename/copy foo.dll.a to foo.lib if you want for MSVC people, they are exactly the same thing. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] New library "type" needed?
Charles Wilson wrote: > I have a library that I want to build shared (let's call it "libbfd"). > It depends on a portability library that is currently built as a > non-libtool, static library (let's call it "libiberty"). 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? 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. And its maintainers do not want the burden of having to maintain an ABI given its history of not being designed as such. So it seems like a really bad idea to jump through hoops to make it shared, as you'd end up with the situation you mentioned dozens of cygbfd-.dll files to satisfy all the various consumers. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Making shared libraries (DLLs) on Windows: -no-undefined
John Brown wrote: > In all cases, ld would find the symbols easily, if only it would try. Is > libtool really complaining about these so-called undefined symbols? If that > is so, why? Why does it not just try to build the DLL? If ld fails because > of undefined symbols, then it can say so at that time. > > Is that if I am building my.dll on Windows, and it consists only of my.c, > which calls only functions in my.c, then -no-undefined is not required, but > otherwise, -no-undefined is necessary? > > Should I tell the libamrnb maintainer that configure needs to add > --no-undefined on Windows, or Windows users should configure with > LDFLAGS=-no-undefined? Libtool will *not* create shared libraries without -no-undefined on PE targets, period. It's not about it trying to detect whether there are or are not any undefined symbols, it's about the maintainer telling libtool that it is safe to assume or not assume something. So yes, you need to either use -no-undefined unconditionally, or conditionalized on PE targets. See <http://article.gmane.org/gmane.comp.gnu.mingw.user/18727> for a little of the history. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Making shared libraries (DLLs) on Windows: -no-undefined
John Brown wrote: > Running 'nm --undefined-only libamrnb-2.dll' gives: > > U ___crt_xc_end__ > U ___crt_xc_start__ > U ___crt_xi_end__ > U ___crt_xi_start__ > U ___crt_xl_start__ > U ___crt_xp_end__ > U ___crt_xp_start__ > U ___crt_xt_end__ > U ___crt_xt_start__ > U ___tls_end__ > U ___tls_start__ > U __end__ > > If undefined symbols are not allowed, then what's that? Those are labels created by the linker script. They represent locations, not data. You can refer to them in your C code only as &__foo__, never as __foo__. I don't know why they are marked U. In any case, this is not at all the same situation as function or data imports. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Making shared libraries (DLLs) on Windows: -no-undefined
Bob Rossi wrote: > Yup, I think this is the topic that I've been asking about. Not that I > don't like it, but some of the users of a library I help maintain don't > like it. I don't seem to have an easy way to make libtool just output > the name of the dll with out the -. I don't see why you can't just use -avoid-version. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool woes
Jason Curl wrote: > /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -version-info > 0:0:0 -o libtp.la -rpath /usr/local/lib version.lo > libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin > shared libraries Libtool won't build shared libraries on Win32/PE targets without -no-undefined in *_LDFLAGS. The text of this warning message could perhaps be clearer, because it's not telling you that you necessarily have any undefined symbols, it's telling you that you didn't assure libtool that you don't. > lib -OUT:.libs/libtp.lib version.o > ../libtool: line 5973: lib: command not found I'm not sure why it's trying to use lib here, that seems wrong if you're using gcc/binutils. Possibly a configure problem? Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool woes
Jason Curl wrote: > I guess what happens if I don't say this the build will fail. I've It should produce static libraries if it cannot produce shared ones. > turned it on and it looks good. I'll try and search more info later, but > while I'm at it: > - Why is it .dll.a and not .dll? > - How is versioning information embedded in the DLL, or is the basis of > the DLL hell? .dll.a is the import library. .dll is the actual library. Both should be produced. The import library is used when linking against the library, but it is not needed at runtime and contains no code. It's typically distributed in the same context as headers -- it is needed by developers who want to build against your library, but not users who simply want to run software that uses your library. In some cases it is also named just "libfoo.a", or perhaps "foo.lib" if you want compatibility with users of the MS toolchain. As its name suggests this is actaully an "ar" archive. It looks like you may be getting confused because the linker outputs a message along the lines of "creating file libfoo.dll.a" when the --out-implib linker switch is used, but this really means "in addition to the normal output libfoo.dll I'm also producing an import library libfoo.dll.a as a side effect of creating the library" not that the library would actually be named libfoo.dll.a. The concept of an import library is a bit of a hold-back to days past. Using the GNU linker at least, you can link directly to a DLL without any import library. However, there is one function of an import library that cannot be duplicated otherwise, and that is the ability to provide aliases for symbol names. This allows you to do things like rename functions in the actual library without affecting callers/users that use the old name. It also comes in very handy when reconciling differences in stdcall function decoration when trying to mix code between different vendors' toolchains. PE has no means of explicit symbol versioning. Shared library versioning works on the basis of choosing an appropriate filename for the library, i.e. libfoo-n.dll. This should happen automatically when you use -version-info appropriately. The import library thus also provides one further function that makes it very handy -- it functions analogously to the "foo.so -> foo.so.1" symlink on POSIX systems. The import library is always named just libfoo.dll.a without any version numbers, and so the linker finds it when you specify -lfoo. However, the actual name of the library may be libfoo-2.dll (or cygfoo-2.dll if you're using Cygwin) and hence the import library is the thing that selects which version of the library to link against. For example on Cygwin: $ ls -l /usr/bin/cygintl* /usr/lib/libintl* -rwxr-x---+ 1 brian Users 22K Dec 13 2001 /usr/bin/cygintl-1.dll -rwxr-x---+ 1 brian Users 37K Aug 10 2003 /usr/bin/cygintl-2.dll -rwxr-x---+ 1 brian Users 31K Nov 19 2005 /usr/bin/cygintl-3.dll -rwxr-x---+ 1 brian Users 31K Oct 22 2006 /usr/bin/cygintl-8.dll -rwxr-x---+ 1 brian Users 48K Oct 22 2006 /usr/lib/libintl.a -rwxr-x---+ 1 brian Users 30K Oct 22 2006 /usr/lib/libintl.dll.a -rwxr-x---+ 1 brian Users 800 Oct 22 2006 /usr/lib/libintl.la Here you see that there are four versions of the libintl library installed, however there is just the one import library. The name of the DLL is encoded into the import library, so this means any new code that is compiled today with -lintl will find /usr/lib/libintl.dll.a which internally specifies the filename corresponding to ABI version 8 of the library. But the other versions can still exist on disk for the sake of supporting existing binary packages of the previous ABI versions. So this works just like the symlink on POSIX that selects which version of the library all new binaries should link against (which is almost always the newest.) Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Why is "setting LD_LIBRARY_PATH very bad"?
Wintaki Hagabashi wrote: > - Perhaps it is possible to create a replacement library that some > suid application uses and you can then gain root access (maybe there > are other things stopping this from happening?) On linux at least, LD_LIBRARY_PATH is ignored when invoking something that has the setuid or setgid bit. > - Big pain when developing, have to make sure your LD_LIBRARY_PATH is > always set correctly, pointing to your build area. And then if you > have multiple checkouts (perhaps working on a branch), you need to > keep changing your LD_LIBRARY_PATH. But this is the libtool list, and the above is exactly the kind of tedium that libtool takes care of for you so that you don't have to worry about it. > Having said that, I don't see what the problem is really in a > controlled environment with production installations? Again, using my > Oracle example, there is no way they could force you to install into a > special place. They require setting LD_LIBRARY_PATH. Obviously you > don't want every single utility and application installed having its > own special lib dir, but isn't that the normal thing to do for > large(r) software distributions? Especially commercial software? > > And what is a real problem is when you do need to move a package. > THen the rpath can cause a big headache for you depending on the > situation. If you ask me, these binary packages should either: A. Play nice with the existing package management system of the distro by shipping in a .deb/.rpm/whatever package that: - installs to the system locations like /usr/lib, /usr/bin, /usr/share, etc. - allows clean install/uninstall/upgrade/remove using the familiar package manager commands - captures the library dependencies of the software so that all required support items of the required versions are also automatically installed - prevents accidents like the user running routine security updates from the distro which installs an incompatible version of some lib because the binary software's requirements were not communicated to the package management system (i.e. the general principle of: don't mess around behind the back of the package management system, it's there to help you, not something that gets in the way.) or B. Ship with an install script that updates /etc/ld.so.conf to add the required paths. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking with libtool & mingw
Robert Schwebel wrote: > Info: resolving _deflate_copyright by linking to __imp__deflate_copyright > (auto-import) > Info: resolving __dist_code by linking to __imp___dist_code (auto-import) > Info: resolving __length_code by linking to __imp___length_code (auto-import) > Info: resolving _z_errmsg by linking to __imp__z_errmsg (auto-import) These are completely normal if you are porting software that does not explicitly dllimport symbols. They are not errors. > etronix-Wireshark-trunk-Win/build-target/wireshark-0.99.6/.libs/wireshark.exeS.c:(.data+0x9a4c): > undefined reference to `_g_module_name > ' > .libs/wireshark.exeS.o:/some/path/wireshark-0.99.6/.lib > s/wireshark.exeS.c:(.data+0x9a5c): undefined reference to `_g_module_open' > .libs/wireshark.exeS.o:/some/path/wireshark-0.99.6/.lib > s/wireshark.exeS.c:(.data+0x9c4c): undefined reference to > `__g_async_queue_get_mutex' > .libs/wireshark.exeS.o:/some/path/wireshark-0.99.6/.lib > ... > collect2: ld returned 1 exit status There is not enough information to help you based only on the error. We need to see the full link command, at least. It would also be helpful to know what object or library contains the symbols that are listed as undefined. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Jason Curl wrote: > ./configure CC="gcc -mno-cygwin" LDFLAGS="-Wl,--kill-at" > --target=i586-pc-mingw32 --disable-static > on Cygwin to generate the Windows DLL Target is not the right thing to use here. Target only has meaning in the context of building tools that themselves generate code, such as compilers, linkers, assemblers, etc. If you want to simply indicate that you are cross-compiling a library for a host different than the current one then you use --host. Also, if you're going to use Cygwin as a "Fake mingw" then you probably also should use --build=mingw as well. > I have also another subdirectory that tests the library but I can't link to > it using mingw. First it doesn't recognise that the name was simplified (it > looks for [EMAIL PROTECTED] for example instead of _my_func/my_func). You need to understand that the --kill-at is a linker option. It cannot change behavior of the compiler, and when gcc is told to use the stdcall calling convention for a function, it includes the normal stdcall decorations on the symbol. There is no way to change this AFAIK, unless you use __attribute__((alias)) or something. So if you want to use these symbols without the stdcall decoration, then you have to get the linker to jump throuh hoops. --kill-at removes them from names that are exported, but that still doesn't change the fact that the compiler emits calls to the decorated names. For that you will have to use --enable-stdcall-fixup, which will link calls to [EMAIL PROTECTED] to _foo if there is no [EMAIL PROTECTED] found anywhere. Or, you could create an import library and link with that. But instead of all of that I think I would just simply use --add-stdcall-alias. This should result in both a decorated and undecorated alias of each symbol being exported, so you don't have to try to pretend that gcc isn't emitting calls to decorated names when it really is. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Jason Curl wrote: > libtest.exe <-- Doesn't seem to work? No idea >what this is... > libtest > .libs/ > libtest.exe<-- Will work when "libmofo-1.dll" >is in the path, e.g. copied to >this dir. > > Can anybody explain what libtool is doing?? It appears to do a lot of > nifty stuff, but I don't see any dependencies on "libmofo" from > "libtest.exe" in either case. I'll attach a minimal example when I'm > back at work tomorrow. It is a wrapper to allow running the uninstalled binary in the build tree without having to mess with PATH or LD_LIBRARY_PATH or whatever. On a POSIX system this would be a shell script. I think that in libtool HEAD, it won't have such a confusing name. > And the directory it runs from (.libs) indicates it is actually the > source "lt-libtest.c" that relies on a shell, so as soon as I move the > executable to a "virgin" computer without Cygwin, the program > "libtest.exe" won't work. You shouldn't be manually mucking about like that, you use "make install" to get an installed copy and that will not be a wrapper. If you configured with CC="gcc -mno-cygwin" (i.e. used this "fake mingw" setup) then the Cygwin dependence should only be for the wrapper which isn't supposed to be installed or even moved out of the build directory for that matter. > I'd also like to generate .lib files (what is the .a file that is > generated anyway? Is that the .lib import library?) An import library can be named foo.lib, libfoo.a, or libfoo.dll.a; they are all the exact same thing just named differently. Don't confuse the libfoo.a name with a static library which has the same style name but is a totally different thing (and that's why it's considered deprecated to name an import library libfoo.a, but some are still done that way, e.g. all of w32api.) Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Windows DLLs from Unix with minimum effort
Jason Curl wrote:
> For Posix systems I agree (and I haven't had to care until now). It's an
> unnecessary burden for w32api however, especially for users that don't have
> any kind of sane build environment. I guess I'm saying I don't know how to
> package the result so that someone on w32 can use it on a standard cmd.exe
> console without having Cygwin, etc. installed. This environment is only
> necessary for the build.
The wrapper is totally irrelevant to end users, it is only for the
convenience of the developer to be able to run the binary uninstalled.
To make a binary package to give to end users you do the exact same
thing that you would on a POSIX system to create a binary package:
make install DESTDIR=/some/staging/area
# or make install prefix=/some/staging/area
(cd /some/staging/area && tar jcf binary-package.tar.bz2 *)
[ aside ]
The choice of whether you use DESTDIR or override prefix is mildly
controversial. Some hand-written makefiles don't support DESTDIR, and
DESTDIR doesn't play nicely if you're using Win32 paths because you
can't prepend something in front of a drive letter to produce a valid
path. But if you use automake you automatically get DESTDIR support, so
it's fairly common, as well as being a part of the GNU coding standards
spec.
On the other hand overriding prefix normally doesn't require any special
makefile support, other than the invariant that overriding it must not
cause anything to be rebuilt (which is also specified by the GCS.) It
also is the only route if you're using Win32 paths since they can't be
prepended. But I don't personally like it because it becomes clumsy if
you have specified more than just --prefix at configure time (and they
aren't subdirectories of prefix that can use ${prefix}). For example if
I am making binary packages for a typical distro, I might configure
with:
path/to/configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
Now I've built and want to install to a staging area in order to create
the binary package. If I use DESTDIR, I can simply:
make install DESTDIR=/tmp/mypackage
...and the entire tree as originally configured will install under that
staging area. However if I want to use the override technique I must
remember all of the options that I originally specified and be sure to
override them all appropriately:
make install prefix=/tmp/mypackage/usr sysconfdir=/tmp/mypackage/etc \
localstatedir=/tmp/mypackage/var
So not only is it more typing, but I've duplicated my configuration in
two places which can easily get out of sync. This is not a concern in
the common case where only --prefix was given, since all the other paths
have defaults that symbolicly reference $prefix, e.g.
exec-prefix='${prefix}' and bindir='${exec-prefix}/bin' and
libdir='${exec-prefix}/lib' and so on, so they will take the correct
values when only prefix is overridden. And in fact if you can specify
these as subdirectories of prefix or exec-prefix or whatever it's
advisable to continue to use this syntax so that you can simply override
prefix and have everything else follow. But as I said I simply find
DESTDIR a cleaner solution that involves less worry.
[ end aside ]
To cater to the typical Win32 user you might want to flatten the
heirarchy, since they are typically used to having everything in one
dir, so e.g. --bindir='${prefix}' --libdir='${prefix}'
--docdir='$[prefix}' (and so on for a million other variables) which
would result in the binary-package.tar.bz2 created above simply being a
flat set of files. But I guess it all depends on your target audience
and how you plan to distribute things (e.g. NSIS, InnoSetup, 7-zip sfx,
.zip file, whatever.)
> Or should I revert to a different build environment? This is my first attempt
> at using Autoconf to build something for native Windows (mostly because I
> want to use it on Linux, but other colleagues of mine benefit from it's use
> on Windows).
Using Cygwin to build MinGW executables is common but suboptimal.
Unless you really know what you're doing it's very easy to shoot
yourself in the foot: for example you might leak POSIX paths from the
build/configure system into a header or configuration file (or other
generated file), which the resulting binary will be clueless about since
it's a native MinGW app that only speaks Win32 paths. I'd recommend
using MinGW+MSYS instead if you don't intend to build Cygwin programs.
Also relocatability is a whole other ball of wax that you have to
address when building for MinGW, because the user expectation is that
they can install the files in any location -- as opposed to Cygwin where
you have a mount table that handles that bit of indirection and presents
a uniform filesystem layout despite the actual location on disk.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Favoring static linking at configure time
Benoit Sigoure wrote:
> shared libraries). The first case that comes to my mind is Windows
> where there used to be import libraries named in libfoo.a (whereas
> they are now named libfoo.dll.a or whatever). But maybe this was a
> long time ago so it's not common enough to bother?
Every one of the w32api import libraries is named according to the old
scheme so yes this is still extremely common and won't be going away any
time soon. You really shouldn't have to care what the filename is
though.
> 2nd problem: when you use -lfoo, GCC (at least) seems to always use
> libfoo.{so,dylib,sl,you-name-it} rather than libfoo.a. AFAIK there
> is no switch to kindly ask it to use the .a version (what people do
> usually is that they pass the full path to the .a on the link command
> line).
Of course there is: -Wl,-Bstatic -lfoo -Wl,-Bdynamic
> So yeah the general question basically boils down to: is it possible
> to test at configure time whether a static version of a given library
> is available and ensure that it's used during the build?
I'm not sure how you'd do this with libtool per se, but in general why
can't you just try a test link with -Bstatic -lfoo, if that succeeds
then use that, otherwise fall back to just -lfoo.
Brian
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Favoring static linking at configure time
Benoit Sigoure wrote: > > Of course there is: -Wl,-Bstatic -lfoo -Wl,-Bdynamic > > Hmm I didn't know this. How portable is it? I guess a gccism, but > is it even portable across versions/ports of GCC? It doesn't really have anything to do with gcc, it's the linker that interprets these options. -Wl is the only part gcc sees and that has been in gcc forever. I'm not sure if other compilers have options for "pass this to the linker" or not. -B seems to be fairly portable; all of the following support it: GNU ld: <http://sourceware.org/binutils/docs-2.18/ld/Options.html> Solaris ld: <http://docs.sun.com/app/docs/doc/819-2239/6n4hsf6n2?l=en&a=view> FreeBSD ld: <http://www.freebsd.org/cgi/man.cgi?query=ld&apropos=0&sektion=1&manpath=FreeBSD+6.2-RELEASE&format=html> NetBSD ld: <http://netbsd.gw.com/cgi-bin/man-cgi?ld++NetBSD-current> Irix ld: <http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/u_man/cat1/ld.z> Looks like Tru64 does not however: <http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/MAN/MAN1/0180.HTM> Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Favoring static linking at configure time
Peter Rosin wrote: > to make link.exe select by itself. As Microsoft themselves typically > doesn't have any libraries that are available both as dlls and static > (do they?), there is no conflict (for them). MS would use foo.lib for They do. But the differentiate them by filename, not by extension. For example the C runtime comes in a number of flavors: libc.lib - single-threaded, static libcd.lib - single-threaded, static, debug libcmt.lib - multi-threaded, static libcmtd.lib - multi-threaded, static, debug msvcrt.lib - multi-threaded, shared msvcrtd.lib - multi-threaded, shared, debug So the last two are really import libs whereas the first four are real static archives. But I think this particular example is a little flawed since most people select one of the above by command line switches (/ML, /MLd, /MT, /MTd, /MD, /MDd respectively). [ There's a similar set for the C++ runtime and the mixed managed/native runtimes as well, see <http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx>. ] Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linking with extern DLLs under Cygwin
Peter Rosin wrote: > It is not terribly hard to create those import libraries semi- > manually. dlltool can do most of the work. Is that not an > option for you? That or simply a symlink libfoo.dll.a -> ../bin/cygfoo-n.dll. In the official Cygwin distro all devel packages contain import libs, so I'd consider this a bug in the ICU package if it can't generate one. One can be created as a side effect of linking the DLL simply by adding -Wl,-out-implib,libfoo.dll.a. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: v1.5.27a 'syntax error' in numerous packages
snowcrash+libtool wrote: > i'm guessing the nomially required rm-ing is somewhere inbetween the > two actions; likely at least (just?) the aforementioned > 'ltoptions.m4'? If you keep your build dirs around you can do a much better job of surgically removing a package: make install DESTDIR=/tmp/deleteme && \ find /tmp/deleteme \( -type f -o -type l \) -printf '/%P\0' | \ xargs -0 rm; rm -rf /tmp/deleteme This simply installs the package again in an empty throwaway dir and uses the resulting filelist to delete from the live system. Of course, you may want to fortify this in various ways: pick a more appropriately named temp dir, make sure it's empty at first, sanity check the list of files to delete, ensure the package supports DESTDIR (vs. prefix overriding) etc. But you get the general idea of the method. Some packages generalize this with a "make uninstall" rule. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: different object sets in shared and static libs
John Calcote wrote: > Is there a way to specify additional objects (sources) for the shared > library that will not be linked into the static library. You could always wrap the entire contents of the file with "#ifdef PIC". The objects would still be in the static lib but they would be essentially empty files. I know, not the cleanest solution. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Testing doesn't work so well, but it builds
Bruce Korb wrote: Hi Brian, Harlan, and libtool-ers, On Tue, Jun 24, 2008 at 4:59 PM, Brian Utterback <[EMAIL PROTECTED]> wrote: Bruce is correct that the problem has to do with "-R" but you don't do "-R" the way he is using it here. I need to point out that "he" isn't doing anything with the "-R". I have to depend upon libtool to take canonical link commands and transform them into whatever is needed for a particular platform. If the "-R" option to the linker is not being configured correctly, then they need to know about it. I'll update my libtool as soon as there is a fix. Regards, Bruce On Solaris, the link time library search path is separate from the run time library search path. The -L flag sets the link time (compile time) library search path, and the -R flag sets the run time path. If the library you are linking to is already installed in the same place and the directory it is in is not on the default search path, then you need to set the directory with both a -L and a -R. You use them the same way, on the command line. $ bash -x cc.sh + gcc -DHAVE_CONFIG_H -g -DTEST_TEST_NESTED_OPTS -I/pogo/users/bkorb/autogen- 5.9.6pre6 -I/pogo/users/bkorb/autogen-5.9.6pre6/_b -I/pogo/users/bkorb/autoge n-5.9.6pre6/_b/agen5 -I/pogo/users/bkorb/autogen-5.9.6pre6/_b/autoopts -I/pog o/users/bkorb/autogen-5.9.6pre6/agen5 -I/pogo/users/bkorb/autogen-5.9.6pre6/a utoopts -I/usr/local/gnu/include -o nested nested.c /pogo/users/bkorb/autogen -5.9.6pre6/_b/autoopts/.libs/libopts.a /pogo/users/bkorb/autogen-5.9.6pre6/_b /autoopts/.libs/libguileopts.a -Wl,-R -L/usr/local/gnu/lib -lguile -lguile -lt ^^ dl -lsocket -lnsl -lm -lgen That looks better, but: $ ./nested -? ld.so.1: nested: fatal: libguile-ltdl.so.1: open failed: No such file or directory Killed Yes, -Wl,-R supplies a -R to the linker, but the -R to the linker needs an argument, the same as the -L. Also, it is usual to supply the -R the same way as the -L, as a plain flag to the compiler. The compiler knows to pass it to the linker. Brian Utterback I notice that the configure script tests whether -Wl,-R works or not by specifying -Wl,-R/tmp in the test, but then goes on to set ag_cv_test_ldflags to simply "-Wl,-R" which is then used to set AG_LD_FLAGS. I presume that the same thing occurred when libguile was compiled. Brian Utterback ___ http://lists.gnu.org/mailman/listinfo/libtool
extra copy of manual on www.gnu.org
The GNU website has both the current manual: http://www.gnu.org/software/libtool/manual/libtool.html ...as well as this older version from 1.5.24: http://www.gnu.org/software/libtool/manual.html >From the similarity of the URLs I'm guessing that this is accidental. Unfortunately search engines have an uncanny habit of finding those old copies and putting them near the top of the results, which leads to a lot of confusion if the neglected version evades deletion long enough such that it documents a long-obsolete version. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Sticky --disable-shared
Alessandro Vesely wrote: > Why not? I can build a shared library linking it with a static one. > The static library has to be compiled with -fPIC, of course. It will > then be included in the shared one, without further runtime dependencies. Well of course if you put PIC objects in a static archive you can do that. But that misses the point, because it's not a common thing to do and the vast majority of static libs aren't built that way (and certainly not by libtool.) Moreover, libtool has no way of knowing wheter a random archive that's outside of its control happens to contain PIC objects, so it assumes it doesn't which is correct in the vast majority of cases. Now AFAIK libtool will create archives of PIC objects for convenience libraries. But these are never installed and always under the control of libtool so it doesn't have to guess. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: using .la or .a when linking an executable ?
Vincent Torri wrote: > > No. I wouldn't even know that indirect deps work on w32, or whether > > they help there. > > Ok, i'll wait for a mingw dev to answer. It's irrelevant. The option is accepted but silently ignored, because PE doesn't have anything analogous to the ELF DT_NEEDED tag. If you specify a lib on the link command line but no symbols in it are referenced from the program being linked, it's a no-op, so the problem that this option was invented to solve doesn't exist there. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
tips for checking changes to library version numbers?
Hello, Does anyone have any good ways to check that updates to -version-info numbers accurately reflect the actual changes in the API of a library when making a new release? Currently I do this by (1) comparing 'nm' output against the old library to find any added/deleted functions (2) manually inspecting a diff of the header files (3) looking at the accumulated NEWS/Changelog entries for possible changes in semantics. I am open to suggestions for reducing human error... thanks. -- Brian Gough GNU Scientific Library - http://www.gnu.org/software/gsl/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Getting filenames for libraries
Jason Curl wrote: > >> I can't move over to libtool 2.2.x just yet (most distros I support > >> still have 1.5.26 - sorry) and I'm generating libraries. > >> > > > > FWIW, most distros have a way to use upstream packages without > > re-libtoolizing and re-autoreconfing them. > > > I'm using Ubuntu 8.04, SuSE 11.0, Cygwin 1.5.x. I'm a little afraid of > having both libtool 1.5.x and 2.x installed simultaneously and don't > want to uninstall 1.5.x in fear of breaking things. This newsgroup has > enough reports about mixing releases, especially libtool. I think what Ralf meant was that you said "most distros I support" as if to imply that shipping a tarball generated with 2.2 would also require end-users to have 2.2 installed to build it. But the whole point of the "make dist" tarball is that it's standalone and the user shouldn't need any special developer tools to build it, other than a shell, compiler, and make. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Bug in libtoolize
On Feb 16, 2005, at 9:28 AM, Peter O'Gorman wrote: | Some suggestions for a fix: | | 1. Do the copy as now, but then have a series of "touch" statements to | modify the mtime/ctime all the relevant AM-specific files in the Right | Order so that the timestamps will be proper. | | 2. Copy the files over in order in the first place (i.e., don't use a | glob). | | 3. Tar up the source directory and untar it in the destination. | | Each of the three has benefits and drawbacks -- I guess I'd lean towards | #1. It's probably the least elegant, but it guarantees to get it Right | with the least amount of work. Everyone else seems to be on holiday, so I guess I'll look into it (unless you want to send a patch? :-).) Could libtoolize just use 'cp -f -p' instead of 'cp -f' when copying the files and leave the timestamps as they are in the original libltdl directory? I admit to not understanding all the details, but that was enough to clear up the problem for me (as one would expect - the installed sources of libltdl should be setup correctly...). Seems much easier than any of the other options. Brian -- Brian Barrett Graduate Student, Open Systems Lab, Indiana University http://www.osl.iu.edu/~brbarret/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Multiple "mv" commands?
Hi All, I am working with automake 1.6, autoconf 2.53, libtool 1.4.2, and the SUNWspro 6 update 2 compilers. I am getting some thing a bit weird and I am not sure if I have configured libtool correctly and I am trying to get the auto dependency tracking working. Here is an example of my problem, the "mv" error is the problem: make[2]: Entering directory `/hipo/home/taylor/LOIS/libs/liblois' source='bswap.c' object='bswap.lo' libtool=yes \ depfile='.deps/bswap.Plo' tmpdepfile='.deps/bswap.TPlo' \ depmode=dashXmstdout /bin/ksh ../../depcomp \ /bin/ksh ../../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../../include -g -xCC -v -I/usr/openwin/include -I/usr/local/include -I/hipo/home/taylor/LOIS/include -c -o bswap.lo `test -f bswap.c || echo './'`bswap.c cc -DHAVE_CONFIG_H -I. -I. -I../../include -g -xCC -v -I/usr/openwin/include -I/usr/local/include -I/hipo/home/taylor/LOIS/include -c bswap.c -KPIC -DPIC -o bswap.o mv -f bswap.o bswap.lo mv: cannot rename bswap.o: No such file or directory I found that if I make the following change to libtool: # Just move the object if needed, then go on to compile the next one if test x"$output_obj" != x"$libobj"; then $show "$mv $output_obj $libobj" if test -r $output_obj; then <--- added if $run $mv $output_obj $libobj; then : else error=$? $run $rm $removelist exit $error fi fi fi I can kinda get it to work. But I get this failure mode also mv: cannot rename lsidtm.o: No such file or directory It seems as through the mv command is being executed more than once on a file. Can anybody tell me what I am doing wrong? Thanks in Advance! Brian ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Multiple "mv" commands?
Hi All, Okay... I discovered my problem. The Forte 6 Sun Compilers send the dependency info to stdout. So when the code was compiled for dependencies it would assume that the was an object to remove. To resolve this, I added a flag that in the depcomp file to pass the "--stdoutdepend" to the libtool. This in turn sets a flag to test before a mv. This works pretty well but it still seems to get out of sync every once in a while, I would be very interested in a better solution and one that could be added to the libtool dist and/or automake dist. Or have I missed something completly in the configuration of libtool and/or automake? Thanks to Bruce for pointing me in the right direction.. Cheers, Brian On 2002.04.10 18:43 Bruce Korb wrote: > "Brian W. Taylor" wrote: > > > I found that if I make the following change to libtool: > > > ># Just move the object if needed, then go on to compile the > next > > one > >if test x"$output_obj" != x"$libobj"; then > > $show "$mv $output_obj $libobj" > > if test -r $output_obj; then <--- added > > if $run $mv $output_obj $libobj; then : > > else > > error=$? > > $run $rm $removelist > > exit $error > > fi > > fi > >fi > > > > I can kinda get it to work. But I get this failure mode also > > > > mv: cannot rename lsidtm.o: No such file or directory > > > > It seems as through the mv command is being executed more than once > on a > > file. Can anybody tell me what I am doing wrong? > > Insert a ``set -x'' and ``set +x'' around all the suspect code > and examine the output. > ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
