Re: ILD too long
On Fri, 25 Feb 2000, Ossama Othman wrote: > I did just realize that the compiler options passed to libtool during > the link phase are being stripped from the link command. For example: > >bin/sh ../libtool --tag=CXX --mode=link c++ -W -Wall -Wpointer-arith >-fno-implicit-templates -g -O2 -pthread -pipe -O3 -o libACE.la -rpath >/usr/local/lib-version-info 5:14:0 Basic_Types.lo OS.lo ... -lrt -ldl > > becomes: > >c++ -shared -nostdlib /usr/lib/crti.o >/usr/lib/gcc-lib/i386-linux/2.95.2/crtbeginS.o .libs/Basic_Types.o .libs/OS.o ... >-L/usr/lib/gcc-lib/i386-linux/2.95.2 -lrt -ldl -lstdc++ -lm -lc -lgcc -lc >/usr/lib/gcc-lib/i386-linux/2.95.2/crtendS.o /usr/lib/crtn.o -Wl,-soname >-Wl,libACE.so.5 -o .libs/libACE.so.5.0.14 > > This is clearly busted. I'm working on this problem. Bob, I wonder > if this is the cause of your C++ exception problems. Are you passing > some sort of exception flag at link time? Oh, dear! I am not using any exception flag (that I am aware of), however, ImageMagick is passing options to support large files & pthreads, as well as being linked against oodles of shared libraries. There are user-specified options such as -R to specify the library run-path. I think I can get back to this tomorrow ... Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Extra library dependencies?
I am encountering a very strange problem when using CVS libtool (multi-lingual) in that several libraries are repeated (as reported by ldd) as dependencies, and these libraries are not found at run-time. This is under Solaris 2.6, using gcc 2.9.5. This is sample output from ldd: % ldd `which display` libMagick.so.5 =>/usr/local/lib/libMagick.so.5 libjbig.so.0 => /usr/local/lib/libjbig.so.0 libdf.so => /usr/local/lib/libdf.so libtiff.so =>/usr/local/lib/libtiff.so libttf.so.2 => /usr/local/lib/libttf.so.2 libintl.so.1 => /usr/lib/libintl.so.1 libjpeg.so.62 => /usr/local/lib/libjpeg.so.62 libpng.so.2 => /usr/local/lib/libpng.so.2 libdpstk.so.5 => (file not found) libdps.so.5 => (file not found) libXext.so.0 => /usr/lib/libXext.so.0 libXt.so.4 =>/usr/lib/libXt.so.4 libX11.so.4 => /usr/lib/libX11.so.4 libsocket.so.1 =>/usr/lib/libsocket.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libbz2.so => /usr/local/lib/libbz2.so libz.so => /usr/local/lib/libz.so libpthread.so.1 => /usr/lib/libpthread.so.1 libm.so.1 => /usr/lib/libm.so.1 libc.so.1 => /usr/lib/libc.so.1 libdpstk.so.5 => /usr/openwin/lib/libdpstk.so.5 libdps.so.5 => /usr/openwin/lib/libdps.so.5 libSM.so.6 =>/usr/openwin/lib/libSM.so.6 libICE.so.6 => /usr/openwin/lib/libICE.so.6 libdl.so.1 =>/usr/lib/libdl.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libthread.so.1 =>/usr/lib/libthread.so.1 And this is how it is linked by libtool: /bin/sh ./libtool --mode=link gcc -g -O -Wall -o display display.o magick/libMagick.la gcc -g -O -Wall -o .libs/display display.o magick/.libs/libMagick.so -L/usr/local/lib -L/usr/openwin/lib /usr/local/lib/libjbig.so -ldf -ltiff /usr/local/lib/libttf.so -lintl /usr/local/lib/libjpeg.so /usr/local/lib/libpng.so -ldpstk -ldps -lXext -lXt -lX11 -lsocket -lnsl -lbz2 -lz -lpthread -lm -R/usr/local/lib creating display Even though LDFLAGS includes -R/usr/local/lib:/usr/openwin/lib, libtool seems to be removing /usr/openwin/lib, where the problem libraries reside. However, notice that one of the two references to the library is discovered anyway. Does anyone know how to resolve this problem? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Libtool ltdl descriptor leak is non-bug
It turns out that the issue I reported this weekend regarding libltdl leaving file descriptors open was due to our own applcation. An innocent looking function to return a list of files in the module directory was recursing back to the module loading function. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
AC_CANONICAL_BUILD
I notice that AC_CANONICAL_BUILD is now considered to be an internal macro (CVS autoconf) and is renamed _AC_CANONICAL_BUILD. CVS libtool is still requiring AC_CANONICAL_BUILD so it does not work with CVS autoconf. Will this be fixed soon? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
RE: Extra library dependencies?
On Tue, 14 Mar 2000, Thomas Tanner wrote: > > On 27-Feb-2000 Bob Friesenhahn wrote: > > I am encountering a very strange problem when using CVS libtool > > (multi-lingual) in that several libraries are repeated (as reported by > > ldd) as dependencies, and these libraries are not found at run-time. > > This is under Solaris 2.6, using gcc 2.9.5. > >... > > libdpstk.so.5 => (file not found) > > libdps.so.5 => (file not found) > > libdpstk.so.5 => /usr/openwin/lib/libdpstk.so.5 > > libdps.so.5 => /usr/openwin/lib/libdps.so.5 > >... > > Even though LDFLAGS includes -R/usr/local/lib:/usr/openwin/lib, >^ > This syntax is not supported > Try using -R/usr/local/lib -R/usr/openwin/lib I used both syntaxes at once for good measure. :-) A careful configure this morning leads to a config.status with this configuration comment: # /home/bfriesen/src/graphics/ImageMagick/configure CFLAGS='-g -O -Wall -Wmissing-prototypes' 'CFLAGS=-g -O -Wall -Wmissing-prototypes' 'LDFLAGS=-L/usr/local/lib -R/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib' --enable-lzw --disable-static --enable-shared --enable-ltdl-convenience Ldd shows that the libdpstk and libdps entries are repeated in the linked executable. This is the link line: /bin/sh ./libtool --mode=link gcc -g -O -Wall -Wmissing-prototypes -o display display.o magick/libMagick.la gcc -g -O -Wall -Wmissing-prototypes -o .libs/display display.o magick/.libs/libMagick.so -L/usr/local/lib -L/usr/openwin/lib /usr/local/lib/libjbig.so -ldf -ltiff /usr/local/lib/libttf.so -lintl /usr/local/lib/libjpeg.so /usr/local/lib/libpng.so -ldpstk -ldps -lXext -lXt -lX11 -lsocket -lnsl -lbz2 -lz -lpthread -lm -R/usr/local/lib creating display This is the dependency_libs entry from the libMagick.la file: dependency_libs=' -L/usr/local/lib -L/usr/openwin/lib /usr/local/lib/libjbig.la -ldf - ltiff /usr/local/lib/libttf.la -lintl /usr/local/lib/libjpeg.la /usr/local/lib/libpng. la -ldpstk -ldps -lXext -lXt -lX11 -lsocket -lnsl -lbz2 -lz -lpthread -lm' And here is the relink_command entry (note replicated LDFLAGS): relink_command="cd /tmp/im8/magick; /bin/sh ../libtool --mode=relink gcc -g -O -Wall - Wmissing-prototypes -L/usr/local/lib -R/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib -L/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib -o libMagick.la -rpath /u sr/local/lib -version-info 5:20:0 PreRvIcccm.lo animate.lo annotate.lo attributes.lo b lob.lo cache.lo cache_view.lo colors.lo compress.lo constitute.lo decorate.lo delegate s.lo display.lo draw.lo effects.lo enhance.lo error.lo gems.lo image.lo magick.lo memory.lo modules.lo monitor.lo montage.lo quantize.lo segment.lo shear.lo signature.lo st ream.lo timer.lo transform.lo utility.lo widget.lo xwindows.lo zoom.lo avs.lo bim.lo b mp.lo cmyk.lo dcm.lo dps.lo ept.lo fax.lo fits.lo fpx.lo gif.lo gradation.lo gray.lo h df.lo histogram.lo html.lo icc.lo icon.lo iptc.lo jbig.lo jpeg.lo label.lo logo.lo map .lo matte.lo miff.lo mono.lo mtv.lo pcd.lo pcl.lo pcx.lo pdb.lo pdf.lo pict.lo pix.lo png.lo plasma.lo pnm.lo preview.lo ps.lo ps2.lo ps3.lo psd.lo pwp.lo rgb.lo rla.lo rle .lo sct.lo sfw.lo sgi.lo stegano.lo sun.lo svg.lo tga.lo tiff.lo tile.lo tim.lo ttf.lo txt.lo uil.lo uyvy.lo vicar.lo vid.lo viff.lo wbmp.lo x.lo xbm.lo xc.lo xpm.lo xwd.lo yuv.lo -ljbig -ldf -ltiff -lttf -ljpeg -lpng -ldpstk -ldps -lXext -lXt -lX11 -lsocket -lnsl -lbz2 -lz -lpthread -lm" The ldpstk and ldps libraries are peculiar in that they are some of the few Open Windows libraries which are not symbolically linked from /usr/lib. > > libtool seems to be removing /usr/openwin/lib, where the problem > > libraries reside. However, notice that one of the two references to > > the library is discovered anyway. > > Maybe -R/usr/openwin/lib is hardcoded into another > library that uses libdps[tk]? Nope. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Still have linkage problems with libtool
Some of you may recall that I reported a linkage problem when using CVS libtool, and relying on its library dependency support under Solaris 2.6. The problem seems to be that although LDFLAGS is specified as: 'LDFLAGS= -L/usr/local/lib -R/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib' to configure (taken from config.status), libtool does not apply the last -R option at link time: /bin/sh ./libtool --mode=link gcc -g -O -Wall -Wmissing-prototypes -o display display.o magick/libMagick.la gcc -g -O -Wall -Wmissing-prototypes -o .libs/display display.o magick/.libs/libMagick.so -L/usr/local/lib -L/usr/openwin/lib /usr/local/lib/libjbig.so -ldf -ltiff /usr/local/lib/libttf.so -lintl /usr/local/lib/libjpeg.so /usr/local/lib/libpng.so -ldpstk -ldps -lXext -lXt -lX11 -lsocket -lnsl -lbz2 -lz -lpthread -lm -R/usr/local/lib creating display I can use libtool to build other programs against the same library, and those programs work. Interestingly, I can 'make dist' the package, and build the result under Solaris 7, and the problem is not experienced. Maybe this is a problem with my configure script, or Automake configuration, but it would be really nice to get to the bottom of it. Thanks, Bob ========== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Still have linkage problems with libtool
On 20 Mar 2000, Alexandre Oliva wrote: > On Mar 20, 2000, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > > > /bin/sh ./libtool --mode=link gcc -g -O -Wall -Wmissing-prototypes -o > > display display.o magick/libMagick.la > > Does libMagick.la (the script) contains both -R flags? What was the > command used to link it? The dependency_libs entry does not include any -R flags. The relink_command entry does include both -R flags. This hairy statement captures the link step: /bin/sh ../libtool --mode=link gcc -O -g -Wall -L/usr/local/lib -L/usr/openwin/lib -R/usr/local/lib -R/usr/openwin/lib -L/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib -o libMagick.la -rpath /usr/local/lib -version-info 5:20:0 PreRvIcccm.lo animate.lo annotate.lo attributes.lo blob.lo cache_view.lo colors.lo compress.lo constitute.lo decorate.lo delegates.lo display.lo draw.lo effects.lo enhance.lo error.lo gems.lo image.lo magick.lo memory.lo modules.lo monitor.lo montage.lo quantize.lo segment.lo shear.lo signature.lo stash.lo stream.lo timer.lo transform.lo utility.lo widget.lo xwindows.lo zoom.lo avs.lo bim.lo bmp.lo cache.lo cmyk.lo dcm.lo dps.lo ept.lo fax.lo fits.lo fpx.lo gif.lo gradation.lo gray.lo hdf.lo histogram.lo html.lo icc.lo icon.lo iptc.lo jbig.lo jpeg.lo label.lo logo.lo map.lo matte.lo miff.lo mono.lo mtv.lo pcd.lo pcl.lo pcx.lo pdb.lo pdf.lo pict.lo pix.lo png.lo plasma.lo pnm.lo preview.lo ps.lo ps2.lo ps3.lo psd.lo pwp.lo rgb.lo rla.lo rle.lo sct.lo sfw.lo sgi.lo stegano.lo sun.lo svg.lo tga.lo tiff.lo tile.lo tim.lo ttf.lo txt.lo uil.lo uyvy.lo vicar.lo vid.lo viff.lo wbmp.lo x.lo xbm.lo xc.lo xpm.lo xwd.lo yuv.lo -ljbig -ldf -ltiff -lttf -ljpeg -lpng -ldpstk -ldps -lXext -lXt -lX11 -lsocket -lnsl -lbz2 -lz -lpthread -lm /usr/ccs/bin/ld -G -h libMagick.so.5 -o .libs/libMagick.so.5.0.20 .libs/PreRvIcccm.o .libs/animate.o .libs/annotate.o .libs/attributes.o .libs/blob.o .libs/cache_view.o .libs/colors.o .libs/compress.o .libs/constitute.o .libs/decorate.o .libs/delegates.o .libs/display.o .libs/draw.o .libs/effects.o .libs/enhance.o .libs/error.o .libs/gems.o .libs/image.o .libs/magick.o .libs/memory.o .libs/modules.o .libs/monitor.o .libs/montage.o .libs/quantize.o .libs/segment.o .libs/shear.o .libs/signature.o .libs/stash.o .libs/stream.o .libs/timer.o .libs/transform.o .libs/utility.o .libs/widget.o .libs/xwindows.o .libs/zoom.o .libs/avs.o .libs/bim.o .libs/bmp.o .libs/cache.o .libs/cmyk.o .libs/dcm.o .libs/dps.o .libs/ept.o .libs/fax.o .libs/fits.o .libs/fpx.o .libs/gif.o .libs/gradation.o .libs/gray.o .libs/hdf.o .libs/histogram.o .libs/html.o .libs/icc.o .libs/icon.o .libs/iptc.o .libs/jbig.o .libs/jpeg.o .libs/label.o .libs/logo.o .libs/map.o .libs/matte.o .libs/miff.o .libs/mono.o .libs/mtv.o .libs/pcd.o .libs/pcl.o .libs/pcx.o .libs/pdb.o .libs/pdf.o .libs/pict.o .libs/pix.o .libs/png.o .libs/plasma.o .libs/pnm.o .libs/preview.o .libs/ps.o .libs/ps2.o .libs/ps3.o .libs/psd.o .libs/pwp.o .libs/rgb.o .libs/rla.o .libs/rle.o .libs/sct.o .libs/sfw.o .libs/sgi.o .libs/stegano.o .libs/sun.o .libs/svg.o .libs/tga.o .libs/tiff.o .libs/tile.o .libs/tim.o .libs/ttf.o .libs/txt.o .libs/uil.o .libs/uyvy.o .libs/vicar.o .libs/vid.o .libs/viff.o .libs/wbmp.o .libs/x.o .libs/xbm.o .libs/xc.o .libs/xpm.o .libs/xwd.o .libs/yuv.o -R/usr/local/lib -R/usr/openwin/lib -L/usr/local/lib -L/usr/openwin/lib /usr/local/lib/libjbig.so -ldf -ltiff /usr/local/lib/libttf.so /usr/local/lib/libjpeg.so /usr/local/lib/libpng.so -ldpstk -ldps -lXext -lXt -lX11 -lsocket -lnsl -lbz2 -lz -lpthread -lm -lc (cd .libs && rm -f libMagick.so.5 && ln -s libMagick.so.5.0.20 libMagick.so.5) (cd .libs && rm -f libMagick.so && ln -s libMagick.so.5.0.20 libMagick.so) creating libMagick.la (cd .libs && rm -f libMagick.la && ln -s ../libMagick.la libMagick.la) == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Application of convenience libraries?
In an effort to re-organize the ImageMagick source tree, I have moved many files which are part of the ImageMagick library (libMagick.[a|so]) to a seperate directory. I then build these files into a convenience library, and link against the convenience library when creating libMagick. This works great when all the libraries libMagick depends on are installed shared libraries, but if the libraries are static libraries built by libtool (which reside in another package's directory), then duplicate symbol conflicts are experienced when using libtool to link programs based on libMagick. In the documentation for CVS libtool 1.3c, section "Linking static libraries", there is a description of how to do this: "But be careful not to link a single convenience library, directly or indirectly, into a single program or library, otherwise you may get errors about symbol redefinitions.". I do not understand this sentance. The linkage of the dependent programs depends entirely on libtool's library dependency mechanism. No libraries are specified at all when the programs are linked. I am expecting that the final libMagick product will be the same as before. Help! Bob ========== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Application of convenience libraries?
This is regarding my posting last night regarding linkage problems when linking programs against a library which was built, in part, from a convenience library. There is a grevious error in my description of the problem. Rather than conflicting symbols, the current problem is that there are unresolved symbols. These unresolved symbols only occur due to a static library (built using libtool and called libttf.a) which is linked as a dependency when the target library (libMagick) is created. Therefore, it seems that CVS libtool's dependency support is not applying this dependency library when programs are built against the target library (libMagick). Symbols from the other static libraries (which were not built using libtool) do not show up as unresolved. Pictorially: convenience libttf.la other static lib (static) libs \ | / \ |/ \ | / \| / \ | / \ |/ \ | / \| / \ | / libMagick.so | | program Symbols from libttf.la are unresolved. Is there a workaround for this? I would prefer for libtool to take care of this rather than attempting to guess which libraries are static or shared libs, and applying them at different points in the build cycle. These other libraries are from other packages than my own. Thanks, Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
AM_ENABLE_SHARED?
I have been using AM_ENABLE_SHARED(no) AM_ENABLE_STATIC(yes) AC_PROG_LIBTOOL in configure.in in order to control the default settings for whether shared libraries are built or not. It seems that supplying these in configure.in to set the defaults is not supported any more (nothing in the documentation). Now I see --enable-shared[=PKGS] build shared libraries [default=yes] --enable-static[=PKGS] build static libraries [default=yes] --enable-fast-install[=PKGS] optimize for fast installation [default=yes] --disable-libtool-lock avoid locking (might break parallel builds) --enable-shared[=PKGS] build shared libraries [default=no] --enable-static[=PKGS] build static libraries [default=yes] In the configure --help output, and the first set seems to win. Is there a fix for this. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: AM_ENABLE_SHARED?
On 4 Apr 2000, Alexandre Oliva wrote: > On Apr 4, 2000, Akim Demaille <[EMAIL PROTECTED]> wrote: > > >>>>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: > Bob> I have been using AM_ENABLE_SHARED(no) AM_ENABLE_STATIC(yes) > Bob> AC_PROG_LIBTOOL > > > Will probably disappear if you move to AC_, not AM_. Untested. > > Why would it disappear? One just `indir's the other. And it doesn't disappear. From the generated configure's help output: Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --disable-dependency-tracking Speeds up one-time builds --enable-dependency-tracking Do not reject slow dependency extractors --enable-shared=PKGS build shared libraries default=yes --enable-static=PKGS build static libraries default=yes --enable-fast-install=PKGS optimize for fast installation default=yes --disable-libtool-lock avoid locking (might break parallel builds) --enable-shared=PKGS build shared libraries default=no --enable-static=PKGS build static libraries default=yes This is the relevant configure.in code: # # Configure libtool and ltdl # AC_LIBLTDL_CONVENIENCE # Substitute INCLTDL and LIBLTDL in the Makefiles AC_SUBST(INCLTDL) AC_SUBST(LIBLTDL) # Check for dlopen support AC_LIBTOOL_DLOPEN AC_LIBTOOL_SETUP # Configure libtool AC_ENABLE_SHARED(no) AC_ENABLE_STATIC(yes) AC_PROG_LIBTOOL Am I doing something in the wrong order? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: AM_ENABLE_SHARED?
In answer to my own issue, moving AC_ENABLE_SHARED and AC_ENABLE_STATIC to before AC_LIBLTDL_CONVENIENCE elminates the problem: # # Configure libtool and ltdl # AC_ENABLE_SHARED(no) AC_ENABLE_STATIC(yes) AC_LIBLTDL_CONVENIENCE # Substitute INCLTDL and LIBLTDL in the Makefiles AC_SUBST(INCLTDL) AC_SUBST(LIBLTDL) # Check for dlopen support AC_LIBTOOL_DLOPEN AC_LIBTOOL_SETUP AC_PROG_LIBTOOL works. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Libtool dynamic modules under FreeBSD 4.0
Using the CVS libtool and FreeBSD 4.0, I get this warning message when building a module, and a .a file is created rather than a .so file: *** Warning: inter-library dependencies are not known to be supported. *** All declared inter-library dependencies are being dropped. *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module 8bim. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. I have not yet tried the -dlopen option that it advises. Will this problem be fixed soon? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
More on modules and FreeBSD 4.0
As a follow up to my previous email, there is no dlopen library provided with FreeBSD 4.0, so the advice that libtool gives when it builds a static library rather than a shared-library style module is not valid. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: More on modules and FreeBSD 4.0
On Sat, 8 Apr 2000, Bob Friesenhahn wrote: > As a follow up to my previous email, there is no dlopen library > provided with FreeBSD 4.0, so the advice that libtool gives when it > builds a static library rather than a shared-library style module is > not valid. Please disregard this previous statement. I see that this option is a libtool option, and not an actual linker option or library. My package is not using module pre-opening since it can easily be compiled without modules when modules are not supported. It also does not use the "libname_LTX_" scheme for symbol naming since all symbol names are already unique. If the -dlopen option must be supplied, how is it specified? The documentation says the syntax is `-dlopen file'. Must I include instances of this for all 72 of my modules? If so, how does this help the system load an old-style archive file? The documentation for dlopen only mentions opening shared libraries ... Bob ========== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 2nd Try: Shared libraries w/ C++ and libltdl
On Mon, 10 Apr 2000, Kevin Atkinson wrote: > About a week ago I posted this massage to the libtool mailing but I have > yet to receive any replies. Don't feel too bad. I have posted questions to the libtool list quite a number of times, but rarely receive any response (most responses from Ossama). I think that answers (which include a patch) are more highly regarded than questions. Regarding your Problem 2, the way the library I maintain (ImageMagick, http://www.imagemagick.org) does it, each module exposes unique symbols using a pre-defined naming scheme so that the module loader computes the correct name for symbol in the module. Only one symbol needs to be loaded. The rest of the symbols are registered via call-back from the module itself. This eliminates any need for the pre-loading complexity. The library has 72 modules. I doubt that the command line can reliably pass enough parameters to handle libtool's preload requirement for 72 modules. With the above scheme (using call-backs to the library), there may still be a requirement for special linkage for programs. The libtool docs specify that if libtool is used to link the program, -export-dynamic must be specified. Bob > > I could REALLY use some help here. I understand I am using a > developmental version and will be willing to work with you to help improve > libtools. > > Maybe I should just not use the CXX language features and just some how > make sure all the right libraries get linked in and just avoid using > global variables which require initilization... > > Please give me some guidance here. > > -- Forwarded message -- > Date: Tue, 4 Apr 2000 17:40:01 -0400 (EDT) > From: Kevin Atkinson <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Shared libraries w/ C++ and libltdl. > Resent-Date: Tue, 4 Apr 2000 17:39:36 -0400 > Resent-From: [EMAIL PROTECTED] > > I am having all sorts of problems with shared libraries and C++ with the > multi-lang. branch. > > PROBLEM 1 > > 1) On many platforms libtool can create shared libraries for C but not for > C++ > > 2) On many of the platforms which libtool does know how to create C++ > shared libraries libstdc++ is not compiled as a shared library, nor is it > compiled with PIC support. This means that linking the shared library > fails miserably because it will try to link the non PIC code into the > shared library. > > So my question is > > 1) Is there a way to force libtool NOT to link it as a C++ library if it > can't do it as a shared library. IE don't fall back to only making a > static library. > > 2) Is there a way to force libtool NOT to link in libstdc++ but STILL link > it using c++? > > In either case I would like the C++ libraries to be specified in the .la > files so that they will get statically linked in by libtool when a C program > uses my libraries. > > PROBLEM 2 > > Is they a way to do the ldpreloding stuff that is 100% transparent to > programs linking with my libraries using libtool? I want the end user to > have to doing noting but "libtool --mode=link ... -l" and have > libtool automatically preload the necessary modules and set up the data > structure automatically so that the end user does NOT have to call > LTDL_SET_PRELOADED_SYMBOLS(). > > > Thanks in advance. Any advice you can give me would really help me out > with my Pspell (http://pspell.sourceforge.net) project. > > --- > Kevin Atkinson > [EMAIL PROTECTED] > http://metalab.unc.edu/kevina/ > > == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: 2nd Try: Shared libraries w/ C++ and libltdl
On Mon, 10 Apr 2000, Kevin Atkinson wrote: > On Mon, 10 Apr 2000, Bob Friesenhahn wrote: > > > Regarding your Problem 2, the way the library I maintain (ImageMagick, > > http://www.imagemagick.org) does it, each module exposes unique > > symbols using a pre-defined naming scheme so that the module loader > > computes the correct name for symbol in the module. Only one symbol > > needs to be loaded. The rest of the symbols are registered via > > call-back from the module itself. This eliminates any need for the > > pre-loading complexity. The library has 72 modules. I doubt that the > > command line can reliably pass enough parameters to handle libtool's > > preload requirement for 72 modules. > > I basically do the same thing. But I need to be able to get the modules > loaded some how. How do you do if they can't be loaded using dlopen and > friends. I should have mentioned that when these objects are not loaded as modules, they are included in a larger shared or static library via the magic of Automake conditionals. There is a small fragment of conditional code which comes into effect when the modules are included as objects in the larger library, which serves to invoke their registration routines. This means that there is very little source difference between the module version and the library version. > The basic problem is that on many platforms the C++ libraries are NOT > compiled as static libraries (and often not compiled with pic > support (which means they can't get linked into the shared modules) but > they some how need to get access to the c++ libraries when loaded This is indeed annoying. Some configure-magic could identify the problem. Then you would need some way to instruct libtool to build the appropriate library. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Solution to Preload problem & Feature Request
On Fri, 14 Apr 2000, Kevin Atkinson wrote: > Doesn't either setting LD_LIBRARY_PATH (or the equivalent variable for > your particular system) or adding the weird location to /etc/ld.so.conf > (or the equivalent file for your particular system) generally solve the > problem? Try supporting this for 5000 users of your installed program across 5000 workstations/PCs. This approach fails miserably. Besides the effort to get your users to use the same LD_LIBRARY_PATH, there is the problem with conflicts between similarly named libraries. The LD_LIBRARY_PATH variable was intended for developers, and it should be treated as such. > I don't see why manually infusing the location of the library is really > necessary. Wouldn't manually infusing the location of the library into > executables cause problems if the libraries are ever moved? It would > seam to me that it will also make an executable extremely non portable across > multiple sytems Systems which want to copy binaries around should agree on standard library locations and naming conventions. Otherwise, there is always compilation from source. Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Solution to Preload problem & Feature Request
On Fri, 14 Apr 2000, Kevin Atkinson wrote: > > Try supporting this for 5000 users of your installed program across > > 5000 workstations/PCs. This approach fails miserably. Besides the > > effort to get your users to use the same LD_LIBRARY_PATH, there is the > > problem with conflicts between similarly named libraries. > > > > The LD_LIBRARY_PATH variable was intended for developers, and it > > should be treated as such. > > What about supporting relocatable binaries with shared libraries in the > same directory as the binary on some other path relative to the binary. > This is found in many commercial programs. Commercial programs typically include a shell script which sets LD_LIBRARY_PATH (and other variables) in order to find the package components. While this may be fine for commercial software, it is not acceptable for free software since free software must be held to a higher standard of quality. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Solution to Preload problem & Feature Request
On Fri, 14 Apr 2000, Kevin Atkinson wrote: > On Fri, 14 Apr 2000, Bob Friesenhahn wrote: > > > Commercial programs typically include a shell script which sets > > LD_LIBRARY_PATH (and other variables) in order to find the package > > components. While this may be fine for commercial software, it is not > > acceptable for free software since free software must be held to a > > higher standard of quality. > > And what exactly is wrong with this approach. How it it not acceptable for > free software. Are you trying to say that free software packages should > ALWAYS be compiled for a precise system setup? Yes, of course. Free software should be well integrated with the system rather than be applied as an afterthought. This provides a more solid base for dependent applications, improves performance, and improves usability. Note that since free software is available with full source code, it can be compiled to specifically match a particular system configuration if an appropriate binary distribuition for that system is not available. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
CVS libtool incompatability with IRIX compiler
The IRIX C/C++ compiler accepts aguments of the form "-LANG:std". Options of this form must be specified in order to compile and link C++ code, and possibly strict ANSI code. Unfortunately, libtool parses these options as being linker path options and does not supply them properly to the compiler and linker. The appropriate fix to this problem is for libtool to verify that the specified directory exists prior to deciding that this is a normal -L option, otherwise the option should be passed on to the compiler and linker. Thanks, Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: CVS libtool incompatability with IRIX compiler
On Sat, 26 Aug 2000, Gary V. Vaughan wrote: > > Sounds good to me. In order to not penalise IRIX developers, I guess > libtool should continue to discard -LANG:foo and friends, except on > IRIX. That would make it safe to add the following to your Makefile.am: > > libfoo_la_LIBADD = -LANG:std > > Following this principle through to its logical conclusion, do we also > need to discard these flags on IRIX when GNU ld is the linker? Now we are going overboard a bit. It is better to insert something for a particular platform rather than add everything for all platforms and take away what is not needed. Bob ========== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Multi-lingual libtool annoyance
It would be nice if the $Id RCS tags were removed from the ltcf-c.sh ltcf-cxx.sh and ltcf-gcj.sh files in the multi-lingual libtool branch because these tags are (by default) updated whenever they are checked into CVS. This leads to the appearance of continual change when there is none. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Multi-lingual libtool annoyance
On Wed, 30 Aug 2000, Ossama Othman wrote: > Hi Bob, > > On Wed, Aug 30, 2000 at 08:21:49AM -0500, Bob Friesenhahn wrote: > > It would be nice if the $Id RCS tags were removed from the ltcf-c.sh > > ltcf-cxx.sh and ltcf-gcj.sh files in the multi-lingual libtool branch > > because these tags are (by default) updated whenever they are checked > > into CVS. This leads to the appearance of continual change when there > > is none. > > I'm not sure what you mean by "continual change." I actually find the > RCS ID tags fairly useful, but I'm not that attached to them. > If the rest of team wants to remove them, I certainly won't object. If the file is checked into a different CVS repository, CVS considers the number associated with $Id: to be a change, and commits it as an update (and reports that the file changed). In my particular situation I find this to be annoying because I take check files out of one repository and commit them to another. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
libtool, nm, & -B
The libtool-multilang branch of libtool seems to be having difficulties lately due to its assumption that -B (a MIPS compatability option in GNU nm) is accepted by nm. Unfortunately, it is not accepted by BSD or Solaris nm, and produces an error message similar to the following: checking command to parse /usr/bin/nm -B output... nm: illegal option -- B usage: nm [-agnopruw] [file ...] nm: illegal option -- B usage: nm [-agnopruw] [file ...] failed Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Libtool warning message
Using CVS Automake, Autoconf, and multi-lingual libtool I see the following message printed from configure: checking whether a program can dlopen itself... cat: cannot open conftest.cc no Under Solaris 2.6. I believe that the main-branch libtool prints the same message. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
[Libtool] Multi-lingual libtool nit
Using CVS Libtool, Automake, and Autoconf: Under Solaris 2.6 (and reportedly Solaris 8) the following message is emmitted from configure: checking for X... libraries /usr/openwin/lib, headers /usr/openwin/include checking whether -R must be followed by a space... cat: cannot open conftest.c cat: cannot open conftest.c neither works this is in addition to the previously reported checking for dlopen in -ldl... yes checking for dlfcn.h... yes checking whether a program can dlopen itself... cat: cannot open conftest.cc no Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Multi-lingual libtool and Sun Workshop 5
I am seeing some strange problems when compiling *some* C++ programs using the C++ compiler from Sun Workshop 5. I have six or eight simple one-source-file programs built in a given directory, and all compile/link except for one. The linker fails with an error like ild: (bad file) argument file doesn't exist :: .libs/SunWS_cache/CC_obj_2/2yi5kEpmEtUw_3Zz13e2.o I notice that this file is available as SunWS_cache/CC_obj_2/2yi5kEpmEtUw_3Zz13e2.o by playing the trick mkdir SunWS_cache; mkdir .libs; cd .libs; ln -s ../SunWS_cache .; cd .. make all of the programs then compile and run. While I don't see any significant coding difference between the various programs (it may be that the ones which fail are less template-heavy), something about the program is causing the template instantiation to be written to the wrong place. Libtool is obviously involved given the .libs offset. Has anyone seen this before? Is there a fix or workaround? Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Multi-lingual libtool and Sun Workshop 5
On Thu, 28 Sep 2000, Art Pope wrote: > > I am seeing some strange problems when compiling *some* C++ programs > > using the C++ compiler from Sun Workshop 5. I have six or eight > > simple one-source-file programs built in a given directory, and all > > compile/link except for one. The linker fails with an error like... > > Could be caused by building all programs in the same directory. Sun C++ is > using the same template repository for each and, unless the repository is > cleaned out between programs, it will become confused as to what template > instantiations go with a program. Template instantiations should not really be program dependent as long as they depend on the same types, defined via the same header files. I have discovered that Sun's newer compiler (Forte 6.0) builds my software just fine, without encountering this bug. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Multi-lingual libtool and Sun Workshop 5
On Thu, 28 Sep 2000, Art Pope wrote: > Could be caused by building all programs in the same directory. Sun C++ is > using the same template repository for each and, unless the repository is > cleaned out between programs, it will become confused as to what template > instantiations go with a program. > > > Has anyone seen this before? Is there a fix or workaround? > > Place them in separate directories, or clean out the template repository > between builds. See Sun's CCadmin(1) man page. I have verified that if the failing program is built by itself, with no pre-existing SunWS_cache directory, that it still fails to link in an identical way. Bob ========== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
multi-lingual libtool & -KPIC
Using CVS Autoconf & CVS multi-lingual libtool checked out today, configure guesses wrong on gcc PIC flags under Solaris 2.6: checking for gcc option to produce PIC... -KPIC -DPIC checking if gcc PIC flag -KPIC -DPIC works... yes checking if gcc static flag -Bstatic works... yes ltconfig:675:checking for gcc option to produce PIC ltconfig:684:checking that gcc PIC flag -KPIC -DPIC works. ltconfig:694: gcc -c -g -O2 -Wall -KPIC -DPIC -DPIC conftest.c 1>&5 gcc: unrecognized option `-KPIC' ltconfig:746: checking if gcc static flag -Bstatic works ltconfig:755: gcc -o conftest -g -O2 -Wall -L/usr/local/lib -R/usr/local/lib -Bstatic conftest. c 1>&5 conftest.c:1: warning: return-type defaults to `int' gcc: file path prefix `static' never used This leads to later (serious) warnings: gcc: unrecognized option `-KPIC' Shared libraries won't work ... Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
More on gcc/Solaris libtool problem
After some spelunking, I find that the reason libtool is not determining the correct PIC flags under Solaris is that even though configure determines that the the compiler is the GNU C compiler, this is not properly picked up by libtool. I see this in the generated libtool script: # Is the compiler the GNU C compiler? with_gcc=no even though configure reports the following while it is running: checking whether the C compiler works... yes checking whether we are cross compiling... no checking whether we are using the GNU C compiler... yes It seems that whatever interface is used to pass this info from Autoconf to libtool (presumably with_gcc environment variable) is not working any more. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: multi-lingual libtool & -KPIC
Alexandre, Libtool (libtool.m4) is checking the variable ac_cv_prog_gcc in order to determine if the --with-gcc should be passed to ltconfig. I see this in the Autoconf changelog: 2000-10-16 Akim Demaille <[EMAIL PROTECTED]> * aclang.m4 (_AC_LANG_COMPILER_GNU): New macro, which unifies... (_AC_PROG_F77_GNU, _AC_PROG_CC_GNU, _AC_PROG_CXX_GNU): Remove. Adjust dependencies. (ac_cv_prog_gcc, ac_cv_prog_gxx, ac_cv_prog_g77): AU_ALIAS'ed. I am not sure what AU_ALIAS is supposed to do, but obviously it does not cause ac_cv_prog_gcc to be set in the configure script. Instead ac_cv_c_compiler_gnu is set, and ac_cv_prog_gcc is not set at all. What is the best fix for this problem? It seems like autoconf needs to set ac_cv_prog_gcc in order to provide backward compatability for libtool. Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: multi-lingual libtool & gcc
I do not believe that this is the correct way to fix the incompatability between CVS autoconf and libtool on the multi-language-branch (it should be fixed in Autoconf rather than libtool), but this is a patch to libtool that gets multi-lingual libtool users over the hump. If this was the correct fix then I would have provided a ChangeLog. I would be very supprized if the libtool on the main branch is working properly either. Index: libtool.m4 === RCS file: /var/cvs/libtool/libtool.m4,v retrieving revision 1.71.2.37 diff -u -r1.71.2.37 libtool.m4 --- libtool.m4 2000/10/31 23:16:36 1.71.2.37 +++ libtool.m4 2000/11/04 21:00:19 @@ -119,7 +119,7 @@ test "$enable_shared" = no && libtool_flags="$libtool_flags --disable-shared" test "$enable_static" = no && libtool_flags="$libtool_flags --disable-static" test "$enable_fast_install" = no && libtool_flags="$libtool_flags --disable-fast-install" -test "$ac_cv_prog_gcc" = yes && libtool_flags="$libtool_flags --with-gcc" +test "$ac_cv_prog_gcc" = yes -o "$ac_cv_c_compiler_gnu" = yes && +libtool_flags="$libtool_flags --with-gcc" test "$ac_cv_prog_gnu_ld" = yes && libtool_flags="$libtool_flags --with-gnu-ld" ifdef([AC_PROVIDE_AC_LIBTOOL_DLOPEN], [libtool_flags="$libtool_flags --enable-dlopen"]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Useless libtool warnings when installing modules
When shared libraries built as modules are installed by libtool, a message is displayed regarding how to link against the shared library. This message has no value for loadable modules since they are not intended to be used as a normal shared library. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
CVS Autoconf fails on libltdl configure.in
When the development version of Autoconf is used to generate a configure script from CVS libltdl's configure.in this error occurs. configure.in:36: error: m4_require: circular dependency of AC_LTDL_SYMBOL_USCORE configure.in:36: AC_LTDL_SYMBOL_USCORE is required by... ./aclocal.m4:3382: AC_LTDL_DLSYM_USCORE is expanded from... ./aclocal.m4:3318: AC_LTDL_SYMBOL_USCORE is expanded from... configure.in:36: AC_LTDL_SYMBOL_USCORE is required by... ./aclocal.m4:3142: AC_LIB_LTDL is expanded from... configure.in:36: the top level The end result is that an empty configure script is generated. These actions should be taken: o Libltdl's configure.in should be fixed so that it is compatible with both released and development Autoconf. o Autoconf should either preserve an existing configure script, or should leave no configure script at all after an error. Empty configure scripts have a nasty habit of accidentally getting into distributions. Bob ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
CVS libtool 1.4a fails to install
If GNU make is not named 'make' then the install target fails for the multi-language-branch: Making install in libltdl gmake[1]: Entering directory `/home/bfriesen/src/gnu/libtool-multilang/libltdl' Usage : make [ -f makefile ][ -K statefile ]... [ -d ][ -dd ][ -D ][ -DD ] [ -e ][ -i ][ -k ][ -n ][ -p ][ -P ][ -q ][ -r ][ -s ][ -S ][ -t ] [ -V ][ target... ][ macro=value... ] make: Fatal error: Unknown option `-w' This problem is particularly onerous since the install target should not normally depend on GNU make. Installing like 'gmake install MAKE=gmake' works. The other targets (e.g. 'dist') are also handicapped by this problem. I prefer to install GNU make as 'gmake' so that it does not shadow the vendor make program, and makes portability testing easier. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
make distclean fails to remove libltdl/libltdlc.la
I notice that the distclean target in the libltdl directory fails to remove libltdlc.la. This is a bug. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Getting started question:
On Wed, 31 Jan 2001, Robert Collins wrote: > Hi, > If I want to test libtool 1.4 (I develop on openBSD & windows > 2K (via cygwin) - which may be an odd combination :-]), what's the > recommended autoconf version to get? > > I saw a message recently about libtool CVS not being autoconf CVS > ready which is what has prompted my question. In my experience, Libtool CVS generally works with Autoconf CVS. In fact, that is what I have been using for the past couple of years for ImageMagick. Sometimes there are nasty bugs and sometimes things work just fine (just fine at the moment). The snapshot at alpha.gnu.org is a good way to get a recent Autoconf to play with. Just make sure that you test thoroughly prior to releasing anything. > Sometime soon I'm going to add dynamic module support to squid, > which currently configures under autoconf 2.13 Great. Modules are working well for ImageMagick. Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool --config broken
>From libtool checked out from the multi-language-branch as of today, libtool's --config option no longer produces any output. This breaks part of ImageMagick's build environment since certain options are tested to support conditional portions of the Makefiles. Any ideas? Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool --config problem resolved
It seems that the problem I was having is the result of not re-libtoolizing the package directory. This apparently caused a mismatch that created the "bug". Sorry about the noise. Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool does not preserve -xarch=v9
64-bit compilation under Solaris & Sun's compiler requires that the argument '-xarch=v9' be provided when compiling C++ objects. Unfortunately libtool (1.4a (1.641.2.259 2001/06/04 19:32:47)) is discarding this argument (which was passed via LDFLAGS to configure) so objects are built as 32-bit objects instead. Is a fix for this available? Bob ========== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool does not preserve -xarch=v9
On Fri, 21 Sep 2001 [EMAIL PROTECTED] wrote: > On Thu, Sep 20, 2001 at 09:38:29PM -0500, Bob Friesenhahn wrote: > > 64-bit compilation under Solaris & Sun's compiler requires that the > > argument '-xarch=v9' be provided when compiling C++ objects. > > Unfortunately libtool (1.4a (1.641.2.259 2001/06/04 19:32:47)) is > > discarding this argument (which was passed via LDFLAGS to configure) > > so objects are built as 32-bit objects instead. Is a fix for this > > available? > > Does Sun ld(1) even support -xarch? I just checked the manpage on a > Solaris 8/SPARC 64-bit system and didn't see mention of it. I also > tried linking a library using ld(1) with -xarch=v9 as an argument and > got an error. The way Sun's build environment supports 64-bit compilation, it is only necessary to build all objects using -xarch=v9. The linker is responsible for selecting the correct mode based on the mode of the objects. All linked objects must be built for the same model or linking will fail. > Anyway, *without* having LDFLAGS="-xarch=v9", I built HEAD and > ran nm on libltdl/.libs/libltdl.so.3.1.0: > $ nm libltdl/.libs/libltdl.so.3.1.0 > libltdl.so.3.1.0: ELF 64-bit MSB dynamic lib SPARCV9 Version ... How is it that 64-bit was selected unless you requested it? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool does not preserve -xarch=v9
On Fri, 21 Sep 2001 [EMAIL PROTECTED] wrote: > > The way Sun's build environment supports 64-bit compilation, it is > > only necessary to build all objects using -xarch=v9. The linker is > > responsible for selecting the correct mode based on the mode of the > > objects. All linked objects must be built for the same model or > > linking will fail. > > > > Ok, so it sounds like your first problem is that you are trying to > pass a compiler flag to the linker. You're right! This option should be passed via CFLAGS rather than LDFLAGS. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Shared libs under Mac OS X "Darwin"
What is required to get shared libraries working under Mac OS X? Is CVS libtool expected to work for Mac OS X? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libltdl crashes under Solaris LP64 64-bit model
Under SPARC Solaris, libltdl crashes when compiled for the 64-bit
addressing model. I received these words from the ImageMagick
developer who is flushing out 64-bit related bugs:
The bug is in ltdl and may be related to 64-bit or perhaps not. I added
(void) lt_dlopen("tiff.la") as the very first call of convert.c and got
a fault:
detected a multithreaded program
t@1 (l@1) terminated by signal BUS (invalid address alignment)
Current function is rpl_argz_create_sep (optimized)
521 *pargz_len = argz_len;
(/opt/SUNWspro/bin/../WS6U1/bin/sparcv9/dbx) where
current thread: t@1
=>[1] rpl_argz_create_sep(str = ???, delim = ???, pargz = ???, pargz_len = ???)
(optimized), at 0x7f165258 (line ~521) in "ltdl.c"
[2] foreach_dirinpath(search_path = ???, base_name = ???, func = ???, data1 =
???, data2 = ???) (optimized), at 0x7f167cec (line ~2184) in "ltdl.c"
[3] try_dlopen(phandle = ???, filename = ???) (optimized), at
0x7f168c44 (line ~2688) in "ltdl.c"
[4] lt_dlopen(filename = ???) (optimized), at 0x7f169f54 (line ~2919)
in "ltdl.c"
[5] main(argc = ???, argv = ???) (optimized), at 0x13c7c (line ~449) in
"convert.c"
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libltdl crashes under Solaris LP64 64-bit model
The problem with libltdl in the Solaris LP64 64-bit model is due to a mismatch with sizes. argzize_path requires size_t. Under 64-bits size_t is 8 bytes and int is 4 bytes. Here is a patch which should resolve the problem. Index: ltdl.c === RCS file: /home/cvs/libtool/libltdl/ltdl.c,v retrieving revision 1.159 diff -u -r1.159 ltdl.c --- ltdl.c 2001/09/21 17:38:39 1.159 +++ ltdl.c 2001/09/30 03:53:19 @@ -2165,7 +2165,7 @@ int result = 0; int filenamesize = 0; int lenbase= LT_STRLEN (base_name); - int argz_len= 0; + long argz_len= 0; char *argz = 0; char *filename = 0; char *canonical = 0; ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libltdl & 64-bit lint
Here is the output from Sun's 64-bit lint tool when run on libltdl current as of September 29. You will notice that there are a number of type down-conversions going on when the code is 64-bit. In order to be safe, these types should jive for both the ILP32 and LP64 data type models. I don't have ready access to a 64-bit development environment, so I am passing this lint output on from someone else. The "Solaris 64-bit Developer's Guide" available at http://docs.sun.com/ provides an excellent overview of how to ensure that source code will work under both data type models. Bob (390) warning: suspicious comparison of unsigned with 0: op "<=" (517) warning: constant in conditional context (787) warning: constant in conditional context (798) warning: constant in conditional context (831) warning: constant in conditional context (842) warning: constant in conditional context (853) warning: constant in conditional context (858) warning: constant in conditional context (864) warning: constant in conditional context (869) warning: constant in conditional context (872) warning: constant in conditional context (883) warning: constant in conditional context (894) warning: constant in conditional context (904) warning: constant in conditional context (980) warning: constant in conditional context (995) warning: constant in conditional context (1012) warning: constant in conditional context (1478) warning: constant in conditional context (1486) warning: constant in conditional context (1496) warning: constant in conditional context (1504) warning: constant in conditional context (1508) warning: constant in conditional context (1529) warning: constant in conditional context (1555) warning: constant in conditional context (1567) warning: constant in conditional context (1572) warning: constant in conditional context (1602) warning: constant in conditional context (1605) warning: constant in conditional context (1638) warning: constant in conditional context (1729) warning: constant in conditional context (1756) warning: constant in conditional context (1761) warning: constant in conditional context (1766) warning: constant in conditional context (1785) warning: constant in conditional context (1790) warning: constant in conditional context (1800) warning: constant in conditional context (1802) warning: constant in conditional context (1813) warning: constant in conditional context (1818) warning: constant in conditional context (1868) warning: constant in conditional context (1874) warning: constant in conditional context (1888) warning: constant in conditional context (1889) warning: constant in conditional context (1949) warning: constant in conditional context (1955) warning: constant in conditional context (1958) warning: constant in conditional context (1994) warning: cast from 64-bit integer to 32-bit integer (2009) warning: constant in conditional context (2140) warning: constant in conditional context (2143) warning: constant in conditional context (2167) warning: assignment of 64-bit integer to 32-bit integer (2173) warning: constant in conditional context (2177) warning: constant in conditional context (2184) warning: argument #3 is incompatible with prototype: prototype: pointer to unsigned long : "ltdl.c", line 2125 argument : pointer to int (2191) warning: assignment of 64-bit integer to 32-bit integer (2195) warning: constant in conditional context (2218) warning: constant in conditional context (2219) warning: constant in conditional context (2220) warning: constant in conditional context () warning: constant in conditional context (2251) warning: constant in conditional context (2502) warning: assignment of 64-bit integer to 32-bit integer (2505) warning: constant in conditional context (2532) warning: constant in conditional context (2533) warning: constant in conditional context (2534) warning: constant in conditional context (2535) warning: constant in conditional context (2557) warning: constant in conditional context (2574) warning: constant in conditional context (2611) warning: constant in conditional context (2643) warning: comparing 32-bit integer with 64-bit integer (2664) warning: constant in conditional context (2668) warning: constant in conditional context (2701) warning: constant in conditional context (2718) warning: passing 64-bit integer arg, expecting 32-bit integer: fgets(arg 2) (2728) warning: passing 64-bit integer arg, expecting 32-bit integer: fgets(arg 2) (2794) warning: constant in conditional context (2803) warning: constant in conditional context (2813) warning: constant in conditional context (2838) warning: constant in conditional context (2881) warning: constant in conditional context (2888) warning: constant in conditional context (2893) warning: constant in conditional context (2895) warning: constant in conditional context (2898) warning: constant in conditional context (2901) warning: constant in conditional context (2904) warning: constant in
Re: libltdl crashes under Solaris LP64 64-bit model
On Sun, 30 Sep 2001 [EMAIL PROTECTED] wrote: > On Sat, Sep 29, 2001 at 10:56:13PM -0500, Bob Friesenhahn wrote: > > The problem with libltdl in the Solaris LP64 64-bit model is due to a > > mismatch with sizes. argzize_path requires size_t. Under 64-bits > > size_t is 8 bytes and int is 4 bytes. Here is a patch which should > > resolve the problem. > > Then why not make argz_len size_t? Nothing else in foreach_dirinpath > uses argz_len so it would seem more correct. Yes, the type should be size_t. We changed this for ImageMagick's copy of libltdl, but I didn't want to annoy the list with something the maintainers would see right away. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
C++ exceptions fail, CVS libtool, gcc 3.0.1, Solaris 2.6
ImageMagick has been using CVS libtool. With gcc 2.95.2, C++ exceptions work fine under Solaris 2.6. With gcc 3.0.1, C++ exceptions are not being caught, causing the program to core dump. Has anyone else seen this problem? Is it due to libtool? Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: C++ exceptions fail, CVS libtool, gcc 3.0.1, Solaris 2.6
On Thu, 4 Oct 2001 [EMAIL PROTECTED] wrote: > > Has anyone else seen this problem? Is it due to libtool? > > Have you tried generating a small test program with exceptions to > determine if GCC is the culprit? I cannot imagine anything inherent in > libtool that would cause a problem. Are both versions of GCC built the > same (i.e. with GNU as/ld)? Both versions use Solaris 'as' and Solaris 'ld'. Tests with simple exceptions in a small stand-alone program show that exceptions do work. A somewhat larger test program crashes in libstdc++ (libsupc++/vec.cc:52) so perhaps this is a compiler library issue unrelated to libtool. Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
More on C++ exception failure with gcc 3.0.1
This is a followup to my previous complaint that exceptions were not working with CVS libtool, SPARC Solaris 2.6, and gcc 3.0.1. I suspect that this may be due to a compiler bug. I performed a trivial C++ exception test to see if exceptions were working. I compiled the test by handl. The test worked. I then included the library headers from my package, and the test still worked. A more sophisticated test in which I threw an exception from a function failed to work. Reports this: Program received signal SIGSEGV, Segmentation fault. 0xeed6e274 in ?? () at /home/bfriesen/src/gnu/gcc-3.0.1/libstdc++-v3/libsupc++/vec.cc:52 from /usr/local/lib/libstdc++.so.3 52 uncatch_exception::uncatch_exception () It doesn't seem that any code in the method was executed. The title on the top of this source module is "New abi Support". Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
CVS libtool --silent is ignored
CVS libtool ignores the --silent option when linking programs, and when installing modules: /bin/sh ../libtool --silent --mode=link gcc -g -O2 -mcpu=ultrasparc -Wall -Wall -L/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib -o composite -L/usr/local/lib -L/usr/local/lib -R/usr/local/lib -L/usr/local/lib -L/usr/local/lib -L/usr/openwin/lib -R/usr/openwin/lib -export-dynamic composite.o ../magick/libMagick.la ../ltdl/libltdlc.la source='/home/bfriesen/src/graphics/ImageMagick/utilities/convert.c' object='convert.o' libtool=no \ depfile='.deps/convert.Po' tmpdepfile='.deps/convert.TPo' \ depmode=gcc3 /bin/sh /home/bfriesen/src/graphics/ImageMagick/depcomp \ gcc -DHAVE_CONFIG_H -I. -I/home/bfriesen/src/graphics/ImageMagick/utilities -I../magick -I../ -I/home/bfriesen/src/graphics/ImageMagick -I/home/bfriesen/src/graphics/ImageMagick/libltdl -I/usr/openwin/include -I/usr/local/include/freetype2 -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/local/include -I/usr/openwin/include -I/usr/openwin/include/X11 -g -O2 -mcpu=ultrasparc -Wall -Wall -c `test -f /home/bfriesen/src/graphics/ImageMagick/utilities/convert.c || echo '/home/bfriesen/src/graphics/ImageMagick/utilities/'`/home/bfriesen/src/graphics/ImageMagick/utilities/convert.c /bin/sh ../libtool --silent --mode=install /usr/local/bin/install -c art.la /usr/local/lib/ImageMagick/modules/coders/art.la libtool: install: warning: relinking `art.la' gcc -shared -Wl,-h -Wl,art.so -o .libs/art.so .libs/art.o -R/usr/local/lib -R/usr/openwin/lib -L/usr/local/lib -L/usr/openwin/lib -lMagick -lc -- Libraries have been installed in: /usr/local/lib/ImageMagick/modules/coders If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - use the `-RLIBDIR' linker flag See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------- == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
CVS libtoolize is broken
When CVS libtoolize is used, this problem occurs:
% libtoolize --copy --force
You should update your `aclocal.m4' by running aclocal.
cp: cannot access /usr/local/share//config.guess
libtoolize: cannot copy `/usr/local/share//config.guess' to `config.guess'
cp: cannot access /usr/local/share//config.sub
libtoolize: cannot copy `/usr/local/share//config.sub' to `config.sub'
cp: cannot access /usr/local/share//ltmain.sh
libtoolize: cannot copy `/usr/local/share//ltmain.sh' to `ltmain.sh'
This is because pkgdatadir ends up being defined as
pkgdatadir=${datadir}/
rather than
pkgdatadir=${datadir}/libtool
The problem is that ${PACKAGE} is not defined in configure.ac:
pkgdatadir='${datadir}'"/${PACKAGE}"
AC_SUBST([pkgdatadir])
This is due to the removal of the line
AM_INIT_AUTOMAKE(libtool, 1.4c)
when going from revision 1.5 to 1.6.
This should be fixed ...
Bob
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: CVS libtoolize is broken
By the way, I have attached a patch to resolve this particular
problem. There is also a warning emitted from configure that someone
should look at.
Bob
Index: configure.ac
===
RCS file: /home/cvs/libtool/configure.ac,v
retrieving revision 1.6
diff -u -r1.6 configure.ac
--- configure.ac2001/10/06 15:35:17 1.6
+++ configure.ac2001/10/29 00:03:50
@@ -52,7 +52,7 @@
## --- ##
## Libtool specific configuration. ##
## --- ##
-pkgdatadir='${datadir}'"/${PACKAGE}"
+pkgdatadir='${datadir}'"/AC_PACKAGE_TARNAME
AC_SUBST([pkgdatadir]) # automake does not need this, but libtoolize does
aclocaldir='${datadir}/aclocal'
Index: ChangeLog
===
RCS file: /home/cvs/libtool/ChangeLog,v
retrieving revision 1.1075
diff -u -r1.1075 ChangeLog
--- ChangeLog 2001/10/28 12:22:38 1.1075
+++ ChangeLog 2001/10/29 00:03:51
@@ -1,3 +1,7 @@
+2001-10-28 Bob Friesenhahn <[EMAIL PROTECTED]>
+
+* Fix pkgdatadir definition.
+
2001-10-28 Gary V. Vaughan <[EMAIL PROTECTED]>
From Tom Bates <[EMAIL PROTECTED]>:
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
On Mon, 19 Nov 2001, Bruno Haible wrote: > 3) Introduce a libintl-config script that sets outputs the right -L and >-rpath option. Most packages appear to select this option. Unfortunately it is often worse than useless because it only works in the most simplistic case --- the case where the application only uses that one library. As soon as more than one *-config script is used to obtain -I, -L, and -l options, things blow up since the combination of path options often selects the wrong files, and the libraries may be linked in the wrong order. What is needed is a "database" which acts as a registry of installed packages. This would be updatable by 'make install' as well as binary packaging tools. A tool would be provided to formulate the optimum -I, -L, and -llibs options required to build using a set of libraries. The database would need to be distributable across multiple prefixes in order to handle the case where libraries are provided by the system, installed to a common local directory, and installed in a private directory. Bob ========== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
On Mon, 19 Nov 2001, Paul Davis wrote: > >What is needed is a "database" which acts as a registry of installed > >packages. This would be updatable by 'make install' as well as binary > >packaging tools. > > all of GNOME is now using pkg-config for this purpose. > > >A tool would be provided to formulate the optimum > >-I, -L, and -llibs options required to build using a set of libraries. > > pkg-config doesn't do that. its an almost impossible task unless you Are you talking about some new tool that I had not previously heard about or are you talking about a script like the '/usr/local/bin/gnome-config' I see on my system? If the latter, then that is the type of trivial *-config script that I described as being totally useless to configure a large package that needs to use options from several (or many!) of these scripts. If this works for gnome; a tightly controlled environment; then that's great. It doesn't work in the general case though. In the general case there is no feedback loop to resolve problems as there is in a project like gnome. Unfortunately gtk standardized this type of script through proliferation. The proliferation occured because no other option was offered. It's mere popularity does not make it the right solution. The scripts options do not even align with Autoconf since Autoconf distinguishes options with finer granularity than the *-config scripts do: *-config Autoconf === --libsLDFLAGS + LIBS --cflags CPPFLAGS + CFLAGS The munging of LDFLAGS and LIBS to create the output from the --libs option creates a bloody mess when you try to blend these options together. Linker directory search order and library link order are totally lost if a simple concatenation of options is used. The only proper solution is one based on a rules database in which the dependency requirements for each package can be expressed so that the dependencies can be reliabily satisified by the build environment. Libtools .la files do not provide this database. Pkg-config scripts do not provide this database. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: use of libtool for linking executables - rpath problem
On 19 Nov 2001, Russ Allbery wrote: > Rob Browning <[EMAIL PROTECTED]> writes: > > > The problem I'm talking about is if Makefile.am's use > > > LDFLAGS = `gnome-config --libs foo` `foo-config --libs bar` > > > then if you've got a normal gnome-dev package installed, such that > > it's libs are in /usr/lib, it will (or at least it used to) put > > -L/usr/lib into LDFLAGS ahead of whatever foo-config specifies. > > This is a bug in the packaging that should be reported to your > distribution. Under no circumstances should /usr/lib, /usr/include, and > other such default paths be included in the configured link or compile > flags, and the packager needs to fix them if they are. Remember that there are still many of us who have not adopted Linux or some other system where pre-compiled packages are preferred. We actually compile packages from sources on our systems. There is no one responsible for how an application is installed on our system other than the application developer, and the options we (the end user) choose. How is the application developer to know which directories are searched by default? The tools used may not even be consistent. For example, the compiler may look in /usr/local automatically, but the system linker does not. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Turn off warning when installing modules?
Is there a good way to turn off the usage message that gets displayed every time a module is installed by libtool? This usage message is useful for normal shared libraries, but is not useful for loadable modules. Thanks, Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: GNU libtool 32/64-bit Support
On Wed, 10 Oct 2001, Torok-1, Maria wrote: > We're currently using GNU libtool v1.4 on Solaris 2.6, but are preparing to > upgrade to Solaris 8. Can you please tell me if you provide a 32-bit and > 64-bit version of libtool and for how long you plan on supporting them? Libtool itself is a script so it does not care about 32-bit or 64-bit. The libltdl component is compiled so it does care. The development version of libltdl is currently not 64-bit bit safe. A patch was submitted to this list, but it has not been applied yet. Using the patch, ImageMagick has been shown to work properly under Solaris 8 when compiled as 32-bit or 64-bit. The patch simply makes libltdl POSIX-compliant. Libtool is not commercial software (although you may be able to purchase commercial support). Based on experience with other open source packages, it is safe to say that it will be supported for as long as it remains actively in use on your chosen operating system. If you send it to Mars, then it will be supported longer. :-) Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool CVS permanently broken?
I assume that libtool is currently a "dead" project since libtool CVS has not been updated in weeks, but could the contents of CVS at least be left in a functional state before allowing libtool to die? Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool CVS permanently broken?
On Thu, 3 Jan 2002, Robert Boehne wrote:
> Bob Friesenhahn wrote:
> >
> > I assume that libtool is currently a "dead" project since libtool CVS
> > has not been updated in weeks, but could the contents of CVS at least
> > be left in a functional state before allowing libtool to die?
>
> I use it every day. It hasn't had any checkins for awhile because
> it works so well. Are you trying to report a bug? (note, extreme
> sarchasm ;)
I assumed that the problems would be immediately self-evident to
anyone who checked libtool out of CVS and attempted to use it:
% ./bootstrap
autoheader: config-h.in is unchanged
Can't call method "close" on an undefined value at /usr/local/bin/automake line 7751.
% ./configure
configure: loading site script /usr/local/share/config.site
=
Configuring libtool 1.4c (1.1085 2001/12/06 19:34:36)
=
checking for a BSD compatible install... /usr/local/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
./configure: syntax error at line 1504: `(' unexpected
%
% autoconf --version
autoconf (GNU Autoconf) 2.52
% automake --version
automake (GNU automake) 1.5
% perl --version
This is perl, v5.6.1 built for sun4-solaris
==
Bob Friesenhahn
[EMAIL PROTECTED]
http://www.simplesystems.org/users/bfriesen
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool CVS permanently broken?
It looks like the aborted configure run I was seeing was due to an update I made to configure.ac to try to get 'make dist' to actually work. My update was missing a quote. Sorry about that. The automake warning/error remains. Bob ====== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
still can't build libtool
Using the exact files from libtool CVS, and the current released autoconf and automake, I get this error at the 'make' stage: Making all in libltdl gmake[1]: Entering directory `/home/bfriesen/src/gnu/libtool/libltdl' gmake[1]: *** No rule to make target `@MAINTAINER_MODE_TRUE@', needed by `Makefile'. Stop. gmake[1]: Leaving directory `/home/bfriesen/src/gnu/libtool/libltdl' gmake: *** [all-recursive] Error 1 Ideas? Bob ========== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: still can't build libtool
On Sat, 5 Jan 2002, Albert Chin wrote: > > Ideas? > > I just did the following (Solaris 8/SPARC): > > $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/libtool login > $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/libtool co libtool [etc] > No problems. What procedure are you using? Same, except that my CVS root was set to :pserver:[EMAIL PROTECTED]:/home/cvs, as it has been for quite some time. Also (and most importantly) I have been working from an already-checked out directory, and just did a 'cvs update'. After doing a fresh CVS checkout, things work just fine. Sorry for all the bother and for being a PITA. Bob ========== Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool versioning
On Sun, 2 May 2010, Jef Driesen wrote: I'm trying to understand the libtool current:revision:age versioning scheme. I think I understand how it works, but I noticed that filename of the shared library seems to get different numbers (current-age.age.revision). Is that expected? The filename generation is dependent on the OS. It is usually best not to pay any attention to the filenames at all unless you are switching from some other existing numbering scheme and need to avoid a collision. I keep these notes in my configure script (taken from various libtool related documentation) so that I remember how things work: # Libtool library revision control info # See the libtool documentation under the heading "Libtool's versioning # system" in order to understand the meaning of these fields # # current # The most recent interface number that this library implements. # revision # The implementation number of the current interface. # age # The difference between the newest and oldest interfaces that # this library implements. In other words, the library implements # all the interface numbers in the range from number current - # age to current. # # Here are a set of rules to help you update your library version # information: # # 1. Start with version information of `0:0:0' for each libtool library. # 2. Update the version information only immediately before a public # release of your software. More frequent updates are unnecessary, and # only guarantee that the current interface number gets larger faster. # 3. If the library source code has changed at all since the last update, # then increment revision (`c:r:a' becomes `c:r+1:a'). # 4. If any interfaces have been added, removed, or changed since the last # update, increment current, and set revision to 0. # 5. If any interfaces have been added since the last public release, then # increment age. # 6. If any interfaces have been removed since the last public release, # then set age to 0. One of the reasons why I would like to know the filename is that I'm also building a Windows DLL (it's a cross platform library) where I would like to include a version resource. And one of the fields in a Windows version resource is the "OriginalFilename". It seems that dlls get filename libfoo-x.dll, where x is the number current-age. Is that correct? It is true that Windows does not support useful versioning and is not able to select among DLLs based on an interface version. It seems that your analysis is correct. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning
On Mon, 3 May 2010, Jef Driesen wrote: # 6. If any interfaces have been removed since the last public release, # then set age to 0. Shouldn't step #6 included "changed" as well as "removed"? If you change the interface (for example modifying function parameters), backwards compatibility is broken too. But only "removed" is listed here. Yes, "changed" is the same as "removed". Square blocks don't fit in round holes. Increment current and set age to 0. Changing an interface is a big deal. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool versioning
On Mon, 3 May 2010, Matěj Týč wrote: If I have understood correctly, the whole LTversion stuff has only one purpose - to inform users what have they installed. More specifically, it provides libtool with the information needed to produce a suitably numbered library to satisfy a purpose. As you say, libtool does not provide control over which versions of libraries are consumed in a link since only the current version in the linker search path, or the version indicated by a .la file, gets used. I don't think that this makes libtool useless by any means. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.7b released (2.2.8 release candidate).
On Sat, 22 May 2010, Gary V. Vaughan wrote: Is the problem due to Windows searching for DLLs along $PATH? And, if so, do you know whether the current directory is always searched first irrespective of the PATH setting? Yes, Windows uses PATH equivalently to LD_LIBRARY_PATH except that it does always search the directory containing the executable first. I don't remember when the current directory is tried, and it may depend on the version of Windows. When tests are run, the current directory is rarely the directory containing the DLLs. Windows Vista 64 bit and Windows 7 add additional new rules (related to manifests) that we will start needing to worry about. The problem is not fixed yet as far as I am aware. It certainly plagues GraphicsMagick. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Building shared libraries at configuration time
On Tue, 1 Jun 2010, Ludovic Courtès wrote: Hello, GNU Guile relies on TLS (thread-local storage) support where available, and can live without it on inferior systems. However, I haven’t found a reliable way to check whether TLS is supported. Why aren't you using the POSIX TLS APIs? That is what my software uses and I have not encountered any difficulties across a broad span of platforms. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Building shared libraries at configuration time
On Tue, 1 Jun 2010, Ludovic Courtès wrote: On Tue, 1 Jun 2010, Ludovic Courtès wrote: Hello, GNU Guile relies on TLS (thread-local storage) support where available, and can live without it on inferior systems. However, I haven’t found a reliable way to check whether TLS is supported. Why aren't you using the POSIX TLS APIs? Because using __thread allows you to choose a more efficient TLS model without changing your code (see <http://people.redhat.com/drepper/tls.pdf>), and because it requires less initialization-related code. I can see why this ELF-based TLS extension is attractive (especially when updating old code) but it seems wrong for portable software like guile to be using it and therefore penalizing standard environments which don't support it. It seems best reserved for OS-specific libraries which have no need to be portable. Operating systems and compilers not supporting this non-standard extension are not 'inferior' because it is a non-standard extension. If they fail to implement a standard interface then they can be called 'inferior'. You will likely find that 'valgrind' is not particularly friendly or helpful to diagnose memory problems in applications using this extension. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.8 released (stable)
On Tue, 8 Jun 2010, Gary V. Vaughan wrote: More interesting still: I think things might blow up if the .la files have been removed on a platform that does automatic deplib loading for runtime linking, say lt_dlopening libpng.dll (which pulls in zlib through LoadLibrary without libltdl knowing about it), and then the application tries to lt_dlopen libz.dll. It then depends on whether the underlying LoadLibrary implementation is smart enough to realise that it already has a copy of libz in memory and returns a handle to it without trying to reload another copy first... this would be an interesting test to have in the next release to see what feedback it brings. Obviously this is already working fine. Windows LoadLibrary() is smart enough to know what it has already loaded. The unloading sequence is much more interesting since something could be unloaded which is still being used. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.8 released (stable)
On Tue, 8 Jun 2010, Charles Wilson wrote: If it doesn't, then that's a bug. Libltdl is supposed to keep track of everything it loads, But the point here is that Bob is advocating that (in the first half of the example above) *libltdl* does NOT explicitly load the libjpeg dependency. However, the Windows *will* load it "behind the scenes" and automatically, when libltdl does a LoadLibrary(libtiff) because libtiff depends on libjpeg. Once Windows has done so, and THEN libltdl attempts to do a LoadLibrary(libjpeg) -- when libjpeg has already been "privately" loaded, unbeknownst to libltdl -- what happens? As a useful data point, when GraphicsMagick gets built using Visual Studio, libltdl is not used. Instead a more simple loader based on LoadLibrary() is used and Windows automatically loads any dependendencies. This has not caused any problems that I can recall. In the MinGW and Cygwin builds of GraphicsMagick, libldtl does get used so libltdl's redundant dependency loading is active. I assume that in this case, libltdl's loader ends up taking precedence over Windows similar features since it is invoked first. Windows surely still loads some implicit DLLs that libltdl is not aware of. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.8 released (stable)
On Tue, 8 Jun 2010, Gary V. Vaughan wrote: Obviously this is already working fine. Windows LoadLibrary() is smart enough to know what it has already loaded. The unloading sequence is much more interesting since something could be unloaded which is still being used. Looks like another interesting test case for 2.2.10 to me :) Do you feel motivated to write it? Or at least add a description to the TODO file in the tests directory? This seems more like a test of the OS than it would be of libltdl. We already know that libltdl does not normally *have* to explicitly load all of the dependencies in order for a program to run, but it is possible that the .la files contain some knowledge of library locations that Windows does not have. Without the smarts added by the .la files, we become dependent on Windows default DLL search algorithms, which could potentially find a similarly named library in some other location. For example, the Windows default search algorithm might require that the DLLs be in the executable search PATH, but LoadLibrary() is able to load a DLL via an explicit filesystem path (outside of the Windows search PATH) as well so paths in the .la file do add value. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GNU Libtool 2.2.8 released (stable)
On Wed, 9 Jun 2010, Gary V. Vaughan wrote: M4 master, for example, has had to simply turn off all the libltdl/OS run-time loader path searching to maintain any cross platform sanity (it does this by managing it's own search path environment variable, making the searches itself and then always passing fully qualified paths to libltdl). That sort of functionality seems like it should really be in libltdl, which is supposed to help with this kind of thing. GraphicsMagick does the same, but this is actually a blessing since it makes it easy to stop using libltdl if need be. :-) Most would agree that libltdl includes too many features that nobody uses, but can bite you in the ass if you fail to pay attention. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: [RFC] [PATCH] libltdl error reporting
On Thu, 10 Jun 2010, Peter O'Gorman wrote:
As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like "file not found" where the actual
problem might be something completely different, and a reasonable error
string may be readily available from dlerror().
As we have known for quite a while now, libltdl's error reporting is
not sane. For example, the preloader always issues a useless error
("file not found") when preloading is not used for the module. Since
the loaders were nicely modularized, each loader is tried in turn
(issuing an error on failure) until a loader is successful, or there
are no more loaders. This is perhaps worse on OS-X where there are
two OS APIs for loading modules. I think that some improvements were
made, but functionality is still lacking.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: [sr #107416] relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR
On Fri, 2 Jul 2010, Tim Mooney wrote: This issue affects all versions of libtool from 2.2.10 going back to the initial versions that added support for DESTDIR installs. This does not seem to be a libtool bug: % grep DESTDIR libtool % Since libtool does not handle DESTDIR, then it must be the responsibility of a higher-level, such as the makefile. If you are using Automake, maybe there is a deficiency in your project's Makefile.am, or even Automake itself. There is a known Automake bug in that libraries need to be listed in a particular order so that old installed libraries won't be used by mistake. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: hpux linking shared library with static library
On Wed, 14 Jul 2010, Alon Bar-Lev wrote: Thank you! But I do link the static library as PIC. Even if the static library is PIC, and the OS is happy to load and run the result, there is a common problem with this approach since if more than one shared library is linked with the static library, and these two shared libraries are used in the same program, there are likely to be duplicate symbol conficts or semi-random operation. The problem becomes worse if multiple versions of the static library were used. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Thread-safety "guidelines" of LTDL
On Wed, 11 Aug 2010, Andreas Mohr wrote: Hello, I've been reading "Using libltdl in a multi threaded environment" at http://www.gnu.org/software/libtool/manual/html_node/Thread-Safety-in-libltdl.html#Thread-Safety-in-libltdl and I must say I feel that it's rather misguided. I'm as threading-resistant as anyone *) , but IMHO suggesting the use of ugly, contention-hampered, __insufficient__ mutexes to make LTDL "thread-safe" in an external manner is too short-sighted. Assuming that we agree with most of your points, would it not be sufficient to implement libltdl as a singleton model where each "user" requests a handle, and accesses via this handle access a single actual instance of libltdl in a thread-safe (i.e. mutex protected) way? This approach seems to avoid needing to radically modify libltdl. This approach should also not hinder performance much since dlopen(), dlsym(), and friends already need to include locking in order to be thread safe. As for myself, I am not at all "threading-resistant" and have yet to see the horrors occur which were forecast by others when I first started to use threading in 1996. There is no doubt that such horrors are possible absent proper design. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Link Time Optimization
On Wed, 25 Aug 2010, Nick Bowler wrote: http://www.andrew.cmu.edu/user/qralston/writing/tagging-harmful/ for details. Everything sent by this mailing list has the header: X-BeenThere: libtool@gnu.org which can be used to filter mails from the list. For example, I use the following procmail recipe: :0 * ^X-BeenThere:.*libt...@gnu.org libtool/ which puts all the mails from this list into the 'libtool' mailbox. You might as well send the mail to /dev/null since that is how it would be treated. Maybe some mail programs are able to monitor many tens of individual inboxes but most don't. My life would be considerably improved if [libtool] appeared in the subject line. All of the non-GNU lists I am on include the list name in the subject line. It may be that for some people here, libtool is essentially a full-time occupation, but that is not the case for me. When one participates in a conversation, mails addressed directly from the sender to you would fail to be filtered, leading to an incomplete communication flow in the default inbox. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Anything remaining to hold up the August release I promised?
On Wed, 1 Sep 2010, Ralf Wildenhues wrote: Hello Gary, * Gary V. Vaughan wrote on Wed, Sep 01, 2010 at 10:00:20PM CEST: Unless there are any unmerged patches or unresolved issues to bring to my attention, I'll make a new libtool release from the HEAD of master branch this coming weekend (September 5th). I haven't pushed the new small LTO patch series yet. The 72 hours are over. Anybody want to review (or reject) it before I push? While I doubt that I am qualified to review the patch, I am definitely interested in seeing autotools fully support LTO. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Anything remaining to hold up the August release I promised?
On Thu, 2 Sep 2010, Ralf Wildenhues wrote: While I doubt that I am qualified to review the patch, I am definitely interested in seeing autotools fully support LTO. Can you try out the patch series, ideally on something other than GNU/Linux? If it helps you, I can push the branch I have it on. First I would need to build a GCC which properly supports LTO. Pushing the branch to head would certainly make it easier to test. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Gary V. Vaughan wrote: I'm planning to make the belated 2.4 release in about 24 hours. Yesterday I ran the libtool test suite on various machines here. The test suite performed quite well (better than a week or two ago) on Solaris 10 x86 & SPARC, FreeBSD 8.0, and OS-X Leopard PPC. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Gary V. Vaughan wrote: Hi Bob, On 19 Sep 2010, at 21:41, Bob Friesenhahn wrote: On Sun, 19 Sep 2010, Gary V. Vaughan wrote: I'm planning to make the belated 2.4 release in about 24 hours. Yesterday I ran the libtool test suite on various machines here. The test suite performed quite well (better than a week or two ago) on Solaris 10 x86 & SPARC, FreeBSD 8.0, and OS-X Leopard PPC. That's great news! Thanks for testing :) Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Ralf Wildenhues wrote: * Bob Friesenhahn wrote on Sun, Sep 19, 2010 at 05:45:45PM CEST: Unfortunately, my MinGW testing is not so successful. The testing still quits part-way through with some sort of make-related issue (as reported in detail previously). I don't have that previous report on my radar. Can you point us to it, please? This is the situation where the tests quit mid-way like this: PASS: tests/depdemo-shared-unst.test make[4]: *** No rule to make target `.log', needed by `test-suite.log'. Stop. make[4]: Leaving directory `/home/bfriesen/mingw/libtool-head' make[3]: *** [check-TESTS] Error 2 make[3]: Leaving directory `/home/bfriesen/mingw/libtool-head' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/bfriesen/mingw/libtool-head' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/bfriesen/mingw/libtool-head' make: *** [check] Error 2 I am not finding this posted to a libtool list so it was probabably in off-list discussion among libtool core developers. The above is produced today after re-installing MinGW/GCC using the latest TDM GCC installer (with GCC 4.5.1). It is similar to what I observed before. The test suite used to work so I assume that the issue is due to some change in the past few months, such as in Automake. There are no autotools installed in this MinGW installation. Libtool is bootstrapped on a Solaris system. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Ralf Wildenhues wrote: The above is produced today after re-installing MinGW/GCC using the latest TDM GCC installer (with GCC 4.5.1). It is similar to what I observed before. The test suite used to work so I assume that the issue is due to some change in the past few months, such as in Automake. Yeah, this is a GNU make 3.80 bug exposed by Automake 1.11, fixed by Automake 1.11.1, and re-exposed in git Automake (I am working on a fix that tries to avoid this and another bug about long $(TESTS) on MinGW). The 'make' used is GNU make 3.79.1. There is a 'mingw32-make' which is GNU make 3.82, but does not seem to work under MSYS. This is what happens: $ mingw32-make mingw32-make: *** No rule to make target `/uhome/src/gnu/libtool-head/Makefile.am', needed by `/uhome/src/gnu/libtool-head/Makefile.in'. Stop. I tried building my own GNU make 3.82 under MinGW and the result behaves the same as 'mingw32-make'. The timestamps of the files show that no work should be performed but it seems like the target dependency has been reversed. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Ralf Wildenhues wrote: The 'make' used is GNU make 3.79.1. Yeah, that has the same bug. There is a 'mingw32-make' which is GNU make 3.82, but does not seem to work under MSYS. That one's not for you, normally. IIUC it's for the development of, not with, MSYS. It is not an 'msys' application since it is delivered with the MinGW compiler rather than with 'msys'. As such, it must be a "native" application similar to my own attempt to build a working 'make'. I am curious to know what is causing the libtool test suite to work for other people using "MinGW" (a continually evolving/varying environment) and not for me. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Sun, 19 Sep 2010, Charles Wilson wrote: Odd. My last test on MinGW was very successful. This was version 1.3266 (ef56e98f3 IIRC). I'll give it another go @ f0584085. MinGW/MSYS: old -- All 122 tests passed (2 tests were not run) new -- 108 tests behaved as expected. 12 tests were skipped. With Charles Wilson's assistance, I updated my MinGW environment to the latest, but using the latest TDM GCC 4.5.1 compiler (only C & C++ supported). These were the results: ERROR: 102 tests were run, 6 failed (4 expected failures). 18 tests were skipped. The test which failed (twice) was the C++ exception handling test. Similar tests also failed in the GraphicsMagick test suite so it seems that C++ exceptions are unreliable with this compiler. As a side note, I find that the GNU make delivered with current MinGW is at least 60X slower than before. It takes GNU make 2.5 minutes before it does any actual work (while building GraphicsMagick), which represents most of the compilation time with the previous make. A one-year old Cygwin make takes maybe 1.5 seconds to start working when given the same environment. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: 2.4 Release in 24hrs
On Mon, 20 Sep 2010, Ralf Wildenhues wrote: I'd really appreciate if you guys could send build logs to the autobuild server as I've been doing lately, much more than just posting non-verbose results on the list here. You don't need to have autobuild installed. When Eric installs autobuild.m4 you don't need to do anything else. No autobuild.m4 here. Only heard mention of it in the past couple of days. I don't know what it is. $sanitize logfile mail libtool_autobuild.josefsson.org < logfile Most systems I test on have no email access. Certainly I would not trust a Windows PC dedicated to testing with the ability to send email. Shouldn't there be a username component to that email address? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool and LTO
On Mon, 4 Oct 2010, Andi Kleen wrote: I discovered that libtool breaks gcc LTO (link time optimization) Is there a solution or a workaround known? I'm using libtool 2.2.6b Maybe you should use libtool 2.4? I believe that this includes fixes by Ralf Wildenhues for -flto but if you are using Automake I have heard that there are some fixes in development Automake which are needed/useful for -flto. I am interested in trying LTO for myself. :-) Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -xc99=all and libraries on Solaris 10
On Sun, 26 Dec 2010, Bruno Haible wrote: Hi, Reviving an old thread from February 2010. In <http://lists.gnu.org/archive/html/autoconf/2010-02/msg00013.html> Peter O'Gorman wrote: When creating a library or application with c99 or cc -xc99=all /usr/lib/values-xpg6.o is included in the output, this object file contains the c99 definitions for __xpg4 and __xpg6. When creating output without c99/-xc99=all this extra object is not put into the output and the values of __xpg4 and __xpg6 in libc (c89 behavior) are used (because they are the only definitions available). I confirm with a test program. Bruno, This topic is currently discussed on the autoconf list. It seems to me that it has implications for libtool as well. I think that this is a very similar issue to how pthreads are handled (and which libtool now accounts for). The issue for libtool is if it should remember if /usr/lib/values-xpg4.o or /usr/lib/values-xpg6.o needs to be included in the output (via a library .la file). There is also the issue that c99-linked code should (ideally) not be mixed with older code. All code should be compiled and linked at the same 'xpg' level in order to assure original consistent operation. GNU's desire to promote the latest standards results in older already-installed libraries behaving differently than they originally did after a newer library is added. Due to this, I am Cc:ing the libtool list in this reply. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: linkat, LINK_FOLLOWS_SYMLINKS, and Solaris
On Mon, 27 Dec 2010, Bruno Haible wrote:
This is not realistic: People are not distributing libraries in this
way, and are not even aware for which standard a library was built
and tested for. ("file libfoo.so" does not tell. You need
"nm libfoo.so | grep values".)
Since it seems that evidence of built type is stored in shared
libraries on Solaris, is it reasonable for libtool (or even GNU ld or
GCC) to inspect this data and warn about potential incompatibly at
link time?
There are of course many other types of subtle incompatiblies which
may occur when linking libraries.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool library used but `LIBTOOL' is undefined??
On Tue, 4 Jan 2011, kknd1233 wrote: And then when I run the command 'autoreconf --install', it said an error message like " lib/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined lib/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' lib/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. lib/Makefile.am:1: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure lib/Makefile.am:1: its definition is in aclocal's search path. " Could anybody please advise me how to fix the problem and run my little toy code?? Thank you! It seems that the error message has provided instructions for exactly what to do. I suggest that you do it. It is very rare that error messages tell you what to do. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: old solaris problem
On Thu, 17 Feb 2011, Thien-Thi Nguyen wrote: In the GNU Serveez configure.ac, i see: dnl dnl Check if libtool copes with SunOS/Solaris. GNU libtool 1.4.2 and less dnl fail to create self-contained shared libraries. This is due to the gcc dnl - native linker combination. The below macro adds the -liberty path dnl and -lgcc to the linker line if necessary. dnl SVZ_LIBTOOL_SOLARIS I recommend eliminating use of this macro. Whatever purpose it was intending to solve surely no longer exists. I use Solaris for development and have never needed anything similar to what this macro is doing. It seems likely that the developer of the macro was solving some issue with his own compiler installation. Libtool 1.4.2 was released in 2002. That is eons in libtool time. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: What makes a convenience library (use --whole-archive)?
On Tue, 7 Jun 2011, Michael Poole wrote: Some of the files in my convenience libraries have static initializers. By default, the linker discards these symbols because they are not referenced. I am trying to figure out how to keep them in an automake-driven build. Libtool "convenience" libraries are created like an archive library (using 'ar') but are not actually used like a library. Instead, whenever they are referenced as a dependency, libtool extracts all of the object files from the archive file and links them directly into the executable, just like the program's own .o files. The "convenience" library then becomes a convenient way to bundle the object files for later use. Note that this is different than linking in the normal way with an archive library because in that case, the linker selects only the objects which were actually referenced by the program. I think that this information should help considerably with understanding the issue. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library versioning
On Fri, 10 Jun 2011, Lasse Collin wrote: I'm expecting Linux style or something close to it, because according to the operating systems specific docs that I have read, Linux-like versioning *is* the right thing on those operating systems (*BSDs and HP-UX). It would make sense that Libtool would try to emulate the native behavior. It is not nice that Libtool increments the shared library major version when there's no need to do that. Libtool can emulate Linux in how it does the numbering but it is not able to change how an OS uses that numbering. There are also long-standing traditions associated with various OSs. It's not clear to me if there is any operating system that requires incrementing the major version when a new symbol is added to the library while keeping backward compatibility (that is, when you do ++current, ++age, revision=0). In this situation, Libtool does increment the major version on several operating systems, but I wonder if it is possible that it has been a misunderstanding when someone read operating system specific docs long time ago. While Linux users are used to always upgrading their libraries and applications every couple of years, the same is not true for "enterprise" commercial OSs. Due to this, it seem wise to increment current when a new interface is added. There is not much cost associated with doing things correctly (++current, ++age) for a well maintained library which does not lose/change interfaces. In this case, the older library supporting the same current-age may be deleted once the new library is installed. The applications are really what care about the library versioning. The OS is just there to help with the selection process. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Shared library versioning
On Tue, 14 Jun 2011, Lasse Collin wrote:
If I add a new public function to a library and don't modify anything
else, I should do ++current, ++age, revision=0, right? For example, if
the previous version of the library uses current:revision:age = 1:3:0,
adding a new function would make it 2:0:1. On GNU/Linux, this becomes
libfoo.so.1.0.3 -> libfoo.so.1.1.0
which is fine. On OpenBSD, GNU Libtool does
libfoo.so.1.3 -> libfoo.so.2.0
while the correct thing, according to the OpenBSD docs, would be this:
libfoo.so.1.0 -> libfoo.so.1.1
That is, revision isn't visible anywhere. The filename doesn't change if
only bug fixes have been made and the library ABI hasn't been touched
(nothing added, removed, or changed). Please read the section
"Understanding shared libraries number rules" (it's short):
http://www.openbsd.org/faq/ports/specialtopics.html
If this web page text is correct, then I agree that libtool is doing
the wrong thing for OpenBSD. But of course we should search for any
additional information and consult with relevant OpenBSD maintainers
before making any such change since FAQ text could easily be wrong.
The applications are really what care about the library versioning.
The OS is just there to help with the selection process.
Packagers care about library versions too. Incrementing the major
version means that packagers need to recompile everything that depend on
the library. It is annoying if the major version is incremented without
a reason.
The major version ("current") was certainly incremented for a reason.
It is true that if there is a sea of existing libraries which depend
on the older version of the library then there may be problems if you
attempt to relink with a newer version of the library since the linker
may bring in several versions of the same library. These issues are
highly OS dependent.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Thu, 16 Jun 2011, Vadim Zeitlin wrote: different functions (_foo vs _imp__foo). So IMO creating a static library when libtool was requested to build a DLL is never the right thing to do under Windows. And while I hesitate to call this behaviour a bug because it is clearly intentional, I'd like to see it changed because it would have saved me (and presumably others) a lot of time if libtool simply stopped with an error after giving the above message instead of valiantly but ultimately counterproductively trying to continue. In what way was libtool specifically requested to build a DLL? There are certainly cases where proceeding ahead with a static library is a viable solution. If libtool simply refuses to proceed, then many applications will fail to build and users will also be unhappy. What happens if you specify --disable-static to configure? Does that help? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re[2]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Thu, 16 Jun 2011, Vadim Zeitlin wrote: BF> BF> In what way was libtool specifically requested to build a DLL? I'm not sure about the details (please keep in mind that we're speaking about libxml2 here and not my own project) but configure[*] is passed --disable-static option and AFAIK this is handled by AM_PROG_LIBTOOL as meaning that [only] shared libraries should be built, isn't it? It does seem like falling back to building a static library when --disable-static has been specified is a bug. IOW I don't think an example when proceeding ahead is a viable solution is possible. Do you have anything concrete in mind? As it happens, GCC under MinGW and Cygwin does have an "auto-import" facility which magically allows it to work for code built with GCC. Explicit dllexport/dllimport is not needed. It does not work for MSVC and might not work if GCC is linking against a MSVC-built DLL/library. BF> If libtool simply refuses to proceed, then many applications will fail BF> to build and users will also be unhappy. Again, I don't think such change could break anything because applications that would rely on this behaviour wouldn't build even right now. I have experienced such issues before but my own application did still build and work. A library which is expected to be loaded by another program such as a DLL or loadable module would obviously be broken by static linkage. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re[3]: libtool shouldn't switch to creating static library if it can't create the shared one under Windows
On Fri, 17 Jun 2011, Vadim Zeitlin wrote: Yes, sorry, I keep forgetting about auto-import feature, I guess I'm just too accustomed to the "traditional" Windows way and have trouble accepting auto-import magic. It's true that projects using auto-import could live with falling back to a static library. But consider that auto-importing is relatively new so there should be proportionally few projects using it, hence IMHO the risk of breakage remains reasonably small. Most projects using libtool come from Unix/Linux where "auto-import" is the default so it can be seen that most projects already depend on it (and the main issue for them is to use --no-undefined so libtool will build a DLL). Primarily programs which originated under Windows (or really care about Windows) use the dllexport/dllimport facilities. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
