Re: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler
On Fri, 5 Feb 2016, Harald Servat wrote: I'm unsure on how to interpret the libtool related information because it is very simplistic configure:11699: checking if libtool supports shared libraries configure:11701: result: no however, at some point earlier, the following test might be related configure:8998: checking whether the fccpx linker (sparc64-linux-ld -m elf64_sparc) supports shared libraries configure:10069: result: no Can we provide some additional info or run additional tests to improve libtool on this system? The generated config.log file contains detail information regarding the tests performed and error messages produced. Looking there is the next step. The '-print-search-dirs' error message is because libtool attempted to treat the compiler like GCC and obtain its default linker search path. It is unfortunate if Fujitsu does not care to contribute. If that is indeed true, then that would be their loss since a large portion of free software packages use Autotools (including libtool) and these packages won't compile as effectively if the target is not supported. Fujitsu's system would be barren of commonly available software. Fujitsu is in the best position to support their own compiler and platform. 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: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler
On 2016-02-03 14:30, Harald Servat wrote: On 02/02/2016 07:02 PM, Mike Frysinger wrote: On 02 Feb 2016 17:51, Harald Servat wrote: we want to use libtool on a system on which we have to cross-compile from intel x86/64 to sparc/64 using the Fujitsu compiler (fccpx). Unfortunately, I'm unable to get libtool (version 2.4.2) to generate shared libraries. I have written a very small libtool + autotools example and run the following but I'm always getting the output shown below the commands. Note, that the same works fine in a linux/x86-64 and I don't have to add --enable-shared in that case, so I guess I don't need --enable-shared either in these tests. COMMANDS: ./configure --prefix=/tmp/test CC=fccpx --host=x86_64 ./configure --prefix=/tmp/test CC=fccpx --host=x86-64 --target=sparc64 ./configure --prefix=/tmp/test CC=fccpx --host=x86_64 --target=sparc64-linux your flags are incorrect. you want --build=x86_64-linux-gnu and --host=sparc64-linux-gnu. please read this doc for more info: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html -mike Thank you for the pointer Mike. we have found that ./configure --prefix=/tmp/test CC=fccpx --build=x86_64-linux-gnu --host=sparc64-linux-gnu did not work. See: I usually don't provide --build and --host on Fujitsu/IBM Blue Gene/Cray cross-compile systems but explicitly pass 'cross_compiling=yes' to prevent the execution of configure-generated programs and the cross-compiler via CC. On these systems the cross-compilers don't honor the GNU naming conventions, so I don't see a value in passing --build and --host. Is there anything that I'm missing? I made some tests on a Fujitsu PrimeHPC FX10 system for C, C++, and Fortran with vanilla autoconf 2.69, automake 1.13.4, libtool 2.4.6. I succeed in building and installing shared libraries (minimal example and real project) with following configure options: ../configure --prefix=`pwd`/_install cross_compiling=yes CC=fccpx CFLAGS="-Xg -XCClinker -Xg" CXX=FCCpx CXXFLAGS="-Xg -XCClinker -Xg" FC=frtpx The GNU compatibility flag -Xg is needed at configure time, the "-XCClinker -Xg" is needed at make time. It passes -Xg also to the link line, otherwise I got failures for C++. C worked without though. ... checking whether the fccpx linker (/usr/bin/ld -m elf64_sparc) supports shared libraries... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... unsupported checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... cross checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no However, the system support suggested to add the flag -Xg into the Fujitsu compiler and we found that the following configure did work. ./configure --prefix=/tmp/test CC=fccpx --host=x86-linux CFLAGS="-Xg" checking whether the fccpx linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... fccpx: warning: -print-search-dirs is unrecognized option. This option is passed to the linker. usage: fccpx [options] files. GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... cross checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes So that works for the small test example I generated. However, when passing the same flags to the application we want to build, then the libtool still claims it does not support shared libraries. So there are couple of questions then: any idea on why this larger case the addition of CFLAGS and --host does allow libtool to generate shared libraries? And, I don't have direct access to the system, but can I do something to improve the support on this system? Harald, I have access to FX10 (pi) and K computer and I'm willing to help. Is this about the upcoming Kobe tuning workshop (http://www.vi-hps.org/training/tws/tw20.html)? Christian Best, WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received. http://www.bsc.es/disclaimer ___
Re: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler
On 2016-02-03 18:33, Mike Frysinger wrote: On 03 Feb 2016 14:30, Harald Servat wrote: we have found that ./configure --prefix=/tmp/test CC=fccpx --build=x86_64-linux-gnu --host=sparc64-linux-gnu did not work. See: ... checking whether the fccpx linker (/usr/bin/ld -m elf64_sparc) supports shared libraries... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... unsupported checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... cross checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no However, the system support suggested to add the flag -Xg into the Fujitsu compiler and we found that the following configure did work. ./configure --prefix=/tmp/test CC=fccpx --host=x86-linux CFLAGS="-Xg" checking whether the fccpx linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... fccpx: warning: -print-search-dirs is unrecognized option. This option is passed to the linker. usage: fccpx [options] files. GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... cross checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes So that works for the small test example I generated. However, when passing the same flags to the application we want to build, then the libtool still claims it does not support shared libraries. So there are couple of questions then: any idea on why this larger case the addition of CFLAGS and --host does allow libtool to generate shared libraries? And, I don't have direct access to the system, but can I do something to improve the support on this system? i don't know what "fccpx" is, but i'd guess that libtool just doesn't understand how it works. please attach the config.log file from that run. fccpx/fcc are the Fujitsu C compiler commands: "There are two types of compile commands, one is the cross compile command that is fccpx, and the other is the own compile command that is fcc." I got in contact with them on Fujitsu supercomputer like K Computer and FX10 systems. With fccpx you cross-compile on a x86_64 login node for sparc64 compute nodes. fcc generates code for the x86_64 login node. You are right, libtool doesn't understand neither fccpx nor fcc nor the C++ and Fortran variants. I talked to Fujitsu but they are not eager to contribute to libtool. Christian -mike ___ https://lists.gnu.org/mailman/listinfo/libtool ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler
On 03 Feb 2016 14:30, Harald Servat wrote: >we have found that > > ./configure --prefix=/tmp/test CC=fccpx --build=x86_64-linux-gnu > --host=sparc64-linux-gnu > >did not work. See: > > ... > checking whether the fccpx linker (/usr/bin/ld -m elf64_sparc) supports > shared libraries... no > checking dynamic linker characteristics... GNU/Linux ld.so > checking how to hardcode library paths into programs... unsupported > checking for shl_load... no > checking for shl_load in -ldld... no > checking for dlopen... yes > checking whether a program can dlopen itself... cross > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... no > >However, the system support suggested to add the flag -Xg into the > Fujitsu compiler and we found that the following configure did work. > > ./configure --prefix=/tmp/test CC=fccpx --host=x86-linux CFLAGS="-Xg" > > checking whether the fccpx linker (/usr/bin/ld) supports shared > libraries... yes > checking whether -lc should be explicitly linked in... no > checking dynamic linker characteristics... fccpx: warning: > -print-search-dirs is unrecognized option. This option is passed to the > linker. > usage: fccpx [options] files. > GNU/Linux ld.so > checking how to hardcode library paths into programs... immediate > checking for shl_load... no > checking for shl_load in -ldld... no > checking for dlopen... yes > checking whether a program can dlopen itself... cross > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > >So that works for the small test example I generated. However, when > passing the same flags to the application we want to build, then the > libtool still claims it does not support shared libraries. So there are > couple of questions then: any idea on why this larger case the addition > of CFLAGS and --host does allow libtool to generate shared libraries? > And, I don't have direct access to the system, but can I do something to > improve the support on this system? i don't know what "fccpx" is, but i'd guess that libtool just doesn't understand how it works. please attach the config.log file from that run. -mike signature.asc Description: Digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler
On 02/02/2016 07:02 PM, Mike Frysinger wrote: On 02 Feb 2016 17:51, Harald Servat wrote: we want to use libtool on a system on which we have to cross-compile from intel x86/64 to sparc/64 using the Fujitsu compiler (fccpx). Unfortunately, I'm unable to get libtool (version 2.4.2) to generate shared libraries. I have written a very small libtool + autotools example and run the following but I'm always getting the output shown below the commands. Note, that the same works fine in a linux/x86-64 and I don't have to add --enable-shared in that case, so I guess I don't need --enable-shared either in these tests. COMMANDS: ./configure --prefix=/tmp/test CC=fccpx --host=x86_64 ./configure --prefix=/tmp/test CC=fccpx --host=x86-64 --target=sparc64 ./configure --prefix=/tmp/test CC=fccpx --host=x86_64 --target=sparc64-linux your flags are incorrect. you want --build=x86_64-linux-gnu and --host=sparc64-linux-gnu. please read this doc for more info: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html -mike Thank you for the pointer Mike. we have found that ./configure --prefix=/tmp/test CC=fccpx --build=x86_64-linux-gnu --host=sparc64-linux-gnu did not work. See: ... checking whether the fccpx linker (/usr/bin/ld -m elf64_sparc) supports shared libraries... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... unsupported checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... cross checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no However, the system support suggested to add the flag -Xg into the Fujitsu compiler and we found that the following configure did work. ./configure --prefix=/tmp/test CC=fccpx --host=x86-linux CFLAGS="-Xg" checking whether the fccpx linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... fccpx: warning: -print-search-dirs is unrecognized option. This option is passed to the linker. usage: fccpx [options] files. GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... cross checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes So that works for the small test example I generated. However, when passing the same flags to the application we want to build, then the libtool still claims it does not support shared libraries. So there are couple of questions then: any idea on why this larger case the addition of CFLAGS and --host does allow libtool to generate shared libraries? And, I don't have direct access to the system, but can I do something to improve the support on this system? Best, WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received. http://www.bsc.es/disclaimer ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler
On 02 Feb 2016 17:51, Harald Servat wrote: >we want to use libtool on a system on which we have to cross-compile > from intel x86/64 to sparc/64 using the Fujitsu compiler (fccpx). > Unfortunately, I'm unable to get libtool (version 2.4.2) to generate > shared libraries. > >I have written a very small libtool + autotools example and run the > following but I'm always getting the output shown below the commands. > Note, that the same works fine in a linux/x86-64 and I don't have to add > --enable-shared in that case, so I guess I don't need --enable-shared > either in these tests. > > COMMANDS: > >./configure --prefix=/tmp/test CC=fccpx --host=x86_64 >./configure --prefix=/tmp/test CC=fccpx --host=x86-64 --target=sparc64 >./configure --prefix=/tmp/test CC=fccpx --host=x86_64 > --target=sparc64-linux your flags are incorrect. you want --build=x86_64-linux-gnu and --host=sparc64-linux-gnu. please read this doc for more info: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Hosts-and-Cross_002dCompilation.html -mike signature.asc Description: Digital signature ___ https://lists.gnu.org/mailman/listinfo/libtool
Libtool does not generate shared libraries when cross compiling x86/64 -> sparc64 using fujitsu compiler
Hello list, we want to use libtool on a system on which we have to cross-compile from intel x86/64 to sparc/64 using the Fujitsu compiler (fccpx). Unfortunately, I'm unable to get libtool (version 2.4.2) to generate shared libraries. I have written a very small libtool + autotools example and run the following but I'm always getting the output shown below the commands. Note, that the same works fine in a linux/x86-64 and I don't have to add --enable-shared in that case, so I guess I don't need --enable-shared either in these tests. COMMANDS: ./configure --prefix=/tmp/test CC=fccpx --host=x86_64 ./configure --prefix=/tmp/test CC=fccpx --host=x86-64 --target=sparc64 ./configure --prefix=/tmp/test CC=fccpx --host=x86_64 --target=sparc64-linux OUTPUT: checking for fccpx option to produce PIC... -DPIC checking if fccpx PIC flag -DPIC works... yes checking if fccpx static flag works... yes checking if fccpx supports -c -o file.o... yes checking if fccpx supports -c -o file.o... (cached) yes checking whether the fccpx linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... cross checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes So, am I doing something wrong when cross-compiling? Or maybe libtool does not understand fccpx? Thank you very much in advance. WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received. http://www.bsc.es/disclaimer ___ https://lists.gnu.org/mailman/listinfo/libtool
