Problem with .lax directories
I'm getting some peculiar behavior from libtool, where it generates a .lax directory inside .libs (which I've never really seen before), and tries to symbolically link files onto themselves. Is this because I'm passing more than one 'libx11drv.la' file to it, albeit different files in different directories? Is there any way to get this to work by patching libtool? Or would we have to rename the libx11drv.la files to unique names? Can anyone fill me in on the significance of the .lax directory, or show me where to look for more info? For completeness, here's the pertinent chunk of the Makefile.am file and the output of 'make'. Thanks! John -- Makefile.am excerpt -- SOVERSION = 1:0:0 EXTRA_OBJS = \ $(top_builddir)/graphics/x11drv/libx11drv.la \ $(top_builddir)/windows/x11drv/libx11drv.la \ $(top_builddir)/tsx11/libtsx11.la lib_LTLIBRARIES = libx11drv.la libx11drv_la_LDFLAGS = -version-info $(SOVERSION) libx11drv_la_DEPENDENCIES = $(EXTRA_OBJS) libx11drv_la_LIBADD = $(EXTRA_OBJS) -- compile output -- /bin/sh ../../libtool --mode=link gcc -g -O2 -Wall -o libx11drv.la -rpath /usr/local/lib -version-info 1:0:0 x11drv_main.lo x11drv.spec.lo ../../graphics/x11drv/libx11drv.la ../../windows/x11drv/libx11drv.la ../../tsx11/libtsx11.la -lm -lutil -ldl rm -fr .libs/libx11drv.la .libs/libx11drv.* .libs/libx11drv.* gcc -shared x11drv_main.lo x11drv.spec.lo -Wl,--whole-archive ../../graphics/x11drv/.libs/libx11drv.al ../../windows/x11drv/.libs/libx11drv.al ../../tsx11/.libs/libtsx11.al -Wl,--no-whole-archive ../../graphics/x11drv/.libs/libx11drv.al ../../windows/x11drv/.libs/libx11drv.al ../../tsx11/.libs/libtsx11.al -lm -lutil -ldl-lc -Wl,-soname -Wl,libx11drv.so.1 -o .libs/libx11drv.so.1.0.0 (cd .libs && rm -f libx11drv.so.1 && ln -s libx11drv.so.1.0.0 libx11drv.so.1) (cd .libs && rm -f libx11drv.so && ln -s libx11drv.so.1.0.0 libx11drv.so) rm -fr .libs/libx11drv.lax mkdir .libs/libx11drv.lax rm -fr .libs/libx11drv.lax/libx11drv.al mkdir .libs/libx11drv.lax/libx11drv.al (cd .libs/libx11drv.lax/libx11drv.al && ar x /home/jsheets/cvs/winehq/autowine/dlls/x11drv/../../graphics/x11drv/.libs/libx11drv.al) rm -fr .libs/libx11drv.lax/libx11drv.al mkdir .libs/libx11drv.lax/libx11drv.al (cd .libs/libx11drv.lax/libx11drv.al && ar x /home/jsheets/cvs/winehq/autowine/dlls/x11drv/../../windows/x11drv/.libs/libx11drv.al) rm -fr .libs/libx11drv.lax/libtsx11.al mkdir .libs/libx11drv.lax/libtsx11.al (cd .libs/libx11drv.lax/libtsx11.al && ar x /home/jsheets/cvs/winehq/autowine/dlls/x11drv/../../tsx11/.libs/libtsx11.al) (cd .libs/libx11drv.lax/libx11drv.al && ln -s bitblt.lo bitblt.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s bitmap.lo bitmap.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s brush.lo brush.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s clipping.lo clipping.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s dib.lo dib.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s graphics.lo graphics.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s objects.lo objects.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s oembitmap.lo oembitmap.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s palette.lo palette.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s pen.lo pen.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s text.lo text.lo) (cd .libs/libx11drv.lax/libx11drv.al && ln -s xfont.lo xfont.lo) ar cru .libs/libx11drv.a x11drv_main.o x11drv.spec.o .libs/libx11drv.lax/libx11drv.al/bitblt.lo .libs/libx11drv.lax/libx11drv.al/bitmap.lo .libs/libx11drv.lax/libx11drv.al/brush.lo .libs/libx11drv.lax/libx11drv.al/clipping.lo .libs/libx11drv.lax/libx11drv.al/dib.lo .libs/libx11drv.lax/libx11drv.al/graphics.lo .libs/libx11drv.lax/libx11drv.al/init.lo .libs/libx11drv.lax/libx11drv.al/objects.lo .libs/libx11drv.lax/libx11drv.al/oembitmap.lo .libs/libx11drv.lax/libx11drv.al/palette.lo .libs/libx11drv.lax/libx11drv.al/pen.lo .libs/libx11drv.lax/libx11drv.al/text.lo .libs/libx11drv.lax/libx11drv.al/xfont.lo .libs/libx11drv.lax/libx11drv.al/clipboard.lo .libs/libx11drv.lax/libx11drv.al/event.lo .libs/libx11drv.lax/libx11drv.al/init.lo .libs/libx11drv.lax/libx11drv.al/keyboard.lo .libs/libx11drv.lax/libx11drv.al/mouse.lo .libs/libx11drv.lax/libx11drv.al/wnd.lo .libs/libx11drv.lax/libtsx11.al/ts_xf86dga.lo .libs/libx11drv.lax/libtsx11.al/ts_xf86dga2.lo .libs/libx11drv.lax/libtsx11.al/ts_xf86vmode.lo .libs/libx11drv.lax/libtsx11.al/ts_xshm.lo .libs/libx11drv.lax/libtsx11.al/ts_xlib.lo .libs/libx11drv.lax/libtsx11.al/ts_xresource.lo .libs/libx11drv.lax/libtsx11.al/ts_xutil.lo .libs/libx11drv.lax/libtsx11.al/ts_xpm.lo ar: .libs/libx11drv.lax/libx11drv.al/bitblt.lo: Too many levels of symbolic links make: *** [libx11drv.la] Error 1 -- [EMAIL PROTECTED]http://www.gnome.org [EMAIL PROTECTED] http://www.worldforge.org
Adding libtool to Wine
Hi, I'm in the process of adding libtool (and eventually automake) to Wine (http://www.winehq.com), and have a few questions about cross-platform support for a few important features that Wine needs or may need in the near future. First, Wine makes heavy use of convenience .o files, similar to convenience libraries, to gather all the single-file .o's in a directory into a single .o with 'ld -r'. However, I can't get libtool to link it properly. It seems to unconditionally convert .lo to .o, which fails if I use AC_DISABLE_STATIC. And it should! The composite .lo is later linked into a .so, which means it should use the .lo, not the .o. For now, I run these commands without libtool. Here's what I get _with_ libtool: /bin/sh ../libtool --mode=link ld -r generic.lo interface.lo ncurses.lo tty.lo xterm.lo -o console.lo /usr/bin/ld -r -o console.o generic.o interface.o ncurses.o tty.o xterm.o /usr/bin/ld: cannot open generic.o: No such file or directory make: *** [console.lo] Error 1 A related concern is the .la -> .so transition, which requires the $whole_archive_flag_spec variable. I noticed that Linux's --whole-archive and Solaris' -z allextract exist in libtool. How do other platforms fare with .a -> .so linking? I'd prefer to use .la archives, rather than the .lo ones mentioned above, but if this will paint us into a corner with future platforms, I suppose we'll have to stick with .o -> .so instead. It seems this will cause problems with automake down the line, so I'd prefer the .la solution. How does this sit with libtool and wide platform coverage? A couple future extensions Wine may (or may not) need eventually are support for -Bsymbolic, and linker scripts. As I understand it, -Bsymbolic is GNU-specific, and the option has different names on other platforms. Is this a good candidate for libtool support? How would libtool handle -Bsymbolic? Or would we have to handle it ourselves, in an autoconf check? And finally, linker scripts. I don't know much about them myself, nor how they work. Do they have anything to do with libtool? Anything we should be aware of before trying to mix libtool with our own linker scripts? Thanks a lot! I appreciate the tool, and use it wherever I can. John -- [EMAIL PROTECTED]http://www.gnome.org [EMAIL PROTECTED] http://www.worldforge.org
ml-branch: linking .lo files into programs
Hi, as in the multi-language-branch .lo files are no longer real object files as understood by linkers, the linking of programs with .lo files fails (as in 'libtool --mode=link g++ bla.lo hi.lo -o superprog'). The reason is, that *.lo arguments are not changed into the real .o files for $compile_command. The diff below fixes that by replacing the $arg in the argument parsing loop by the string for $pic_object or $non_pic_object. It has problems if both (PIC/non-PIC) objects exists for a .lo file and select the PIC variant. Well, better than nothing ;) Ciao, Michael. -- Index: ltmain.in === RCS file: /home/cvs/libtool/ltmain.in,v retrieving revision 1.200.2.12 diff -u -r1.200.2.12 ltmain.in --- ltmain.in 2000/02/28 17:51:34 1.200.2.12 +++ ltmain.in 2000/05/19 22:12:48 @@ -1253,6 +1253,7 @@ # A PIC object. libobjs="$libobjs $pic_object" + arg="$pic_object" fi # Non-PIC object. @@ -1262,6 +1263,9 @@ # A standard non-PIC object non_pic_objects="$non_pic_objects $non_pic_object" + if test -z "$pic_object" || test "$pic_object" = none ; then + arg="$non_pic_object" + fi fi else # Only an error if not doing a dry-run.
