Re: Potential bugfix for bug#21455: Bug while cross-compiling multiple libtool-based packages ...
Ping ? On Sun, 2015-10-18 at 15:41 +0200, Joakim Tjernlund wrote: > While googling for a fix for bug#21455, > http://lists.gnu.org/archive/html/bug-libtool/2015-09/msg00012.html , > I came across: > > http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.4/use-sysroot-in-libpath > .patch?id=release-2010.12 > > This appear to be the correct fix for the error in bug 21455 > > Jocke ___ https://lists.gnu.org/mailman/listinfo/libtool
Potential bugfix for bug#21455: Bug while cross-compiling multiple libtool-based packages ...
While googling for a fix for bug#21455, http://lists.gnu.org/archive/html/bug-libtool/2015-09/msg00012.html , I came across: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/libtool/libtool-2.4/use-sysroot-in-libpath.patch?id=release-2010.12 This appear to be the correct fix for the error in bug 21455 Jocke ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: cross-compiling with libtool
On Thu, 14 May 2015, Lane wrote: That's what I don't understand. I do have a ranlib binary and it is named by the cross-tools environment that I've been given. For some reason it's not able to find it though when running make install and I don't know how that happens. Are you running 'make install' as a different user than the user who did the build? If so, the PATH, LD_LIBRARY_PATH, or the ability to execute the binary may be different. Check the PATH, LD_LIBRARY_PATH, and the permission bits on the executable. If this 'ranlib' is a script rather than a true binary (not uncommon for transplanted cross-tools), then check its first line to see if the shell it requests is valid and allows execution by that user. Lastly, the toolchain binaries might be a different architecture than the native architecture for your machine. For example, they might be i386 and/or x86-64. If the user id, PATH, or LD_LIBRARY_PATH, changes, perhaps this is causing binaries not to be runnable any more. I have seen cases before where binaries for a different architecture were treated as if they were not programs at all until the framework for the other architecture was installed on the system. 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: cross-compiling with libtool
That's what I don't understand. I do have a ranlib binary and it is named by the cross-tools environment that I've been given. For some reason it's not able to find it though when running make install and I don't know how that happens. On Wed, May 13, 2015 at 10:10 PM, Bob Friesenhahn bfrie...@simple.dallas.tx.us wrote: On Wed, 13 May 2015, Lane wrote: arm-blues-linux-gnueabi-libtool: install: chmod 644 /opt/blues/lib/libbl_parsers.a arm-blues-linux-gnueabi-libtool: install: arm-blues-linux-gnueabi-ranlib /opt/blues/lib/libbl_parsers.a ../../../arm-blues-linux-gnueabi-libtool: line 1104: arm-blues-linux-gnueabi-ranlib: command not found Makefile:395: recipe for target 'install-libLTLIBRARIES' failed Any thoughts on how to proceed? 1. Assuming that you want to make progress with your work. 2. Assuming that your other cross-tools are named prefixed with 'arm-blues-linux-gnueabi-'. 3. Assuming that ranlib is not actually necessary. You could change to the directory where the other cross-tools are and do ln -s /bin/true arm-blues-linux-gnueabi-ranlib Altnerately, you could find a correct ranlib binary and make sure that it is named appropriately. 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
cross-compiling with libtool
I hope this is the right list to ask for libtool help. If not, please let me know. I have an app that uses autotools and it works just fine on x86_64. However, when cross-compiling for arm, I am able to configure, make (successfully), but then make install is a problem and I was hoping someone could give me a bit of direction w/ the error below. --- $ sudo make install Making install in src make[1]: Entering directory '/home/srd/workspace/bl/blues-BUILD/src' Making install in libs make[2]: Entering directory '/home/srd/workspace/bl/blues-BUILD/src/libs' Making install in parsers make[3]: Entering directory '/home/srd/workspace/bl/blues-BUILD/src/libs/parsers' make[4]: Entering directory '/home/srd/workspace/bl/blues-BUILD/src/libs/parsers' /bin/mkdir -p '/opt/blues/lib' ../../../arm-blues-linux-gnueabi-libtool --mode=install /usr/bin/install -c libbl_parsers.la '/opt/blues/lib' arm-blues-linux-gnueabi-libtool: install: /usr/bin/install -c .libs/libbl_parsers.so.0.0.0 /opt/blues/lib/libbl_parsers.so.0.0.0 arm-blues-linux-gnueabi-libtool: install: (cd /opt/blues/lib { ln -s -f libbl_parsers.so.0.0.0 libbl_parsers.so.0 || { rm -f libbl_parsers.so.0 ln -s libbl_parsers.so.0.0.0 libbl_parsers.so.0; }; }) arm-blues-linux-gnueabi-libtool: install: (cd /opt/blues/lib { ln -s -f libbl_parsers.so.0.0.0 libbl_parsers.so || { rm -f libbl_parsers.so ln -s libbl_parsers.so.0.0.0 libbl_parsers.so; }; }) arm-blues-linux-gnueabi-libtool: install: /usr/bin/install -c .libs/libbl_parsers.lai /opt/blues/lib/libbl_parsers.la arm-blues-linux-gnueabi-libtool: install: /usr/bin/install -c .libs/libbl_parsers.a /opt/blues/lib/libbl_parsers.a arm-blues-linux-gnueabi-libtool: install: chmod 644 /opt/blues/lib/libbl_parsers.a arm-blues-linux-gnueabi-libtool: install: arm-blues-linux-gnueabi-ranlib /opt/blues/lib/libbl_parsers.a ../../../arm-blues-linux-gnueabi-libtool: line 1104: arm-blues-linux-gnueabi-ranlib: command not found Makefile:395: recipe for target 'install-libLTLIBRARIES' failed make[4]: *** [install-libLTLIBRARIES] Error 127 make[4]: Leaving directory '/home/srd/workspace/bl/blues-BUILD/src/libs/parsers' Makefile:617: recipe for target 'install-am' failed make[3]: *** [install-am] Error 2 make[3]: Leaving directory '/home/srd/workspace/bl/blues-BUILD/src/libs/parsers' Makefile:345: recipe for target 'install-recursive' failed make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory '/home/srd/workspace/bl/blues-BUILD/src/libs' Makefile:345: recipe for target 'install-recursive' failed make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory '/home/srd/workspace/bl/blues-BUILD/src' Makefile:414: recipe for target 'install-recursive' failed make: *** [install-recursive] Error 1 --- Any thoughts on how to proceed? ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: cross-compiling with libtool
On Wed, 13 May 2015, Lane wrote: arm-blues-linux-gnueabi-libtool: install: chmod 644 /opt/blues/lib/libbl_parsers.a arm-blues-linux-gnueabi-libtool: install: arm-blues-linux-gnueabi-ranlib /opt/blues/lib/libbl_parsers.a ../../../arm-blues-linux-gnueabi-libtool: line 1104: arm-blues-linux-gnueabi-ranlib: command not found Makefile:395: recipe for target 'install-libLTLIBRARIES' failed Any thoughts on how to proceed? 1. Assuming that you want to make progress with your work. 2. Assuming that your other cross-tools are named prefixed with 'arm-blues-linux-gnueabi-'. 3. Assuming that ranlib is not actually necessary. You could change to the directory where the other cross-tools are and do ln -s /bin/true arm-blues-linux-gnueabi-ranlib Altnerately, you could find a correct ranlib binary and make sure that it is named appropriately. 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
Add sysroot_path for cross compiling in libtool-1.5.10
Hi, I have a cross compiling toolchain which use libtool-1.5.10. The toolchain place binaries, libraries ... in another path (ex:/usr/local/toolchain/). However, the *.la files were created with another path, it looks like $ cat libpng12.la |grep libdir libdir='/usr/lib' Actually, the libpng12.la was placed in /usr/local/toolchain/usr/lib. I had made a patch that let libtoo-1.5.10 support SYSROOT_PATH. Before people use libtool to cross compilie, he can add a sysroot path in *libdir* if he export LIBTOOL_SYSROOT_PATH first. ex: $export LIBTOOL_SYSROOT_PATH=/usr/local/foo Once libtool try to read in libdir='/usr/lib' in la file, it will replace it with libdir='/usr/local/foo/usr/lib' I add the patch as attachment. Best Regards, -Julian Index: libtool-1.5.10/ltmain.in === --- libtool-1.5.10.orig/ltmain.in 2008-07-25 16:24:21.0 +0800 +++ libtool-1.5.10/ltmain.in 2008-07-25 18:31:41.0 +0800 @@ -137,6 +137,52 @@ # Shell function definitions: # This seems to be the best place for them +# func_add_sysroot_path add LIBTOOL_SYSROOT_PATH as prefix in search path +# -L/usr/lib - -L/home/foo/usr/lib if sysroot is /home/foo +func_add_sysroot_path () +{ + _suffix= + _leading= + case ${1} in +-L*) + _suffix=`echo ${1} |sed -e s:-L::` + _suffix=${LIBTOOL_SYSROOT_PATH}${_suffix} + _leading=-L + ;; +-I*) + _suffix=`echo ${1} |sed -e s:-I::` + _suffix=${LIBTOOL_SYSROOT_PATH}${_suffix} + _leading=-I + ;; +/*) + _suffix=${LIBTOOL_SYSROOT_PATH}${1} + _leading= + ;; +*) + _suffix=${1} + _leading= + esac + eval add_sysroot_path_result=${_leading}${_suffix} +} + +# func_rm_sysroot_path remove LIBTOOL_SYSROOT_PATH +# -L/home/foo/usr/lib = if sysroot is /home/foo +func_rm_sysroot_path () { + __rm_sysroot_path=${1} + case $__rm_sysroot_path in + -L*) +__rm_sysroot_path=`echo ${1}|sed -e s:$LIBTOOL_SYSROOT_PATH:/:g` +;; + -I*) +__rm_sysroot_path=`echo ${1}|sed -e s:$LIBTOOL_SYSROOT_PATH:/:g` +;; + /*) +__rm_sysroot_path=`echo ${1}|sed -e s:$LIBTOOL_SYSROOT_PATH:/:g` +;; + esac + rm_sysroot_path_result=`echo ${__rm_sysroot_path}|sed -e s://:/:g` +} + # func_win32_libid arg # return the library type of file 'arg' # @@ -2196,6 +2242,16 @@ *) . ./$lib ;; esac +# Add Sysroot to path # +tmp_depen_libs= +for depen_lib in $dependency_libs; do + func_add_sysroot_path $depen_lib + tmp_depen_libs=$tmp_depen_libs $add_sysroot_path_result +done +dependency_libs=$tmp_depen_libs +func_add_sysroot_path $libdir +libdir=$add_sysroot_path_result + if test $linkmode,$pass = lib,link || test $linkmode,$pass = prog,scan || { test $linkmode != prog test $linkmode != lib; }; then @@ -2777,6 +2833,10 @@ # $echo $modename: warning: \`$deplib' seems to be moved 12 # fi if ! grep ^installed=no $deplib /dev/null; then + #Add Sysroot to libdir + func_add_sysroot_path $libdir + libdir=$add_sysroot_path_result + eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $deplib` if test -z $libdir; then $echo $modename: \`$deplib' is not a valid libtool archive 12 @@ -5243,6 +5303,17 @@ case $host,$output,$installed,$module,$dlname in *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;; esac + + # Remove Sysroot from path before write in .la file # + tmp_depen_libs= + for depen_lib in $dependency_libs; do +func_rm_sysroot_path $depen_lib +tmp_depen_libs=$tmp_depen_libs $rm_sysroot_path_result + done + dependency_libs=$tmp_depen_libs + func_rm_sysroot_path $libdir + libdir=$rm_sysroot_path_result + $echo $output \ # $outputname - a libtool library file # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP
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
Cross compiling, FreeBSD, libtool 1.4.2 - --host=i386-mingw32msvc
When trying to cross compile using --host=i386-mingw32msvc on libtool 1.4.2 under FreeBSD, I'm running into problems when it tries to build ltdl. Is it something I'm doing in the configure.in/Makefile.am/bootstrap or is this a problem with ltdl? http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/prolix/prolix/src/ ^^^ is where the configure.in, etc are for the project I'm working on. Would anyone mind taking a look? Thanks ;-) (errors on make as follows...) gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c ltdl.c -DDLL_EXPORT -DPIC -o .libs/ltdl.lo ltdl.c: In function `__declspec': ltdl.c:161: parameter `lt_dlmalloc' is initialized ltdl.c:162: syntax error before `__declspec' ltdl.c:188: storage class specified for parameter `rpl_strdup' ltdl.c:192: syntax error before `const' ltdl.c:188: declaration for parameter `rpl_strdup' but no such parameter ltdl.c:161: declaration for parameter `lt_dlmalloc' but no such parameter ltdl.c:196: `str' undeclared (first use in this function) ltdl.c:196: (Each undeclared identifier is reported only once ltdl.c:196: for each function it appears in.) ltdl.c:205: warning: return makes integer from pointer without a cast ltdl.c: In function `lt_estrdup': ltdl.c:884: warning: initialization makes pointer from integer without a cast *** Error code 1 -- [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool