Re: Linking convenience libraries
On Thu, Mar 03, 2005 at 09:39:36PM -0600, Albert Chin wrote: > On Thu, Mar 03, 2005 at 12:01:26PM -0600, Bob Friesenhahn wrote: > > On Thu, 3 Mar 2005, Albert Chin wrote: > > > > >When using the compiler to perform the link and linking against > > >convenience libraries, is there any reason to link explicitly against > > >the extracted objects of the convenience libraries rather than just > > >the .a file? I'm running into a problem on IRIX with the SGI C++ > > >compiler that is solved if I link the .a files. I see no reason why we > > >extract the convenience libraries libraries when linking against the > > >compiler v. the linker. > > > > If we link against the .a file directly then the only objects which > > will get pulled in are the ones required to link (resolve symbols). > > This means that much of the library may be missing. > > > > If we are building an application it is desirable to shed unnecessary > > objects but it is not desirable to do that for libraries. > > What if we use $whole_archive_flag_spec? > > Are the following equivalent on Linux? > 1. ld -soname libfoo.so 1.o 2.o 3.o [all .o's from lib1.a] \ > [all .o's from lib2.a] > 2. ld -soname libfoo.so 1.o 2.o 3.o \ > --whole-archive lib1.a lib2.a -no-whole-archive > > If so, then we should be able to use $whole_archive_flag_spec in lieu > of extracting everything. Sorry, this is already used when creating shared libraries. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking convenience libraries
On Thu, Mar 03, 2005 at 12:01:26PM -0600, Bob Friesenhahn wrote: > On Thu, 3 Mar 2005, Albert Chin wrote: > > >When using the compiler to perform the link and linking against > >convenience libraries, is there any reason to link explicitly against > >the extracted objects of the convenience libraries rather than just > >the .a file? I'm running into a problem on IRIX with the SGI C++ > >compiler that is solved if I link the .a files. I see no reason why we > >extract the convenience libraries libraries when linking against the > >compiler v. the linker. > > If we link against the .a file directly then the only objects which > will get pulled in are the ones required to link (resolve symbols). > This means that much of the library may be missing. > > If we are building an application it is desirable to shed unnecessary > objects but it is not desirable to do that for libraries. What if we use $whole_archive_flag_spec? Are the following equivalent on Linux? 1. ld -soname libfoo.so 1.o 2.o 3.o [all .o's from lib1.a] \ [all .o's from lib2.a] 2. ld -soname libfoo.so 1.o 2.o 3.o \ --whole-archive lib1.a lib2.a -no-whole-archive If so, then we should be able to use $whole_archive_flag_spec in lieu of extracting everything. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -no_prelink and CC -ar on IRIX
On Fri, Mar 04, 2005 at 10:19:02AM +0900, Peter O'Gorman wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Albert Chin wrote: > | On Thu, Mar 03, 2005 at 01:23:44PM -0600, Albert Chin wrote: > | > | Ok, this sucks. -no_prelink causes other problems. The SGI compiler > | leaves template droppings in the ii_files directory that *must* be > | copied when we extract the convenience library. Ugh. > | > > At the end of func_extract_archives it does a find: > > my_oldobjs="$my_oldobjs "`find $my_xdir -name \*.$objext -print -o -name > \*.lo -print | $NL2SP` > > Does adding -o -name \*.ii to the list help at all? That won't help. After you copy over the .ii files, you must modify them. I have a solution but I'm running into another problem I need to solve. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
$B!~"!Lk$N>pJsJg=8!~"!(B
$B!!!z(B.$B!'!&(B*.$B!&!%(B:$B!y(B.$B!'!&(B*.$B!&!%(B:$B!z(B.$B!'!&(B*.$B!&!%(B:$B!y(B.$B!'!&(B*.$B!&!%(B:$B!z(B.$B!'!&(B*.$B!&!%!y(B.$B!'!&(B
$B(B $B!D!E!&(B
$B(6(6!!Lk$N>pJsJg=8$N3'MM$X(6(6!&!E!D(B
$B!!":";":";":!!"!!~:#G/:G6/$N0|Mp>pJs!*!*!~"!!!";":";":";":";":";":";":";":";(B
$B!!(!(B[PR]$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
$B!!([EMAIL PROTECTED](/(B
*$B!y0|Mp;I7cITB-$NJ}$X6[5^9pCN!*!Z%(%mG>GH![$G$9$Y$F$,JQ$o$k!z(B*
$B!!(-;I7c(-(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B
$B!!(1(,(,(0!~Hh$l$F$$$k$+$i#H$J5$J,$K$J$l$J$$!*(B
$B!!!~#H$J5$J,$rM^$($F$$$^$;$s$+!)$=$l$,%9%H%l%9$K$J$C$F$7$^$&!&!&(B
$B!!!~?7A/$G;I7c$NM-$k%5%$%H$K=P2q$($J$$!JIT0B$bM-$k!K(B
$B$7$+$7!"860x$,J,$+$l$PLdBj2r7h!*(B
$B!!!J0|Mp4IM}?M!&H~F`;R!&$,%5%]!<%H$7$^$9!#5.J}$b0B?4$h!*!K(B
$B"-2a7c$K;I7c$?$C$W$j$NHk7m$O$3$A$i"-(B
$B!!:#$9$0%/%j%C%/"M(B
http://casio.isa-geek.com/aaa/index.php?code=bGlidG9vbEBnbnUub3Jn
$B(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(!(B[PR]$B(!(B
$B"("("("("("("("("("("("("("("("("("("("("("("("("("("("("("("("("("("((B
$B"(=EJ#!"[EMAIL PROTECTED]|A4$r4|$7$F$*$j$^$9$,l9g$O!"?<$/$*OM$S?=$7>e$2$^$9!#(B
$B!!!J$4ITMW$NJ}$O$3$N$^$^%a!<%kJV?.$7$F9XFI2r=|$N$K$D$-4|4V1dD9Cf!*!yAG?M$N7j!yBgGz?JCf(B*
$B('()(B
$B!!('()!!F|[EMAIL
PROTECTED],$*9%$-!)?7CeEj9F$,KhF|FO$/!*!*!!(B $B('()(B
$B!!('()!!(B
$B('()(B
$B!!('()!!I,8+$N7j"M!!(Bhttp://casio.isa-geek.com/aaa/index.php?code=bGlidG9vbEBnbnUub3Jn$B!!(B
$B('()(B
$B!!('()(B
$B('()(B
$B!!('(+(+()(B
$B!!(&(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(*(%(B
$B(B =PR=$B!z!!!z(B $B!z!!(B $B!z!!(B
$B!z(B $B!z!!(B $B!z(B
$B(B $B!y!y!!(B $B!y!!(B $B!y!!(B
$B!y!!(B $B!y(B $B!y(B
$B(B $B!!(B $B!z!!(B
$B!z!!!z!!!z!!!z!!!z!z(B
$B!!(.(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(/(B
$B!!(.(,(4(B $B!!!z!!%;%l%V!&$*>nMM8BDj$N%(%m2hA|!!!z(B
$B!!(2(,(/(B
$B!!(-!!(1(3(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(3(0!!(-(B
$B!!(1(,(,(0(1(,(,(0(B
$B!!"'!!$/(-$o(-$7(-$/(-$O(-%3(-%A(-%i(-!*(-!!"'(B
$B!!(,(0(,(0(,(0(,(0(,(0(,(0(,(0(,(0(,(0(B
$B!D!d(B
http://casio.isa-geek.com/aaa/index.php?code=bGlidG9vbEBnbnUub3Jn $B!c!D(B
$B(B $B!!!D!D!D!D!D!D!D!D!D!D!D!D!D(B
$B(B
$B!y!y!!(B $B!y!!(B $B!y!!(B
$B!y!!(B $B!y(B $B!y(B
$B!!K\%a!<%k%^%,%8%s7G:\$K4X$9$k>[EMAIL PROTECTED]@UG$$rIi$$$^$;$s!#(B
$B!!7G:\>pJs$NMxMQ$K:]$7$F$O!"3F?M$,<+J,[EMAIL PROTECTED]<$5$$!#(B
$B!!$$$+$J$kB;[EMAIL PROTECTED]@UG$$rIi$$$+$M$^$9$N$G$4N;>52<$5$$!#(B
$B!!>pJs$OI,$:$4<+J,$G$43NG'$/[EMAIL PROTECTED](B
$B!!7G:\$5$l$?5-;v$N0lIt$^$?$OA4It$r5v2D$J$/E>:\$9$k$3$H$r6X;_CW$7$^$9!#(B
$B!!(B
$B!!!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z!z(B
$B!Z2r=|$K$D$$$F![(B
$B!!(B
$B!!"(!!9XFI2r=|J}K!(B
$BK|$,0l(B18$B:PL$K~$NJ}$KFO$$$?>l9g$d!"(B
$B(B $BEPO?2r=|$r$44uK>$NJ}$O$*http://lists.gnu.org/mailman/listinfo/libtool
Re: -no_prelink and CC -ar on IRIX
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Albert Chin wrote: | On Thu, Mar 03, 2005 at 01:23:44PM -0600, Albert Chin wrote: | | Ok, this sucks. -no_prelink causes other problems. The SGI compiler | leaves template droppings in the ii_files directory that *must* be | copied when we extract the convenience library. Ugh. | At the end of func_extract_archives it does a find: my_oldobjs="$my_oldobjs "`find $my_xdir -name \*.$objext -print -o -name \*.lo -print | $NL2SP` Does adding -o -name \*.ii to the list help at all? Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (Darwin) iQCVAwUBQie3hbiDAg3OZTLPAQJVUgP+IReeCYyGBwx6z24PujjNCIKiasCxeYJV ai4tQ1wy6ELXk59w+Mig5IMRT0fy/0WxFBFEoL7Y8WUdO4u81UM+iwxAjuKUdXUd 19pCHoQsPJZsDY5G0uOiTB7xRqQUt2F+PvSu3NYbdqIC1EBCWYHfDlegaZXr8UyY Qu5re7ePLTA= =dKa5 -END PGP SIGNATURE- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -no_prelink and CC -ar on IRIX
On Thu, Mar 03, 2005 at 01:23:44PM -0600, Albert Chin wrote: > Will bad things happen if -no_prelink is used in combination with CC > -ar? When GNU libtool creates an archive library which is comprised of > objects from other libtool archive libraries (convenience libraries), > it extracts the object files from the convenience libraries and adds > them to the archive library being created. When this is done, the .ii > files from the archive libraries being added are lost because the > object files are extracted to a temporary directory. So, C++ > prelinking might fail. > > It seems the easiest solution is adding -no_prelink to CC -ar. > > I'm trying to find a solution to a build problem with kdepim-3.3.2 on > IRIX using the SGI C++ compiler: > ... > /bin/sh ../libtool --mode=link --tag=CXX CC ... > rm -fr .libs/knotes_local.lax > mkdir .libs/knotes_local.lax > rm -fr .libs/knotes_local.lax/libknotesresources.a > mkdir .libs/knotes_local.lax/libknotesresources.a > (cd .libs/knotes_local.lax/libknotesresources.a && ar x > /opt/build/kdepim-3.3.2/knotes/./.libs/libknotesresources.a) > rm -fr .libs/knotes_local.lax/libknotesconfig.a > mkdir .libs/knotes_local.lax/libknotesconfig.a > (cd .libs/knotes_local.lax/libknotesconfig.a && ar x > /opt/build/kdepim-3.3.2/knotes/./.libs/libknotesconfig.a) > CC -ar -WR,-u -o .libs/knotes_local.a resourcelocal_plugin.o > .libs/knotes_local.lax/libknotesresources.a/resourcemanager.o > .libs/knotes_local.lax/libknotesresources.a/resourcenotes.o > .libs/knotes_local.lax/libknotesresources.a/resourcelocal.o > .libs/knotes_local.lax/libknotesconfig.a/knoteconfig.o > .libs/knotes_local.lax/libknotesconfig.a/knotesglobalconfig.o > C++ prelinker: error: file > ".libs/knotes_local.lax/libknotesconfig.a/ii_files/knoteconfig.ii" is > read-only Ok, this sucks. -no_prelink causes other problems. The SGI compiler leaves template droppings in the ii_files directory that *must* be copied when we extract the convenience library. Ugh. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
-no_prelink and CC -ar on IRIX
Will bad things happen if -no_prelink is used in combination with CC -ar? When GNU libtool creates an archive library which is comprised of objects from other libtool archive libraries (convenience libraries), it extracts the object files from the convenience libraries and adds them to the archive library being created. When this is done, the .ii files from the archive libraries being added are lost because the object files are extracted to a temporary directory. So, C++ prelinking might fail. It seems the easiest solution is adding -no_prelink to CC -ar. I'm trying to find a solution to a build problem with kdepim-3.3.2 on IRIX using the SGI C++ compiler: ... /bin/sh ../libtool --mode=link --tag=CXX CC ... rm -fr .libs/knotes_local.lax mkdir .libs/knotes_local.lax rm -fr .libs/knotes_local.lax/libknotesresources.a mkdir .libs/knotes_local.lax/libknotesresources.a (cd .libs/knotes_local.lax/libknotesresources.a && ar x /opt/build/kdepim-3.3.2/knotes/./.libs/libknotesresources.a) rm -fr .libs/knotes_local.lax/libknotesconfig.a mkdir .libs/knotes_local.lax/libknotesconfig.a (cd .libs/knotes_local.lax/libknotesconfig.a && ar x /opt/build/kdepim-3.3.2/knotes/./.libs/libknotesconfig.a) CC -ar -WR,-u -o .libs/knotes_local.a resourcelocal_plugin.o .libs/knotes_local.lax/libknotesresources.a/resourcemanager.o .libs/knotes_local.lax/libknotesresources.a/resourcenotes.o .libs/knotes_local.lax/libknotesresources.a/resourcelocal.o .libs/knotes_local.lax/libknotesconfig.a/knoteconfig.o .libs/knotes_local.lax/libknotesconfig.a/knotesglobalconfig.o C++ prelinker: error: file ".libs/knotes_local.lax/libknotesconfig.a/ii_files/knoteconfig.ii" is read-only -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking convenience libraries
On Thu, Mar 03, 2005 at 11:41:00AM -0600, Albert Chin wrote: > When using the compiler to perform the link and linking against > convenience libraries, is there any reason to link explicitly against > the extracted objects of the convenience libraries rather than just > the .a file? I'm running into a problem on IRIX with the SGI C++ > compiler that is solved if I link the .a files. I see no reason why we > extract the convenience libraries libraries when linking against the > compiler v. the linker. Ok, my mistakes. $whole_archive_flag_spec works around this. But, only when creating shared objects. Any portability problems with .a files in static archives? -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Linking convenience libraries
On Thu, 3 Mar 2005, Albert Chin wrote: When using the compiler to perform the link and linking against convenience libraries, is there any reason to link explicitly against the extracted objects of the convenience libraries rather than just the .a file? I'm running into a problem on IRIX with the SGI C++ compiler that is solved if I link the .a files. I see no reason why we extract the convenience libraries libraries when linking against the compiler v. the linker. If we link against the .a file directly then the only objects which will get pulled in are the ones required to link (resolve symbols). This means that much of the library may be missing. If we are building an application it is desirable to shed unnecessary objects but it is not desirable to do that for libraries. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Linking convenience libraries
When using the compiler to perform the link and linking against convenience libraries, is there any reason to link explicitly against the extracted objects of the convenience libraries rather than just the .a file? I'm running into a problem on IRIX with the SGI C++ compiler that is solved if I link the .a files. I see no reason why we extract the convenience libraries libraries when linking against the compiler v. the linker. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: third party libaries
On Thu, 3 Mar 2005, Johannes Drever wrote: On Thu, 3 Mar 2005, Bob Friesenhahn wrote: If you are using Automake, you should express library dependencies via an LDADD statement (can be on a per-library level). If the libraries are in the local build tree, the listed dependency should be the absolute or relative path to the library's uninstalled .la file. If the libraries are already installed, then use -llib syntax. Automake will pass LDADD options to libtool "as is" I didn't want to make an application for each sublibrary. (i think LDADD is for linking executabels?) I use LDADD for both libraries and executables. As the libraries i want to use are already installed i should use the -llib syntax, but where? i already passed the flags via AM_CPPFLAGS=... but is it the right way? and how can i define one path to link at and une the location in the makefile.am's ( or can i make autoconf search the path ?) CPPFLAGS defines where to look for header files, not libraries. You will need both. There is also LIBS, which specifies a list of libraries to supply for all applications. This is the common way to pass a list of libraries from autoconf to the Makefile. You are not limited to using LIBS since you can add your own substitution variables, which supply additional options via a library-specific LDADD statement. Use LDFLAGS to pass linker search path options from configure to the Makefile. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: third party libaries
On Thu, 3 Mar 2005, Bob Friesenhahn wrote: If you are using Automake, you should express library dependencies via an LDADD statement (can be on a per-library level). If the libraries are in the local build tree, the listed dependency should be the absolute or relative path to the library's uninstalled .la file. If the libraries are already installed, then use -llib syntax. Automake will pass LDADD options to libtool "as is" I didn't want to make an application for each sublibrary. (i think LDADD is for linking executabels?) As the libraries i want to use are already installed i should use the -llib syntax, but where? i already passed the flags via AM_CPPFLAGS=... but is it the right way? and how can i define one path to link at and une the location in the makefile.am's ( or can i make autoconf search the path ?) Thank you very much, Johannes ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: third party libaries
On Thu, 3 Mar 2005, Johannes Drever wrote: Hello everyone! what is the best way to add the dependency on third party libaries to my project? The project has many "subproject" which i want to able to build seperately, and each "subproject" depends on other third party libraries. i am totaly unsure where to put the dependencies, so i would be glad to have some advice, or example, or a good tutorial to look at. If you are using Automake, you should express library dependencies via an LDADD statement (can be on a per-library level). If the libraries are in the local build tree, the listed dependency should be the absolute or relative path to the library's uninstalled .la file. If the libraries are already installed, then use -llib syntax. Automake will pass LDADD options to libtool "as is". Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
third party libaries
Hello everyone! what is the best way to add the dependency on third party libaries to my project? The project has many "subproject" which i want to able to build seperately, and each "subproject" depends on other third party libraries. i am totaly unsure where to put the dependencies, so i would be glad to have some advice, or example, or a good tutorial to look at. Thanks, Johannes ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Mediccations-KXL
Hello, Visit Our PharmMail SH0P. SP OF Vi ra $200(120p.) Ci is $300(150p.) Lev ra $300(50p.) ECIAL FER: ag al it And Many Other! With each purchase you get: 20%Off All Re-0rders with us Home delivery Total confidentiality FDAApproved Highest Quality Have a nice day. ___ http://lists.gnu.org/mailman/listinfo/libtool
