Re: 64-bit library on Solaris SPARC
Hi Marcel, * Marcel Martin wrote on Thu, May 11, 2006 at 01:01:36PM CEST: I'm trying to build a 64-bit library on Solaris 9 SPARC. I'm actually using autotools with a larger project, but I could reduce the problem to this small test case which uses only libtool: $ libtool --mode=link g++ -rpath /usr/local/lib -m64 -o libmini.la \ -no-undefined -version-info 0:0:0 mini.lo g++ -shared -nostdlib /vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crti.o /usr/ccs/lib/values-Xa.o /vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crtbegin.o .libs/mini.o -Wl,-R -Wl,/vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3 -Wl,-R *snip* ld: fatal: file .libs/mini.o: wrong ELF class: ELFCLASS64 ld: fatal: File processing errors. No output written to .libs/libmini.so.0.0.0 collect2: ld returned 1 exit status The problem is that incorrect paths are used: For example, instead of /vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/crti.o it should be /vol/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.9/3.4.3/sparcv9/crti.o If I change the paths and do the g++ call manually, it works. I guess this is or has to do with the multilib problem which has come up on the list before, but I'm still at a loss at what to do now. Is there a solution or a workaround for this problem? Workaround: create a libtool script designed for 64bit linking only, and adjust the variables compiler_lib_search_path and maybe also sys_lib_search_path_spec sys_lib_dlsearch_path_spec to point to the right directories. These variables are set for the C compiler at the beginning of the script, and for the C++ and other compilers at the very end. A fix is still to be done. Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
libtool / SkyOS / ELF
Hi! As promised in my last post to this mailinglist I finally switched the SkyOS executable format from PE to ELF. And finally, libtool works like a charm. Anyway, I have one question regarding the version-type. As I don't want to use any shared library versioning system on SkyOS, is it possible to just set the version_type to none? At least one package, tiff-3.7.4, has problems with none as version type. ( though I'm not sure if this is a tiff-3.7.4 or a libtool problem) Attached is the patch against libtool-1.5.22 which adds skyos as a supported target. I tested this patch with following packages which all built a valid shared library using libtool: atk-1.10.3, cairo-1.0.2, fontconfig-2.3.93, libxml2-2.6.23, glib-2.8.6, libgdiplus-1.1.13.2, perl-5.8.8, gettext-0.14.5 and a few more. Please let me know if you have any suggestions/comments regarding this patch, Thanks! Robert libtool.m4.patch Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool / SkyOS / ELF
Hi Robert, * Robert Szeleney wrote on Thu, May 11, 2006 at 09:29:28AM CEST: As promised in my last post to this mailinglist I finally switched the SkyOS executable format from PE to ELF. You know, it's pretty funny when issues in trying to port Libtool to some system has the effect of having the system change its exectuable format. Talk about reverse effects. :-) And finally, libtool works like a charm. Great. It'd be nice to see how the testsuite fares (see README on how to run it verbosely). Anyway, I have one question regarding the version-type. As I don't want to use any shared library versioning system on SkyOS, is it possible to just set the version_type to none? I think that should be possible. But of course, that will limit the ways in which you will be able to upgrade your shared libraries later. Also, since I think version_type=none may not have seen so much usage exposure in Libtool, there may have been bit rot. At least one package, tiff-3.7.4, has problems with none as version type. ( though I'm not sure if this is a tiff-3.7.4 or a libtool problem) Could you point to more information, so we can see what the problem is (build log, something that shows the failure)? Thanks. Attached is the patch against libtool-1.5.22 which adds skyos as a supported target. Hmm. I think it's missing a few things still. First, if you have no libm, I think currently it's necessary to hack a couple of places in ltmain.in, unfortunately (search for beos there). Then, what about PIC objects, do you use text relocations in your shared libraries? If yes, how would that work on, say, x86_64 machines? I think you need to set lt_prog_compiler_pic (for both C++ and non-C++; if there are multiple compilers on SkyOS, also for both $GCC = yes and no). Similarly, how about lt_prog_compiler_static and lt_prog_compiler_wl? Then, I think you don't have an archive_cmds setting for C (and other languages, in AC_LIBTOOL_PROG_LD_SHLIBS), only for C++ (AC_LIBTOOL_LANG_CXX_CONFIG). Further, how about means to hardcode library paths? (That is rather important in order to be able to use uninstalled libraries while compiling and testing some package.) There are several aspects to this topic. Also, I guess you may need to set an export_dynamic_flag_spec value, and for optimization, you can look at providing whole_archive_flag_spec if available. Further, is there a means to not export all non-static symbols in a library? If yes, you should set archive_expsyms_cmds. For optimization, a setting in AC_LIBTOOL_SYS_MAX_CMD_LEN helps. Then, an important missing part is a suitable adjustment to ltdl.m4. I tested this patch with following packages which all built a valid shared library using libtool: atk-1.10.3, cairo-1.0.2, fontconfig-2.3.93, libxml2-2.6.23, glib-2.8.6, libgdiplus-1.1.13.2, perl-5.8.8, gettext-0.14.5 and a few more. That's great. I think the Libtool testsuite will point to more necessary changes. Let's see further then. Please let me know if you have any suggestions/comments regarding this patch, Well, a GNU-style ChangeLog entry is optional but would be helpful. ;-) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: support for SunPRO C/C++ on Linux
Hi Bruno,
* Bruno Haible wrote on Wed, May 10, 2006 at 09:34:42PM CEST:
+ if LC_ALL=C $CC -V 21 | sed 1q | grep Sun C /dev/null;
then
If that LC_ALL=C was really necessary, then that is a bug.
It may not be necessary within the context of a configure script. I put it
there because I tested the English output only, not the Japanese or Chinese
or Thai one... Had forgotten that autoconf already disables i18n.
Ah, ok. That settles this then, thanks.
Any reason not to simplify this to something like this?
case `$CC -V 21 /dev/null` in
*Sun\ C*)
Yes. HP-UX /bin/sh is known to dump core in
case `command that produces more than 1 KB of output` in
and I don't know how much output other compilers generate when given the -V
option.
They might generate a lot: IBM compilers dump their 100KB worth of help
on an unknown option or other issues -- this really bloats config.log
output a lot (maybe we should think of limiting that in Autoconf..).
But say, why is that HP-UX shell issue not listed in the Autoconf
portability section? FWIW, I can't reproduce it on some HP-UX systems;
the oldest I have access to is an HP-UX 10.20. It'd be good to know
about the impact of this -- do you have pointers to bug reports? (Also
note that the shell selection algorithm of Autoconf-2.59c will select
/usr/bin/posix/sh there.)
+ _LT_AC_TAGVAR(whole_archive_flag_spec,
$1)='${wl}--whole-archive`new_convenience=; for conv in
+$convenience\\; do test -z \$conv\ ||
new_convenience=\$new_convenience,$conv\; done; $echo
\$new_convenience\`+${wl}--no-whole-archive'
Are you sure the compiler driver won't reorder arguments here?
I used this backquoted glue-with-commas construct precisely because the
compiler driver did reorder the arguments. Earlier I used
${wl}--whole-archive$convenience ${wl}--no-whole-archive
which had the effect of passing to the compiler driver flags like
-Wl,--whole-archive .libs/libfoo.a .libs/libbar.a -Wl,--no-whole-archive
and the compiler driver passed these options to the linker:
--whole-archive --no-whole-archive .libs/libfoo.a .libs/libbar.a
The patch I submitted now passes to the compiler driver flags
-Wl,--whole-archive,.libs/libfoo.a,.libs/libbar.a -Wl,--no-whole-archive
and the linker gets these options:
--whole-archive .libs/libfoo.a .libs/libbar.a --no-whole-archive
So in general this should make --whole-archive actually work.
IIRC, on Solaris, this:
| _LT_TAGVAR(whole_archive_flag_spec, $1)='${wl}-z ${wl}allextract`for conv in
$convenience\\; do test -n \$conv\
new_convenience=\$new_convenience,$conv\; done; $echo \$new_convenience\`
${wl}-z ${wl}defaultextract'
caused some problems somewhere; cf. for example this thread:
http://lists.gnu.org/archive/html/bug-libtool/2005-10/msg00040.html
and note that with C++, your patch sets ${wl} to `-Qoption ld ' as well,
not to `-Wl,'.
Also, consider this: in a (maybe partially) static linking case, the
objects from the convenience archive require some symbol from a library
specified later. If the driver reorders, we may be out of luck here, as
the needed library may happen to end up listed earlier. OTOH, the
driver on Solaris knows '-z allextract' and understands what to do with
the following arguments. So that had a chance of actually working
across Solaris versions (the driver happens to also reorder differently
across versions).
Now, if the driver understands --whole-archive/--no-whole-archive on
GNU/Linux, I think that should be used plainly, without ${wl}. If it
doesn't, then, depending on how it reorders, we should file a bug
report.
The only drawback of this approach is if no other object file is used, i.e.
the whole contents to be linked is inside --whole-archive, the compiler driver
refuses to do the link because it complains about no object files to link.
I don't know if it is a real use-case of libtool;
Yes, that is a real problem for some packages out there that just
combine a bunch of convenience archives to some larger shared library.
if so, probably a fix could
be to add $convenience at the end of whole_archive_flag_spec, so that the
compiler sees the libraries too. (The linker would then see them twice, the
first time with --whole-archive, the second time without. That should be ok,
I hope?)
Ouch, that seems quite expensive. I don't currently know about a problem
with your suggested workaround, but I've been suggesting users to add a
dummy object instead (or just not wrap all objects into convenience
archives). BTW, letting libtool add a dummy object itself is very
tricky to do right, so I prefer to avoid that.
(This problem was also fixed on Solaris by the approach described above.)
only the CVS HEAD
Libtool testsuite exposes the known failures fully.
Do you have two test cases, one for a whole library plus some other objects,
and one for two libraries and no
Re: gettext cvs, woe32 dlls
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Forwarding this very useful discussion of library builds on cygwin on bug-gnu-utils. There are some suggestions in there for what libtool should be doing to ease library builds. Eric Blake Date: Wed, 10 May 2006 23:25:46 -0400 From: Charles Wilson To: Bruno Haible CC: bug-gnu-gettext Bruno Haible wrote: Hello Charles, I have a question about the WOE32GCC_SHLIBS conditional: When a library libfoo contains a public, exported variable 'int data;', and the library is installed with both shared and static libs (.dll, .dll.a and .a), then what should the include file libfoo.h contain? extern __declspec(dllimport) int data; is the right thing when a program links to the shared variant (so that the compiler knows to use _imp__data instead of data itself). extern int data; is the right thing when a program links to the static variant. But how can the header file know whether the program will link statically or not? It can't, not without help, unfortunately. This matters for libintl, libasprintf and libgettextpo. Yes, in general you are right: we have four states (per library) building the library as shared : declspec(dllexport) building the library as static : no decorator (*) building a client of the library, intending to link shared : extern declspec(dllimport) building a client of the library, intending to link static : extern (*) (*) Technically, you could ALWAYS declare variables extern in the header files, and just ensure that one .c file in the library actually defines the variable. This collapses your state space to just three: in-library shared, out-library shared, and static(in or out). But... This means we need two binary macros to fully span the state space. With the code in its present state, only libintl of those three libs has the full complement (and even that is cheating). With my patch, libintl, libgettextsrc and libgettextlib have the full complement (but are still cheating): BUILDING_LIBINTL + DLL_EXPORT Back before the advent of autoimport, I supported DLL builds of various libraries using the mechanism below. However, it doesn't really mesh well with libtool, unless you overload the meaning of libtool's DLL_EXPORT macro (which is what I did in the patches I posted). (This lack of meshing well with libtool is why most other packages -- and libtool -- signed on to the auto-import bandwagon) old mechanism (1) First, assert that there is one normal way and one special way to build the library and to link against the library (e.g. there has to be some default when you don't #define any of your state macros). I decided that default was 'I'm building an application that will link dynamically against the library'. I felt this placed the least burden on normal users: use DLL, no need to #define anything. use .a ...well, then you have to take special steps. Building the dll or .a -- more special steps, but those were under my control. Plus, in the presence of .la with both old and shared libraries, that's libtool's default; and if both .a and .dll.a exist, it is gcc/ld's default as well: link against shared when possible. (2) One state variable is BUILDING_LIBRARY_FOO -- I added this to the Makefile.am/ la_CFLAGS for the internal gettext libraries, but not for libasprintf and libgettextpo (libintl already had it). Why did I skip those two? 'Cause they seemed to work okay in my minimal tests, but I admit I did not attempt use the .a's. (3) The other state variable is STATIC_LIBRARY_FOO. This differs (sortof) from the way I implemented it in the patch. [[[In the patch, I overloaded DLL_EXPORT to serve almost the same purpose, except that ideally you'd have one macro for each library FOO, not a single macro for all libraries. The latter situation complicates matters when you're building apps that depend on libs that depend on libs: your app SHALL link against the shared version of both libs, or the static version of both libs, not dll one and static other.]]] Anyway, then I had a stanza in some header library file that looked like this: #if BUILDING_LIBRARY_FOO # if STATIC_LIBRARY_FOO # define LIBRARY_FOO_EXTERN # define LIBRARY_FOO_API # else # define LIBRARY_FOO_EXTERN # define LIBRARY_FOO_API declspec(dllexport) # endif #else # if STATIC_LIBRARY_FOO # define LIBRARY_FOO_EXTERN extern # define LIBRARY_FOO_API # else # define LIBRARY_FOO_EXTERN extern # define LIBRARY_FOO_API declspec(dllimport) # endif So you see, the default case is group 4: 'I'm linking against the foo DLL.' Since that's the default behavior of libtool and gcc when both static and dynamic libraries are available, I thought it made sense. However, it means that clients who want to link statically have to behave differently during both compile and link phase: they must #define STATIC_LIBRARY_FOO when compiling as well as link with -static (and don't get me started on the libtool disaster
cross-compiling and libtool
I am trying to cross-complie gphoto2 gphoto.sf.net , which uses ltdl I have everything compiled, but on execution it tries to find its drivers in the build tree, and not in the target tree See below How do I configure libtool in a cross-compile environment to correctly find the stuff it is looking for? Thanks, --Yan [EMAIL PROTECTED]:~# gphoto2 --debug --list-ports 0.51 main(2): ALWAYS INCLUDE THE FOLLOWING LINES WHEN SENDING DEBUG MESSAGES TO THE MAILING LIST: 0.000483 main(2): gphoto2 2.1.99 0.000811 main(2): gphoto2 has been compiled with the following options: 0.001058 main(2): + /home/nfs/yan/whiterussian/OpenWrt-SDK-Linux-i686-1/staging_dir_mipsel/bin/mipsel-linux-uclibc-gcc (C compiler used) 0.001442 main(2): + popt (for handling command-line parameters) 0.001702 main(2): + exif (for displaying EXIF information) 0.001937 main(2): + no cdk (for accessing configuration options) 0.002175 main(2): + no aa (for displaying live previews) 0.002413 main(2): + no jpeg (for displaying live previews in JPEG format) 0.002656 main(2): + no readline (for easy navigation in the shell) 0.002974 main(2): libgphoto2 2.1.99 0.003287 main(2): libgphoto2 has been compiled with the following options: 0.003525 main(2): + /home/nfs/yan/whiterussian/OpenWrt-SDK-Linux-i686-1/staging_dir_mipsel/bin/mipsel-linux-uclibc-gcc (C compiler used) 0.003908 main(2): + no EXIF (for special handling of EXIF files) 0.004169 main(2): + no /proc/meminfo (adapts cache size to memory available) 0.004414 main(2): libgphoto2_port 0.5.2 0.004771 main(2): libgphoto2_port has been compiled with the following options: 0.005016 main(2): + /home/nfs/yan/whiterussian/OpenWrt-SDK-Linux-i686-1/staging_dir_mipsel/bin/mipsel-linux-uclibc-gcc (C compiler used) 0.005273 main(2): + USB (libusb, for USB cameras) 0.005512 main(2): + serial (for serial cameras) 0.005748 main(2): + no resmgr (serial port access and locking) 0.005985 main(2): + no baudboy (serial port locking) 0.006219 main(2): + no ttylock (serial port locking) 0.006457 main(2): + no lockdev (serial port locking) 0.009253 gphoto2-port-info-list(2): Using ltdl to load io-drivers from '/home/nfs/yan/whiterussian/OpenWrt-SDK-Linux-i686-1/build_mipsel/libgphoto2-2.1.99/ipkg-install/usr/lib/libgphoto2_port/0.5.2'... 0.009828 gphoto2-port-info-list(2): Counting entries (0 available)... 0.010133 gphoto2-port-info-list(2): 0 regular entries available. Devices found: 0 Path Description -- 0.010707 gp-camera(2): Freeing camera... 0.010954 gphoto2-port(2): Freeing port... 0.011335 libgphoto2/gphoto2-filesys.c(2): Clearing fscache LRU list... 0.011558 libgphoto2/gphoto2-filesys.c(2): fscache LRU list already empty 0.011771 gphoto2-filesystem(2): Internally deleting all folders from '/'... ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool-1.5.22 on Solaris 10
Hello, I compiled libtool-1.5.22 in a Sparc machine with Solaris 10 and got an error message on gmake check step, which told me write the log to you, so ... Nelson log.gmake-check-libtool-1.5.22.solaris10.txt.gz Description: application/gzip ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
