Thread: [atlas-devel] 3.7.27: dynamic libs at last!
Brought to you by:
rwhaley,
tonyc040457
From: Clint W. <wh...@cs...> - 2007-02-10 19:10:39
|
Guys, I have just released 3.7.27. It's got some better flags for manipulating configure's compiler flags (see configure --help for details), but the big news is I have finally added the ability to build ATLAS into a dynamic library (.so) in addition to the default .a! This support is definitely a prototype. In particular, it is not done automatically, nor are the .so copied during a "make install", etc. You must go to the lib directory and request them to be built after the normal ATLAS install is finished (see INSTALL.txt for details). I have not tested this process anywhere except Linux with the gnu compilers, but I think it should work anywhere with the gnu toolchain. I don't mind extending the functionality of this feature, but only once I'm sure the basics are right. The testing for this is the first time in my life I've built ATLAS to a .so, so I am not sure what people's needs are in this arena. So, it is vital that I hear from you if you are someone who cares about building a .so rather than a .a. Is the present naming scheme OK? Does the current build process provide you with the lib you need? Right now, I'm building ATLAS into essentially one gigantic .so, since that is what I've seen used. Would you rather have the separate libs that ATLAS builds for static archives (or maybe an option for either)? If the present build mechanism satisfies your .so needs, send me an e-mail to that effect as well (to avoid me blowing off something 90% of people want because the only 10% who replied said they didn't like it, and wanted it some other way). I've had quite a few requests for dynamic libs over the years, so please let me know if you needed this feature, and what extensions you'd like (if any) to the present framework. If you test it on a new platform, let me know. I have tested it on a Core2Duo and an Athlon-64. I saw no perceptible loss of performance. You can build most of the testers in bin/ to link to the dynamic libs by simply appending "_dyn" to the tester name (i.e. "make xdlutst_dyn" builds the LU tester and links dynamically rather than statically, as "xdlutst" does). Cheers, Clint |
From: David L. G. <Dav...@no...> - 2007-02-11 04:34:58
|
Hi, Clint, and thanks! I appreciate your need to know how widely this is needed - it must certainly be a lot of hard work. In my case, it'd be useful (if I can figure out how to do it for Windows and Mac platforms), but there's something pretty basic I need to understand first. ATLAS is optimizing w.r.t. both hardware and software platform, correct? If that's the case, would one need to build separate .so's (or .dll's, etc.) for each target chip/OS combination (of which there could be quite a lot), or are we talking "multi-chip" libraries so that the only multiplier is the variety of OS's one's building for? Does this make sense? Thanks! DG Clint Whaley wrote: > Guys, > > I have just released 3.7.27. It's got some better flags for manipulating > configure's compiler flags (see configure --help for details), but the big > news is I have finally added the ability to build ATLAS into a dynamic library > (.so) in addition to the default .a! > > This support is definitely a prototype. In particular, it is not done > automatically, nor are the .so copied during a "make install", etc. You must > go to the lib directory and request them to be built after the normal ATLAS > install is finished (see INSTALL.txt for details). I have not tested this > process anywhere except Linux with the gnu compilers, but I think it should > work anywhere with the gnu toolchain. > > I don't mind extending the functionality of this feature, but only once I'm > sure the basics are right. The testing for this is the first time in my life > I've built ATLAS to a .so, so I am not sure what people's needs are in this > arena. So, it is vital that I hear from you if you are someone who cares about > building a .so rather than a .a. Is the present naming scheme OK? Does the > current build process provide you with the lib you need? Right now, I'm > building ATLAS into essentially one gigantic .so, since that is what I've seen > used. Would you rather have the separate libs that ATLAS builds for static > archives (or maybe an option for either)? > > If the present build mechanism satisfies your .so needs, send me an e-mail to > that effect as well (to avoid me blowing off something 90% of people want > because the only 10% who replied said they didn't like it, and wanted it > some other way). I've had quite a few requests for dynamic libs over the > years, so please let me know if you needed this feature, and what extensions > you'd like (if any) to the present framework. > > If you test it on a new platform, let me know. > > I have tested it on a Core2Duo and an Athlon-64. I saw no perceptible loss > of performance. You can build most of the testers in bin/ to link to the > dynamic libs by simply appending "_dyn" to the tester name (i.e. > "make xdlutst_dyn" builds the LU tester and links dynamically rather than > statically, as "xdlutst" does). > > Cheers, > Clint > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Math-atlas-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/math-atlas-devel > |
From: Albert S. <fu...@gm...> - 2007-02-11 07:14:08
|
Hello all ----- Original Message ----- From: "David L. Goldsmith" <Dav...@no...> To: "List for developer discussion, NOT SUPPORT." <mat...@li...> Sent: Sunday, February 11, 2007 6:23 AM Subject: Re: [atlas-devel] 3.7.27: dynamic libs at last! > Hi, Clint, and thanks! > > I appreciate your need to know how widely this is needed - it must > certainly be a lot of hard work. In my case, it'd be useful (if I can > figure out how to do it for Windows and Mac platforms), but there's > something pretty basic I need to understand first. ATLAS is optimizing > w.r.t. both hardware and software platform, correct? If that's the > case, would one need to build separate .so's (or .dll's, etc.) for each > target chip/OS combination (of which there could be quite a lot), or are > we talking "multi-chip" libraries so that the only multiplier is the > variety of OS's one's building for? Does this make sense? Thanks! I could be wrong, but I think you'll still have to swap in the right version of ATLAS for your particular CPU. At least now you don't have to relink your programs, which is great in an environment with many different types of CPUs. Now that we have ATLAS as a dynamic library, someone (Clint? ;-)) could start looking at loading the right version of ATLAS (from separate .so/DLLs) depending on the CPU, as Intel MKL does. Maybe someone has already coded up something like this? Cheers, Albert > Clint Whaley wrote: >> Guys, >> >> I have just released 3.7.27. It's got some better flags for manipulating >> configure's compiler flags (see configure --help for details), but the >> big >> news is I have finally added the ability to build ATLAS into a dynamic >> library >> (.so) in addition to the default .a! |
From: David C. <da...@ar...> - 2007-02-12 06:10:39
|
Albert Strasheim wrote: > Hello all > > ----- Original Message ----- > From: "David L. Goldsmith" <Dav...@no...> > To: "List for developer discussion, NOT SUPPORT." > <mat...@li...> > Sent: Sunday, February 11, 2007 6:23 AM > Subject: Re: [atlas-devel] 3.7.27: dynamic libs at last! > > >> Hi, Clint, and thanks! >> >> I appreciate your need to know how widely this is needed - it must >> certainly be a lot of hard work. In my case, it'd be useful (if I can >> figure out how to do it for Windows and Mac platforms), but there's >> something pretty basic I need to understand first. ATLAS is optimizing >> w.r.t. both hardware and software platform, correct? If that's the >> case, would one need to build separate .so's (or .dll's, etc.) for each >> target chip/OS combination (of which there could be quite a lot), or are >> we talking "multi-chip" libraries so that the only multiplier is the >> variety of OS's one's building for? Does this make sense? Thanks! > > I could be wrong, but I think you'll still have to swap in the right version > of ATLAS for your particular CPU. At least now you don't have to relink your > programs, which is great in an environment with many different types of > CPUs. > > Now that we have ATLAS as a dynamic library, someone (Clint? ;-)) could > start looking at loading the right version of ATLAS (from separate .so/DLLs) > depending on the CPU, as Intel MKL does. Maybe someone has already coded up > something like this? Hi, I could be wrong too:), but I think this scheme is already there on unix platforms, with the hwcap capability. For example, on ubuntu system, ldconfig -p | grep atlas returns: liblapack_atlas.so.3 (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/liblapack_atlas.so.3 liblapack_atlas.so.3 (libc6) => /usr/lib/liblapack_atlas.so.3 liblapack_atlas.so (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/liblapack_atlas.so liblapack_atlas.so (libc6) => /usr/lib/liblapack_atlas.so liblapack.so.3 (libc6, hwcap: 0x0000000004000000) => /usr/lib/atlas/sse2/liblapack.so.3 liblapack.so.3 (libc6) => /usr/lib/atlas/liblapack.so.3 liblapack.so (libc6, hwcap: 0x0000000004000000) => /usr/lib/atlas/sse2/liblapack.so liblapack.so (libc6) => /usr/lib/atlas/liblapack.so libblas.so.3 (libc6, hwcap: 0x0000000004000000) => /usr/lib/atlas/sse2/libblas.so.3 libblas.so.3 (libc6) => /usr/lib/atlas/libblas.so.3 libblas.so (libc6, hwcap: 0x0000000004000000) => /usr/lib/atlas/sse2/libblas.so libblas.so (libc6) => /usr/lib/atlas/libblas.so libatlas.so.3 (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/libatlas.so.3 libatlas.so.3 (libc6) => /usr/lib/libatlas.so.3 libatlas.so (libc6, hwcap: 0x0000000004000000) => /usr/lib/sse2/libatlas.so libatlas.so (libc6) => /usr/lib/libatlas.so That is there is a generic libatlas.so which works for all x86 platforms, and is linked against, but sse2 library is loaded if available. I don't know how far hwcap can be tweaked (eg I have no idea how the link between hardware capabilities and the hwcap flag is done, if it can be modified, etc...). When I tried to find info about it, I couldn't find anything concrete on google; it seems that it is not debian, nor even linux specific: http://developers.sun.com/solaris/articles/hwcap_modification.html David |
From: Clint W. <wh...@cs...> - 2007-02-11 15:46:51
|
Guys, >I appreciate your need to know how widely this is needed - it must >certainly be a lot of hard work. In my case, it'd be useful (if I can >figure out how to do it for Windows and Mac platforms), but there's >something pretty basic I need to understand first. ATLAS is optimizing >w.r.t. both hardware and software platform, correct? If that's the >case, would one need to build separate .so's (or .dll's, etc.) for each >target chip/OS combination (of which there could be quite a lot), or are >we talking "multi-chip" libraries so that the only multiplier is the >variety of OS's one's building for? Does this make sense? Thanks! ATLAS shouldn't change too much based on OS if it is the same hardware, though it *could* make some changes around the edges (eg., due to different sized pages, or cleaner/dirtier context switches causing less/more L2 cache pollution and changing CacheEdge, etc). ATLAS is still dedicated to specializing for the platform; I just added the ability to build to a dynamic lib rather than always to a static library. I have not added generalizers so that one lib can work on a host of machines. Obviously, generality and performance are antagonistic, so I'd rather encourage people to recompile a few times :) I think Camm (Debian maintainer) does the kind of thing you are talking about, where he makes a general lib, and uses some LD_PATH or something similar to get greater specificity and performance . . . >Now that we have ATLAS as a dynamic library, someone (Clint? ;-)) could >start looking at loading the right version of ATLAS (from separate .so/DLLs) >depending on the CPU, as Intel MKL does. Maybe someone has already coded up >something like this? I think Camm does something like this, and the Redhat packager may be doing something similar? They'll have to explain it: I don't know the details. Cheers, Clint |
From: <ediap@ET.PUT.Poznan.PL> - 2007-02-12 13:34:49
Attachments:
signature.asc
|
* Clint Whaley [2007-02-10 19:44]: [...] > I don't mind extending the functionality of this feature, but only once= I'm > sure the basics are right. The testing for this is the first time in m= y life > I've built ATLAS to a .so, so I am not sure what people's needs are in = this > arena. So, it is vital that I hear from you if you are someone who car= es about > building a .so rather than a .a. Is the present naming scheme OK? Doe= s the > current build process provide you with the lib you need? Right now, I'= m > building ATLAS into essentially one gigantic .so, since that is what I'= ve seen > used. Would you rather have the separate libs that ATLAS builds for st= atic > archives (or maybe an option for either)? >=20 > If the present build mechanism satisfies your .so needs, send me an e-m= ail to > that effect as well (to avoid me blowing off something 90% of people wa= nt > because the only 10% who replied said they didn't like it, and wanted i= t > some other way). I've had quite a few requests for dynamic libs over t= he > years, so please let me know if you needed this feature, and what exten= sions > you'd like (if any) to the present framework. Hi Clint! Thanks for taking care of supporting the shared libraries out o= f the box by ATLAS! I have successfully built the shared libatlas.so object= on my Linux x86 box from release 3.7.28. Anyway, my two-cents regarding your questions: 1) I would prefer to have separate shared libs for each of the static (*.a) library, i.e. libatlas.so, libcblas.so, libf77blas.so and liblapack.so. This will help other autoconf-based project to detect ATLAS= using the same macros as the ones designed for static ATLAS libraries... 2) It would be great if your configure script can support --enable-shared= (--disable-shared) and --enable-static (--disable-static) switches to tur= n on/off the building process of shared/static libraries. This is a "de facto" standard in projects, which use autoconf. For instance, adding "--enable-shared" to the configure script would add proper flags (-fPIC) to C/Fortran flags and would create *.so object automatically. 3) Provided that you consider adding feature 2) to ATLAS configuration, the installation target (make install) should install the selected static= or shared, or even both, libraries into the installation directory. Best regards, /Adam --=20 -=3D#=3D- Adam Pi=C4=85tyszek - "ediap" -=3D#=3D- JID: ediap (at) jabb= er.org -=3D#=3D- -=3D#=3D- ediap (at) users.sf.net -=3D#=3D- PGP key ID: 0x83EFCBAA = -=3D#=3D- |
From: Markus D. <mar...@ge...> - 2007-02-12 14:08:16
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 12 Feb 2007, Adam Pityszek wrote: > 1) I would prefer to have separate shared libs for each of the static > (*.a) library, i.e. libatlas.so, libcblas.so, libf77blas.so and > liblapack.so. This will help other autoconf-based project to detect ATLAS > using the same macros as the ones designed for static ATLAS libraries... > > 2) It would be great if your configure script can support --enable-shared > (--disable-shared) and --enable-static (--disable-static) switches to turn > on/off the building process of shared/static libraries. This is a "de > facto" standard in projects, which use autoconf. For instance, adding > "--enable-shared" to the configure script would add proper flags (-fPIC) > to C/Fortran flags and would create *.so object automatically. > > 3) Provided that you consider adding feature 2) to ATLAS configuration, > the installation target (make install) should install the selected static > or shared, or even both, libraries into the installation directory. > > Best regards, > /Adam > Dear Clint, Many thanks for your efforts to support shared atlas libraries. This is great! I was just about to write an email very similar to Adam's and can only second all three of his points. Thanks, Markus - -- Markus Dittrich (markusle) Gentoo Linux Developer Scientific applications -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF0HTAxlRwCwb7k40RArPeAJ42CB52MSiX05q2uCIENO7tu1ZgmgCfWZOW HkW7Wf4RrF40mBwTUrI76Mo= =Val8 -----END PGP SIGNATURE----- |
From: <ediap@ET.PUT.Poznan.PL> - 2007-02-12 14:25:39
Attachments:
signature.asc
|
>> 2) It would be great if your configure script can support --enable-sha= red >> (--disable-shared) and --enable-static (--disable-static) switches to = turn >> on/off the building process of shared/static libraries. This is a "de >> facto" standard in projects, which use autoconf. For instance, adding >> "--enable-shared" to the configure script would add proper flags (-fPI= C) >> to C/Fortran flags and would create *.so object automatically. >=20 >> 3) Provided that you consider adding feature 2) to ATLAS configuration= , >> the installation target (make install) should install the selected sta= tic >> or shared, or even both, libraries into the installation directory. Hi again ;-) I know that providing a portable solution of 2) and 3) might be difficult= without any special tools. So, I recommend you to have a look at the libtool package, which should solve the portability problems on various platforms and compilers. Here is nice description what libtool provides from the library building point of view: http://sources.redhat.com/autobook/autobook/autobook_68.html#SEC68 BR, /Adam --=20 -=3D#=3D- Adam Pi=C4=85tyszek - "ediap" -=3D#=3D- JID: ediap (at) jabb= er.org -=3D#=3D- -=3D#=3D- ediap (at) users.sf.net -=3D#=3D- PGP key ID: 0x83EFCBAA = -=3D#=3D- |
From: Clint W. <wh...@cs...> - 2007-02-12 16:55:47
|
Adam, >I know that providing a portable solution of 2) and 3) might be difficult >without any special tools. So, I recommend you to have a look at the >libtool package, which should solve the portability problems on various >platforms and compilers. Here is nice description what libtool provides >from the library building point of view: >http://sources.redhat.com/autobook/autobook/autobook_68.html#SEC68 Yeah, I scoped libtool before doing things this way. That was about the third time I'd scoped libtool. From what I can tell, they want me to use libtool for everything: all compilation with all compilers, etc. This is not an option with ATLAS, where the ability to control the flags in microscopic detail is essential. I need a process where I can build normally, and then convert to .so at the end, as the current practice does. As far as I can determine, libtool does not allow this. Perhaps you know better? Thanks, Clint |
From: Clint W. <wh...@cs...> - 2007-02-12 17:17:53
|
Guys, >Hi Clint! Thanks for taking care of supporting the shared libraries out of >the box by ATLAS! I have successfully built the shared libatlas.so object >on my Linux x86 box from release 3.7.28. Anyway, my two-cents regarding >your questions: > >1) I would prefer to have separate shared libs for each of the static >(*.a) library, i.e. libatlas.so, libcblas.so, libf77blas.so and >liblapack.so. This will help other autoconf-based project to detect ATLAS >using the same macros as the ones designed for static ATLAS libraries... OK, I like the separate names myself, so I'll at least add this as another target. Does anyone prefer the "one big fat file" approach (i.e. should it be retained)? >2) It would be great if your configure script can support --enable-shared >(--disable-shared) and --enable-static (--disable-static) switches to turn >on/off the building process of shared/static libraries. This is a "de >facto" standard in projects, which use autoconf. For instance, adding >"--enable-shared" to the configure script would add proper flags (-fPIC) >to C/Fortran flags and would create *.so object automatically. > >3) Provided that you consider adding feature 2) to ATLAS configuration, >the installation target (make install) should install the selected static >or shared, or even both, libraries into the installation directory. I'm thinking of adding these eventually, but I'd like to get some experience with shared libs before supporting it at this level. The idea is to avoid my having to rewrite higher level install things everytime we change our minds on how to build the shared libs . . . Thanks, Clint |
From: <ediap@ET.PUT.Poznan.PL> - 2007-02-13 08:44:34
Attachments:
signature.asc
|
* Clint Whaley [2007-02-12 17:55]: > Yeah, I scoped libtool before doing things this way. That was about th= e > third time I'd scoped libtool. From what I can tell, they want me to u= se > libtool for everything: all compilation with all compilers, etc. This = is > not an option with ATLAS, where the ability to control the flags in > microscopic detail is essential. I need a process where I can build > normally, and then convert to .so at the end, as the current practice d= oes. > As far as I can determine, libtool does not allow this. Perhaps you kn= ow > better? In my opinion it is not a problem at all. Libtool is only a wrapper for the standard compilation method... Except adding or not adding the required PIC flags is does not change anything else in the compilation command. You still need to pass the correct compiler command and flags to= it. Here is an example compilation and linking of a "test.c" file with some explicit compiler flags added. As you can see, in the first step (--mode=3Dcompile), libtool produces two object files - a standard one an= d a position independed in .libs/ subdirectory. All user defined flags are preserved: ediap@lespaul c_cpp % libtool --mode=3Dcompile gcc -fomit-frame-pointer -= O3 -mfpmath=3D387 -m32 -c test.c gcc -fomit-frame-pointer -O3 -mfpmath=3D387 -m32 -c test.c -fPIC -DPIC = -o =2Elibs/test.o gcc -fomit-frame-pointer -O3 -mfpmath=3D387 -m32 -c test.c -o test.o >/dev/null 2>&1 And here an example library linking step is done. You have to only define= the target running path, where the library will be installed and pass *.l= o instead of standard *.o objects for the linking process: ediap@lespaul c_cpp % libtool --mode=3Dlink gcc -rpath /usr/local/lib -o libtest.la test.lo rm -fr .libs/libtest.a .libs/libtest.la .libs/libtest.lai =2Elibs/libtest.so .libs/libtest.so.0 .libs/libtest.so.0.0.0 i686-pc-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/crtbeginS.o .libs/test.o -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1 -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/crtendS.o /usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../crtn.o -Wl,-soname -Wl,libtest.so.0 -o .libs/libtest.so.0.0.0 (cd .libs && rm -f libtest.so.0 && ln -s libtest.so.0.0.0 libtest.so.0) (cd .libs && rm -f libtest.so && ln -s libtest.so.0.0.0 libtest.so) i686-pc-linux-gnu-ar cru .libs/libtest.a test.o i686-pc-linux-gnu-ranlib .libs/libtest.a creating libtest.la (cd .libs && rm -f libtest.la && ln -s ../libtest.la libtest.la) ediap@lespaul c_cpp % BTW, that is how the Gentoo patches are created for your Makefiles. All flags and hand settings are preserved... We only replace standard "gcc =2E.." and "ar ..." commands with their wrapped versions "libtool --mode=3Dcompile gcc ..." and "libtool --mode=3Dlink gcc ..." Hope this clarifies a bit the issue... BR, /Adam --=20 -=3D#=3D- Adam Pi=C4=85tyszek - "ediap" -=3D#=3D- JID: ediap (at) jabb= er.org -=3D#=3D- -=3D#=3D- ediap (at) users.sf.net -=3D#=3D- PGP key ID: 0x83EFCBAA = -=3D#=3D- |
From: Clint W. <wh...@cs...> - 2007-02-15 08:37:24
|
Adam, >In my opinion it is not a problem at all. Libtool is only a wrapper for >the standard compilation method... Except adding or not adding the >required PIC flags is does not change anything else in the compilation >command. You still need to pass the correct compiler command and flags to it. Yeah, I've heard these claims before. MPICH did the same thing, use mpicc to compile everything! Then you find it doesn't take certain flags, adds some you don't want, and/or won't work with compiler X . . . >Here is an example compilation and linking of a "test.c" file with some >explicit compiler flags added. As you can see, in the first step >(--mode=compile), libtool produces two object files - a standard one and a >position independed in .libs/ subdirectory. All user defined flags are >preserved: > >ediap@lespaul c_cpp % libtool --mode=compile gcc -fomit-frame-pointer -O3 >-mfpmath=387 -m32 -c test.c > gcc -fomit-frame-pointer -O3 -mfpmath=387 -m32 -c test.c -fPIC -DPIC -o >.libs/test.o > gcc -fomit-frame-pointer -O3 -mfpmath=387 -m32 -c test.c -o test.o >>/dev/null 2>&1 OK, so in this mode, the value-added from using libtool is: (1) It knows the right command-line flag for PIC code for various compilers. Does it automagically know IBM xlc, Sun cc, SGI cc and Intel icc? (2) It builds two copies of all object files, one dynamic and one static Is that right? Does libtool create the .libs directory automatically? >And here an example library linking step is done. You have to only define >the target running path, where the library will be installed and pass *.lo >instead of standard *.o objects for the linking process: > >ediap@lespaul c_cpp % libtool --mode=link gcc -rpath /usr/local/lib -o >libtest.la test.lo >rm -fr .libs/libtest.a .libs/libtest.la .libs/libtest.lai >.libs/libtest.so .libs/libtest.so.0 .libs/libtest.so.0.0.0 >i686-pc-linux-gnu-g++ -shared -nostdlib >/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../crti.o >/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/crtbeginS.o .libs/test.o >-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1 >-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/lib >-L/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../.. -lstdc++ -lm -lc -lgcc_s >/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/crtendS.o >/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../crtn.o -Wl,-soname >-Wl,libtest.so.0 -o .libs/libtest.so.0.0.0 >(cd .libs && rm -f libtest.so.0 && ln -s libtest.so.0.0.0 libtest.so.0) >(cd .libs && rm -f libtest.so && ln -s libtest.so.0.0.0 libtest.so) >i686-pc-linux-gnu-ar cru .libs/libtest.a test.o >i686-pc-linux-gnu-ranlib .libs/libtest.a >creating libtest.la >(cd .libs && rm -f libtest.la && ln -s ../libtest.la libtest.la) >ediap@lespaul c_cpp % In this mode, the value added is I don't have to find all the dependent libs myself (as well as creating both static and dynamic)? >BTW, that is how the Gentoo patches are created for your Makefiles. All >flags and hand settings are preserved... We only replace standard "gcc >..." and "ar ..." commands with their wrapped versions "libtool >--mode=compile gcc ..." and "libtool --mode=link gcc ..." I'm guessing this would have a problem on any non-gcc comps in the index case files, unless you grep/replace those files as well? It's a bit easier when you have a known platform, however. I can't count on having Linux, or libtool, or even gcc . . . Thanks, Clint |