--silent Bug
Hi, libtool --silent doesn't omit the "if you ever happen to..." text at the end of a make install any more. VERSION=1.4a TIMESTAMP=" (1.641.2.28 2000/05/14 09:08:17)" Dirk
Two questions on library handling
Dear library experts, I'm using libtool for my PDFlib package for quite some time now, and am very happy with what it's able to achieve. However, I am unable to solve the following two problems (which may be combined configure/libtool problems): - How to distinguish shared and static libraries in configure? AC_SEARCH_LIBS and related macros work just fine, but I need to know whether the searched-for library is available as a shared object (since I cannot link in a static one to my own final shared library). - How to deal with library dependencies which exist on some platforms, but not on others? For example, when searching for TIFFlib one has to supply the jpeg and zlib libraries sometimes. Since some platforms insist on finding all libs supplied to the ld command, it's not safe to supply all dependent libraries always. On the other hand, if I first check for the "raw" library in configure (without additional libraries supplied) and this test fails, and then _with_ additional libraries, configure seems to take the previously cached result (failure) for the library in question, even if it would be available with the dependent libs supplied. Since I like to prepare the libtool command lines as precise as possible (with exactly the required libs) I'd be happy to hear any advice on the above issues. To give you some background, the current stacking of libraries is as follows (PDFlib can be used from Perl and other languages): Perl extension library ==> libpdf ==> libtiff ==> libjpeg (possibly, but not always) ==> libz (possibly, but not always) ==> libz ==> libpng ==> libz ==> libm The availability of the TIFF, libz, and libpng libraries is determined by configure, and both the Perl extension and the actual libpdf are built by libtool. If libtiff is only available as static lib I run into trouble since the Perl extension is always shared here. Thomas ___ Thomas Merz [EMAIL PROTECTED]http://www.pdflib.com Visit the PDF 2000 conference: http://www.pdfconference.com ___PDFlib - a library for generating PDF on the fly
Re: ltcf-cxx.sh
Hi, On Mon, 22 May 2000, Ossama Othman wrote: > On Sun, May 21, 2000 at 07:53:39PM +0200, Stephan Kulow wrote: > > Michael Matz and I plan to switch our libtool version to > > the one in multi-language-branch in two days so it gets > > some testing before we release KDE 2.0 with it. > > Great! KDE would be a great smoke test for the multi-language branch > libtool. It's smoking already ;) Even with problem reports ;) On Wed, 24 May 2000, Ossama Othman wrote: > I'll try to move the general g++ configurations outside of the > platform-specific configurations soon. Great. Note that it's all not only depending on the compiler, but also on the actual linker used, so $with_gnu_ld should also be tested. E.g. just today I had a report from someone using KDE on Solaris with gcc and GNU ld. Currently that won't work, because on Solaris ltcf-cxx.sh thinks its using the native linker. (for -export-symbols it tries to give -M bla.exp to the linker). I guess, the easiest solution would be, to structure ltcf-cxx.sh like: if test $with_gcc = yes && test $with_gnu_ld = yes ; then # do useful things, mostly independent from the OS # note, that mostly (if $with_gnu_ld --> also $with_gcc) else if test $with_gcc = yes ; then # do stuff where we at least can count on g++, while using the native # linker else # do ugly stuff for each OS fi fi That way, I think we can factorize out most similarities in behaviour. (I'm not just whining ;) on the weekend I'll try to implement something similar to above, the next BETA is not that far away ;) Btw. just a small thing: in all 'case' statements testing for $CXX you should use $compiler, as $CXX can have arguments. In fact it is set already in the beginning, just not used. No diff, because it would be larger than the description ;) Ciao, Michael.
Re: ltcf-cxx.sh
Hi Michael, On Fri, May 26, 2000 at 12:51:01AM +0200, Michael Matz wrote: > On Mon, 22 May 2000, Ossama Othman wrote: > > Great! KDE would be a great smoke test for the multi-language branch > > libtool. > > It's smoking already ;) Even with problem reports ;) Great! Well, at least for the libtool team. :-) > On Wed, 24 May 2000, Ossama Othman wrote: > > I'll try to move the general g++ configurations outside of the > > platform-specific configurations soon. > > Great. Note that it's all not only depending on the compiler, but also on > the actual linker used, so $with_gnu_ld should also be tested. E.g. just > today I had a report from someone using KDE on Solaris with gcc and GNU > ld. Currently that won't work, because on Solaris ltcf-cxx.sh thinks its > using the native linker. (for -export-symbols it tries to give -M bla.exp > to the linker). Ah! Good point! > I guess, the easiest solution would be, to structure ltcf-cxx.sh like: > > if test $with_gcc = yes && test $with_gnu_ld = yes ; then > # do useful things, mostly independent from the OS > # note, that mostly (if $with_gnu_ld --> also $with_gcc) > else > if test $with_gcc = yes ; then > # do stuff where we at least can count on g++, while using the native > # linker > else > # do ugly stuff for each OS > fi > fi > > That way, I think we can factorize out most similarities in behaviour. > (I'm not just whining ;) on the weekend I'll try to implement something > similar to above, the next BETA is not that far away ;) That sounds good. Thanks so much for your help Michael! Needless to say, it is greatly appreciated! > Btw. just a small thing: in all 'case' statements testing for $CXX you > should use $compiler, as $CXX can have arguments. In fact it is set > already in the beginning, just not used. No diff, because it would be > larger than the description ;) Hmm, I though that Alexandre as already took care of this. It must've been a patch that wasn't integrated. Alexandre, should I integrate your patch? Thanks for reminding me of this problem Michael! All of this feedback is great! I think that we can make some real progress on the multi-language branch because of it!!! Thanks again, -Ossama -- Ossama Othman <[EMAIL PROTECTED]> Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ltcf-cxx.sh
On Fri, 26 May 2000, Michael Matz wrote: > Great. Note that it's all not only depending on the compiler, but also on > the actual linker used, so $with_gnu_ld should also be tested. E.g. just > today I had a report from someone using KDE on Solaris with gcc and GNU > ld. Currently that won't work, because on Solaris ltcf-cxx.sh thinks its > using the native linker. (for -export-symbols it tries to give -M bla.exp > to the linker). Maybe I am missing something here but can't you just let g++ handle all the C++ issues. If G++ does call the native linker and you need to pass special options too it this native linker is bound to be the same as the linker used for C programs. So then can't C++ libtool get the necessarily options to pass (like the rpath stuff) from the C part of libtool. Or am I missing something? --- Kevin Atkinson [EMAIL PROTECTED] http://metalab.unc.edu/kevina/
