multiarch procedure
Hi, I've been using libtool quite happily for some time but have just started looking at packaging libraries for x86_64 systems. I'm trying to find out what the recommended method is for installation of x86_64 64bit libraries. Most of the systems I'm targeting are Fedora which expect 64bit libraries in /usr/local/lib64 etc. and use /usr/local/lib only for 32bit. The compilers I have installed on the x86_64 test machine all build 64bit libraries by default (which is what I want) but $(libdir) defaults to /usr/local/lib Is the only method to manually set --libdir at configure time (I have libtool integrated with automake/autoconf)? I was a little reluctant to have to tell everyone building the libraries that they may (or may not) have to use this switch since I really was hoping to keep the configure stage as automatic as possible. I've done some googling on the subject (with little or nothing concrete to show for it) and it appears that Fedora libtool was patched for multiarch support - although I'm currently uncertain whether this is still true. I had a run through the libtool info at work and I'm sure I found a tantalising reference to multiarch (with a comment along the lines of "unless you know what this is you don't need it") but I certainly can't find anything on my home system (libtool 2.2.4) Any suggestions for a 'correct' approach will be gratefully received! (Please CC me in any replies as I am not subscribed to libtool on this email account) Steve -- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: multiarch procedure
On Fri, 9 May 2008, Steve Edwards wrote: I've been using libtool quite happily for some time but have just started looking at packaging libraries for x86_64 systems. I'm trying to find out what the recommended method is for installation of x86_64 64bit libraries. Different systems use different approaches. Is the only method to manually set --libdir at configure time (I have libtool integrated with automake/autoconf)? I was a little The only way to be sure that things will work is to use --prefix and install into a different directory tree. If you advise to use --libdir, then you still have the interface header files to worry about. Interface header files often have different definitions for 32 and 64 bits. I had a run through the libtool info at work and I'm sure I found a tantalising reference to multiarch (with a comment along the lines of "unless you know what this is you don't need it") but I certainly can't find anything on my home system (libtool 2.2.4) Libtool 2.2.X includes support for automatically using 64-bit libraries on various popular systems (e.g. Solaris, Linux). Otherwise 64-bit builds would fail on systems which default to a 32 bit ABI. It does not include multiarch/multilib support necessary to build 32 and 64 bit libraries and install into that footprint. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: multiarch procedure
On Fri, May 9, 2008 at 9:20 AM, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > On Fri, 9 May 2008, Steve Edwards wrote: >> >> I've been using libtool quite happily for some time but have just started >> looking at packaging libraries for x86_64 systems. I'm trying to find out >> what the recommended method is for installation of x86_64 64bit libraries. > > Different systems use different approaches. > >> Is the only method to manually set --libdir at configure time (I have >> libtool integrated with automake/autoconf)? I was a little > > The only way to be sure that things will work is to use --prefix and install > into a different directory tree. If you advise to use --libdir, then you > still have the interface header files to worry about. Interface header > files often have different definitions for 32 and 64 bits. I agree with this. I started out using the default redhat method of lib64 and lib. After a while, and adding more platforms, compilers, versions, etc. I found it useful to almost always use different prefixes. That being said, I still have a mechanism in my configure to use lib64, etc. I use the code below to add a configure option to set a libdir suffix. Thus, I can set it to create lib64, lib/x86_64, etc. Then, all my other checks for packages try using $acl_libdirstem to link. If that fails and it is not simply "lib", I try that for a mix of packages some of which use lib64, some of which use separate prefixes. You could also set a default, say based on the existance of "/usr/lib64" for redhat systems. AC_DEFUN([CHECK_LIBDIR_SUFFIX], [ AC_ARG_WITH(libdir-suffix, AS_HELP_STRING([--with-libdir-suffix=suffix],[Suffix to apply to library directories]),,with_libdir_suffix=) ]) acl_libdirstem="lib$with_libdir_suffix" libdir="$libdir$with_libdir_suffix" Hope that helps some. > >> I had a run through the libtool info at work and I'm sure I found a >> tantalising reference to multiarch (with a comment along the lines of >> "unless you know what this is you don't need it") but I certainly can't find >> anything on my home system (libtool 2.2.4) > > Libtool 2.2.X includes support for automatically using 64-bit libraries on > various popular systems (e.g. Solaris, Linux). Otherwise 64-bit builds would > fail on systems which default to a 32 bit ABI. It does not include > multiarch/multilib support necessary to build 32 and 64 bit libraries and > install into that footprint. > > Bob > == > Bob Friesenhahn > [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ > > > > ___ > http://lists.gnu.org/mailman/listinfo/libtool > ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool(2.2.4) detect native java compiler in cross-compilation environment
Hello libtool Team, In my environment exist GNU C and Java compilers along with mingw C cross-compiler. When I build libtool the path to mingw C-compiler (gcc) precede path to native C-compiler. In configure output I see : checking for i386-mingw32msvc-strip... i386-mingw32msvc-strip checking for i386-mingw32msvc-gcc... i386-mingw32msvc-gcc checking for i386-mingw32msvc-gcj... no checking for gcj... gcj -> OOPS ! checking if gcj supports -fno-rtti -fno-exceptions... (cached) no checking for gcj option to produce PIC... checking if gcj static flag -static works... no checking if gcj supports -c -o file.o... yes checking if gcj supports -c -o file.o... (cached) yes checking whether the gcj linker (/opt/mingw/i386-mingw32msvc/bin/ld) . Is above detection correct ? If is detected a prefix for a program why configure try to find a program without prefix ? The check for Fortran compiler look similar but I don't have installed native Fortran-compiler so libtool configure don't detect any. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool(2.2.4) detect native java compiler in cross-compilation environment
On Fri, 9 May 2008, Roumen Petrov wrote: checking for i386-mingw32msvc-gcj... no checking for gcj... gcj -> OOPS ! Is above detection correct ? If is detected a prefix for a program why configure try to find a program without prefix ? It looks to me like it did not detect a prefix for the program in the above example, so, as a last-ditch effort, it tried without a prefix. If it picks up the wrong tools, does libtool's configure end up using them or does it eventually reject them? Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool(2.2.4) detect native java compiler in cross-compilation environment
Bob Friesenhahn wrote: On Fri, 9 May 2008, Roumen Petrov wrote: checking for i386-mingw32msvc-gcj... no checking for gcj... gcj -> OOPS ! Is above detection correct ? If is detected a prefix for a program why configure try to find a program without prefix ? It looks to me like it did not detect a prefix for the program in the above example, so, as a last-ditch effort, it tried without a prefix. If it picks up the wrong tools, does libtool's configure end up using them or does it eventually reject them? Dunno. May be it try to use. As example file "tests/testsuite.dir/35/run contain" (after make check-local) contain: = ... CPP='i386-mingw32msvc-gcc -E' ... STRIP='i386-mingw32msvc-strip' ... GCJ='gcj' GCJFLAGS='-g -O2' ... = Also in the file /tests/convenience.at I found: = 262: # There are just too many broken gcj installations out there, either missing 263: # libgcj.spec or unable to find it. Skip this test for them. 264: if test $i -eq 1; then 265:AT_CHECK([$GCJ $GCJFLAGS -c foo1.java || exit 77], [], [ignore], [ignore]) 266:AT_CHECK([$GCJ $GCJFLAGS --main=foo1 -o foo1 foo1.java A1.java || exit 77],[],[ignore],[ignore]) 267:AT_CHECK([./foo1$EXEEXT || exit 77],[],[ignore],[ignore]) = and the command "make check-local" report: 23: Java convenience archives skipped (convenience.at:267) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
