Its FREE, check it out!
Below is the result of your form. It was submitted by ([EMAIL PROTECTED]) on Wednesday, May 22, 2002 at 04:09:33 --- :: FREE Entry! FREE Membership! Don't know how long this GREAT offer will last, but :don't miss your chance TODAY! We have BEAUTIFUL SEXY girls and they are just ONE :click away from showing you a AWESOME time! What could it hurt? Its FREE! Join us :today! http://rd.yahoo.com/dir/?http://members.lycos.co.uk/livewebcam";>Click :here --- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool and JNI libraries on Mac OS X
Don Anderson <[EMAIL PROTECTED]> writes: > I was of a libtool option: > >--moduleext=.jnilib Hi, I second that. I'm experimenting building Matlab MEX-files using Libtool and run into the same problem. At present, my Makefile.am looks as follows: # Libtool library. lib_LTLIBRARIES = libhello.la include_HEADERS = hello.h libhello_la_SOURCES = hello.h hello.c libhello_la_LDFLAGS = -no-undefined -version-info 0:0:0 # Executable program. bin_PROGRAMS = hello hello_SOURCES = main.c hello_CFLAGS = @LIBHELLO_DLL_IMPORT@ hello_LDADD = libhello.la # Matlab MEX-file. noinst_SCRIPTS = hell.$(MEXEXT) matlabarch_LTLIBRARIES = hell.la hell_la_SOURCES = hell.c hell_la_CFLAGS = @LIBHELLO_DLL_IMPORT@ -I$(MATLAB)/extern/include hell_la_LDFLAGS = -no-undefined -avoid-version -module hell_la_LDFLAGS += -export-symbols $(srcdir)/mex-symbols hell_la_LDFLAGS += libhello.la -L$(MATLAB)/bin/$(MATLAB_ARCH) -lmex -lmx -lm CLEANFILES = $(noinst_SCRIPTS) SUFFIXES = .$(MEXEXT) $(noinst_SCRIPTS): $(matlabarch_LTLIBRARIES) rm -f $@ eval `$(LIBTOOL) --config | grep '^objdir='` ; \ eval `grep '^dlname=' $*.la` ; \ $(LN_S) $$objdir/$$dlname $@ That works so far. What I miss is a Libtool option for a) Using $(MEXEXT) as the file name extension for modules. $(MEXEXT) is equal to dll on Windows but, for example, mexsol on Sun Solaris. b) Building and installing only shared objects for hell.la. There's no need to build static objects and archive libraries for modules because they can not be dlopened. I know there is a global --disable-shared option for configure but I want to have an archive library for libhello.la, too. Regards, -- Ralph ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Bug in conditional library building
Dear all, I had the following Makefile.am running generating a proper Makefile.in with automake 1.4a and libtool 1.3c UTILSRC = parser.cpp integrate.cpp MUDSRC = init.cpp linear_solver.cpp mudfas.cpp nonlinear_solver.cpp \ poisson_boltzmann.cpp poisson.cpp prolon.cpp restrict.cpp lib_LTLIBRARIES = libmudfas2d.la libmudfas3d.la libutilities.la libmudfas2d_la_SOURCES = $(MUDSRC) libmudfas2d_la_CXXFLAGS = -DDIM=2 libmudfas2d_la_LDFLAGS = -version-info 0:0:0 libmudfas3d_la_SOURCES = $(MUDSRC) libmudfas3d_la_CXXFLAGS = -DDIM=3 libmudfas3d_la_LDFLAGS = -version-info 0:0:0 libutilities_la_SOURCES = $(UTILSRC) libutilities_la_CXXFLAGS = libutilities_la_LDFLAGS = -version-info 0:0:0 which generated the following piece of Makefile.in libmudfas2d_la_LIBADD = am_libmudfas2d_la_OBJECTS = libmudfas2d_la-init.lo \ libmudfas2d_la-linear_solver.lo libmudfas2d_la-mudfas.lo \ libmudfas2d_la-nonlinear_solver.lo libmudfas2d_la-poisson_boltzmann.lo \ libmudfas2d_la-poisson.lo libmudfas2d_la-prolon.lo \ libmudfas2d_la-restrict.lo libmudfas2d_la_OBJECTS = $(am_libmudfas2d_la_OBJECTS) libmudfas3d_la_LIBADD = am_libmudfas3d_la_OBJECTS = libmudfas3d_la-init.lo \ libmudfas3d_la-linear_solver.lo libmudfas3d_la-mudfas.lo \ libmudfas3d_la-nonlinear_solver.lo libmudfas3d_la-poisson_boltzmann.lo \ libmudfas3d_la-poisson.lo libmudfas3d_la-prolon.lo \ libmudfas3d_la-restrict.lo libmudfas3d_la_OBJECTS = $(am_libmudfas3d_la_OBJECTS) libutilities_la_LIBADD = am_libutilities_la_OBJECTS = libutilities_la-parser.lo \ libutilities_la-integrate.lo libutilities_la_OBJECTS = $(am_libutilities_la_OBJECTS) Now I moved to the last official versions automake 1.6.1 and libtool 1.4.2 and I have the very unpleasant result that the generated Makefile.in does not work any longer. I get instead of what is below the following code in the Makefile.in libmudfas2d_la_LIBADD = am__objects_1 = libmudfas2d_la-init.lo libmudfas2d_la-linear_solver.lo \ libmudfas2d_la-mudfas.lo libmudfas2d_la-nonlinear_solver.lo \ libmudfas2d_la-poisson_boltzmann.lo libmudfas2d_la-poisson.lo \ libmudfas2d_la-prolon.lo libmudfas2d_la-restrict.lo am_libmudfas2d_la_OBJECTS = $(am__objects_1) libmudfas2d_la_OBJECTS = $(am_libmudfas2d_la_OBJECTS) libmudfas3d_la_LIBADD = am_libmudfas3d_la_OBJECTS = $(am__objects_1) libmudfas3d_la_OBJECTS = $(am_libmudfas3d_la_OBJECTS) libutilities_la_LIBADD = am__objects_2 = libutilities_la-parser.lo libutilities_la-integrate.lo am_libutilities_la_OBJECTS = $(am__objects_2) libutilities_la_OBJECTS = $(am_libutilities_la_OBJECTS) which results in that the mudfas3d library with the define DIM=3 is not built any longer. Any idea of what is wrong ? Sincerely, Patrick == Patrick Guio Institute of Physics, University of Oslo P.O. box 1048, Blindern, N-0316 Oslo Tel : (+47) 22 84 40 60 - Fax : (+47) 22 85 56 71 E-mail : [EMAIL PROTECTED] URL : http://folk.uio.no/~patricg ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: MacOSX and autoconf/automake/libtool
[EMAIL PROTECTED] wrote on May 16: > > Today's Topics: > >1. MacOSX and autoconf/automake/libtool (Erik de Castro Lopo) > > --__--__-- > > Message: 1 > Date: Thu, 16 May 2002 14:27:26 +1000 > From: Erik de Castro Lopo <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: MacOSX and autoconf/automake/libtool > Organization: Erik Conspiracy Secret Labs > > Hi People, > > I am the author of an LGPL library which is supposed to run on > Unix, Win32, MacOS and others. While a do have access to two > different Unixen, I do not have access to Win32 or more > importantly MacOS. > > I also run Debian and since upgrading to their Woody release > (libtool went from 1.3 to 1.4) I have been unable to generate > tarballs which compile on the latest release of MacOSX. > > It seems that libtool is not setting the right compiler flags. > > I am currently using: > >autoconf 2.13 (have also tried 2.53) >automake 1.5 (have also tried 1.4) >libtool 1.4.2a > > It seems that there is some stuff about libtool and MacOSX here: > > http://fink.sourceforge.net/doc/porting/libtool.php > > Can anybody offer any advice on how to generate a tarball that will > compile correctly on MacOSX? > > Regards, > Erik > -- I was able to build a library I could link against (a .dylib) just fine. I think you need an up to date version of OS X. On the one I tried, ./config.guess produces: powerpc-apple-darwin5.4 . I think we discovered that once we got the newer OS, libtool 1.4.2 started mostly working. If you want to create a dynamically loaded object (.so), rather than just a library you can link against (.dylib), I just learned a few more things and can offer some suggestions. First, to create a .so, you must use the libtool -module flag. That's in the libtool doc, but it isn't necessary on so many systems that it's easy to miss. Second, to get the .so's to be linked right you need the -module to actually set the -bundle flag for ld. There's a quoting problem in libtool. The symptom is: ./libtool: parse error: condition expected: xyes = [3190] I have a short patch for 1.4.2 if anyone needs it; the real fix is already in the CVS tree for libtool. Finally, if you happen to need a .jnilib (a .so that can be loadable by Java as a JNI), you need some way to produce an output file that ends in .jnilib. Libtool can't do this yet; but you can workaround in Java by using System.load() rather than System.loadLibrary(). - Don -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Don Anderson[EMAIL PROTECTED] Sleepycat Software Inc. +1-978-287-4781 118 Tower Rd. http://www.sleepycat.com Lincoln, MA 01773 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Libtool misfeature on HP-UX
ltmain.sh (GNU libtool) 1.4.2 (1.922.2.54 2001/09/11 03:33:37) Hi, I encountered a problem with Libtool libraries on HP-UX. Consider the following (simplified) Makefile.am: lib_LTLIBRARIES = libfoo.la libbar.la libfoo_la_SOURCES = foo.c libbar_la_SOURCES = bar.c libbar_la_LDFLAGS = libfoo.la When relinking libbar.la for installation, the command sequence is libtool: install: warning: relinking `libbar.la' cd /home/w3016.5/schleich/tmp/foo; /bin/sh ./libtool --mode=relink \ gcc -g -O2 -o libbar.la -rpath /usr/local/lib libfoo.la libbar_la-bar.lo /usr/ccs/bin/ld -b +h libbar.sl +b /usr/local/lib -o .libs/libbar.sl \ libbar_la-bar.lo /usr/local/lib/libfoo.sl -lc The problem is that libfoo.sl is not subject to dynamic file name lookup via the built-in library search path or SHLIB_PATH environment variable (LD_LIBRARY_PATH on HP-UX 11.00) because it has been specified as an absolute file name and *not* via a -l or -l: switch. This is a problem if you want to make a binary distribution with a different directory layout -- just setting SHLIB_PATH does not work. I propose to translate the Libtool link command on HP-UX as follows: /usr/ccs/bin/ld -b +h libbar.sl +b /usr/local/lib -o .libs/libbar.sl \ libbar_la-bar.lo /usr/local/lib/libfoo.sl -lc /usr/ccs/bin/chatr -l /usr/local/lib/libfoo.sl .libs/libbar.sl >/dev/null The chatr(1) command has the following effect: $ chatr .libs/libbar.sl .libs/libbar.sl: shared library shared library dynamic path search: SHLIB_PATH enabled first embedded path enabled second /usr/local/lib internal name: libbar.sl shared library list: static/usr/local/lib/libfoo.sl <<< *look here* dynamic /usr/lib/libc.1 [...] $ chatr -l /usr/local/lib/libfoo.sl .libs/libbar.sl .libs/libbar.sl: shared library shared library dynamic path search: SHLIB_PATH enabled first embedded path enabled second /usr/local/lib internal name: libbar.sl shared library list: dynamic /usr/local/lib/libfoo.sl <<< *look here* dynamic /usr/lib/libc.1 [...] Here is the relevant section from the chatr(1) manual page: -l library Indicate that the specified shared library is subject to run-time path lookup if directory path lists are provided (see +s and +b). Best regards, -- Ralph ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool misfeature on HP-UX
Ralph,
I would expect Libtool to translate "libfoo.la" to "libfoo.${ext}"
and to translate -lfoo into -lfoo, perhaps you should put "-lfoo"
in _LDFLAGS instead of libfoo.la.
IIRC, -lfoo -> -lfoo and libfoo.la -> libfoo.sl because sometimes
users one -lfoo, and sometimes users want libfoo.sl.
But please, correct me if I'm wrong.
Robert
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: rboehne AT ricardo-us DOT com
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool misfeature on HP-UX
"Boehne, Robert" <[EMAIL PROTECTED]> writes:
Hi Robert,
> I would expect Libtool to translate "libfoo.la" to "libfoo.${ext}"
> and to translate -lfoo into -lfoo, perhaps you should put "-lfoo"
> in _LDFLAGS instead of libfoo.la.
But "-lfoo" is not sufficient when linking against a non-installed
library (see my example). You have to add "-L.libs -L_libs -L. -lfoo"
to _LDFLAGS instead of libfoo.la. That's a step back in time before
Libtool exists.
Please read my original message again. I do not want to change the link
command. I proposed to run "chatr -l INSTALLDIR/libfoo.sl libbar.sl"
for each shared library (e.g., libfoo.sl) libbar.sl depends on and whos
name at link time is specified as a file name and not via -l option.
Best regards,
--
Ralph
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
