Check dependency resolution for 64 bit linking
Hello,
I try to compile your software library on my own. Unfortunately, I get an error message from the build process after the configuration on my openSUSE 11.1 system. elfring@Sonne:~/Projekte/PPL/trunk> ./configure --enable-optimization --enable-pch && make -j4 ... make[3]: Entering directory `/home/elfring/Projekte/PPL/trunk/src' CXXLD libppl.la /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [libppl.la] Fehler 1 ... elfring@Sonne:~/Projekte/PPL/trunk> file /usr/local/lib/../lib/libstdc++.so /usr/local/lib/../lib/libstdc++.so: symbolic link to `libstdc++.so.6.0.10'
2.6.28.7-default #1 SMP PREEMPT Sun Mar 1 18:21:35 CET 2009 x86_64 x86_64 x86_64 GNU/Linux
I have got the impression that there is a 64 bit compatibility problem. Can it be solved with autoconf macros in your project?
Regards, Markus
Markus Elfring wrote:
I try to compile your software library on my own. Unfortunately, I get an error message from the build process after the configuration on my openSUSE 11.1 system. elfring@Sonne:~/Projekte/PPL/trunk> ./configure --enable-optimization --enable-pch && make -j4 ... make[3]: Entering directory `/home/elfring/Projekte/PPL/trunk/src' CXXLD libppl.la /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [libppl.la] Fehler 1 ... elfring@Sonne:~/Projekte/PPL/trunk> file /usr/local/lib/../lib/libstdc++.so /usr/local/lib/../lib/libstdc++.so: symbolic link to `libstdc++.so.6.0.10'
2.6.28.7-default #1 SMP PREEMPT Sun Mar 1 18:21:35 CET 2009 x86_64 x86_64 x86_64 GNU/Linux
I have got the impression that there is a 64 bit compatibility problem. Can it be solved with autoconf macros in your project?
Hi Markus,
you are not saying which version of the PPL you are trying to compile. From the path "~/Projekte/PPL/trunk" I guess you are using a version that, at some stage, was the HEAD of the master branch in the central Git repository. If that is the case, what you observe can be explained by the use of an old version of Libtool. So:
1) if you really want to stay on the bleeding edge, using the Git versions, try updating Libtool to the latest available version; 2) otherwise, download an official ppl-0.10.2 tarball and try with that one.
Notice also that:
a) --enable-optimization is the default; b) --enable-pch did not receive much testing since when we realized that it does not speed up building the library in a significant way.
All the best,
Roberto
you are not saying which version of the PPL you are trying to compile.
I try the build process from the results of the command "git clone". http://www.cs.unipr.it/ppl/Download/Git#read-only-access
- if you really want to stay on the bleeding edge, using the Git
versions, try updating Libtool to the latest available version;
I get the following informations. Repository: @System Name: libtool Version: 2.2.6-1.35 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: up-to-date Installed Size: 2.3 M Summary: A Tool to Build Shared Libraries
Does the configuration script contain a check if this software is recent enough?
a) --enable-optimization is the default;
Would you like to add the detail to the help description which level should be the default?
Regards, Markus
Markus Elfring wrote:
you are not saying which version of the PPL you are trying to compile.
I try the build process from the results of the command "git clone". http://www.cs.unipr.it/ppl/Download/Git#read-only-access
OK: please take into account that Git access is meant for developers and for those closely following the PPL development (and, hence, familiar with the tools, conventions, and so forth).
- if you really want to stay on the bleeding edge, using the Git
versions, try updating Libtool to the latest available version;
I get the following informations. Repository: @System Name: libtool Version: 2.2.6-1.35 Arch: x86_64 Vendor: openSUSE Installed: Yes Status: up-to-date Installed Size: 2.3 M Summary: A Tool to Build Shared Libraries
This is OK.
Does the configuration script contain a check if this software is recent enough?
Not now. But this is an oversight and should be fixed.
a) --enable-optimization is the default;
Would you like to add the detail to the help description which level should be the default?
It is documented in README.configure. All the best,
Roberto
P.S. Please direct all PPL-related messages to ppl-devel@cs.unipr.it
- otherwise, download an official ppl-0.10.2 tarball and try with
that one.
I get the same unexpected error message.
... mv -f .deps/ppl-config.Tpo .deps/ppl-config.Po /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [libppl.la] Fehler 1 make[3]: Leaving directory `/home/elfring/Projekte/PPL/0.10.2/src' ...
Will any fine-tuning be needed in the configuration script? http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=blob;f=configure.ac;h=...
Regards, Markus
Markus Elfring wrote:
- otherwise, download an official ppl-0.10.2 tarball and try with
that one.
I get the same unexpected error message.
... mv -f .deps/ppl-config.Tpo .deps/ppl-config.Po /usr/local/lib/../lib/libstdc++.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[3]: *** [libppl.la] Fehler 1 make[3]: Leaving directory `/home/elfring/Projekte/PPL/0.10.2/src' ...
Hi Markus,
I believe there is something wrong with your installation of GCC. The path usr/local/lib/../lib/libstdc++.so makes me think that you (or someone else) installed GCC from sources. What you observe could be explained if you are compiling for Intel 80386 and /usr/local/lib/../lib/libstdc++.so is (a symbolic link to) an x86-64 library or the other way around. Please check using file(1). Here is, e.g., what happens on my system:
$ cd /usr/lib $ file libstdc++.so.6.0.10 libstdc++.so.6.0.10: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped $ cd ../lib64 $ file libstdc++.so.6.0.10 libstdc++.so.6.0.10: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
Can you actually compile and link any C++ program with that compiler? A test with an "hello world" program should suffice.
Will any fine-tuning be needed in the configuration script? http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=blob;f=configure.ac;h=...
Not that I know. All the best,
Roberto
The path usr/local/lib/../lib/libstdc++.so makes me think that you (or someone else) installed GCC from sources.
Yes, you are right. I built the release 4.3.3 also myself.
Please check using file(1).
elfring@Sonne:~> for X in lib lib64 local/lib local/lib64; do file /usr/$X/libstdc++.so.6.0.10; done /usr/lib/libstdc++.so.6.0.10: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped /usr/lib64/libstdc++.so.6.0.10: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped /usr/local/lib/libstdc++.so.6.0.10: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped /usr/local/lib64/libstdc++.so.6.0.10: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Can you actually compile and link any C++ program with that compiler? A test with an "hello world" program should suffice.
Yes - The following example works as expected.
#include <iostream> int main(void) { std::cout << "Test" << std::endl; return 0; }
elfring@Sonne:~/Projekte/GNU/GCC> /usr/local/bin/g++ Test.cpp && ./a.out Test
The compiler software passed the usual test cases (make check) on my system, too.
Regards, Markus
Markus Elfring wrote:
The path usr/local/lib/../lib/libstdc++.so makes me think that you (or someone else) installed GCC from sources.
Yes, you are right. I built the release 4.3.3 also myself.
Please check using file(1).
elfring@Sonne:~> for X in lib lib64 local/lib local/lib64; do file /usr/$X/libstdc++.so.6.0.10; done /usr/lib/libstdc++.so.6.0.10: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped /usr/lib64/libstdc++.so.6.0.10: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped /usr/local/lib/libstdc++.so.6.0.10: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped /usr/local/lib64/libstdc++.so.6.0.10: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
My guess is that you are compiling the PPL for x86-64 and, for some reason, /usr/local/lib/libstdc++.so.6.0.10, which is an 80386 object, is in the way. I do not know why this happens: the answer is probably contained in config.log.
My guess is that you are compiling the PPL for x86-64 and, for some reason, /usr/local/lib/libstdc++.so.6.0.10, which is an 80386 object, is in the way. I do not know why this happens: the answer is probably contained in config.log.
It seems that I stumble on an open issue which was also reported by other software developers several times.
Examples: - libtool problem on system with 32 and 64 bit libraries http://lists.gnu.org/archive/html/libtool/2009-04/msg00016.html
- Another libtool problem with 64-bit build on a bi-arch system http://lists.gnu.org/archive/html/libtool/2008-09/msg00049.html
- Debugging Libtool's Insistence on Sourcing a Library from /usr/lib Rather Than LDFLAGS http://lists.gnu.org/archive/html/libtool/2008-02/msg00073.html
- Wrong libstdc++ picked http://lists.gnu.org/archive/html/libtool/2007-04/msg00060.html
Would you like to add any workarounds to your configuration script to find the expected library directories? How are the chances to fix the involved tools?
Regards, Markus
Markus Elfring wrote:
My guess is that you are compiling the PPL for x86-64 and, for some reason, /usr/local/lib/libstdc++.so.6.0.10, which is an 80386 object, is in the way. I do not know why this happens: the answer is probably contained in config.log.
It seems that I stumble on an open issue which was also reported by other software developers several times.
Examples:
libtool problem on system with 32 and 64 bit libraries http://lists.gnu.org/archive/html/libtool/2009-04/msg00016.html
Another libtool problem with 64-bit build on a bi-arch system http://lists.gnu.org/archive/html/libtool/2008-09/msg00049.html
Debugging Libtool's Insistence on Sourcing a Library from /usr/lib
Rather Than LDFLAGS http://lists.gnu.org/archive/html/libtool/2008-02/msg00073.html
- Wrong libstdc++ picked http://lists.gnu.org/archive/html/libtool/2007-04/msg00060.html
Would you like to add any workarounds to your configuration script to find the expected library directories?
Not blindly. Can I have access to the machines where this happens? I think the problem is in your installation of GCC in /usr/local.
How are the chances to fix the involved tools?
My experience with the Libtool people are quite positive. All the best,
Roberto
Can I have access to the machines where this happens?
I am unsure if we can setup a reliable connection into my private machine. I guess that it would be easier to clarify assignments to the configuration variable "extra_libraries".
My experience with the Libtool people are quite positive.
Does the build for the 64 bit processor architecture always succeed in your software development environment?
Regards, Markus
Markus Elfring wrote:
Does the build for the 64 bit processor architecture always succeed in your software development environment?
Yes. But not only mine: lots of people and with different distributions.
Yes. But not only mine: lots of people and with different distributions.
I could build your software for the 64 bit processor architecture also on my system after the command "LDFLAGS='-L/usr/local/lib64' ./configure ". All tests (make check) passed. Do you override any linker parameters in your configurations?
Regards, Markus
Markus Elfring wrote:
Yes. But not only mine: lots of people and with different distributions.
I could build your software for the 64 bit processor architecture also on my system after the command "LDFLAGS='-L/usr/local/lib64' ./configure ". All tests (make check) passed.
Good!
Do you override any linker parameters in your configurations?
No.
Good!
Unfortunately, I get the message "Libraries have been installed in: /usr/local/lib" from the command "make install". I would expect that the directory "/usr/local/lib64" should be automatically used from my current build configuration. Can the generated binaries be installed for all supported processor architectures in parallel?
Regards, Markus
Markus Elfring wrote:
Good!
Unfortunately, I get the message "Libraries have been installed in: /usr/local/lib" from the command "make install". I would expect that the directory "/usr/local/lib64" should be automatically used from my current build configuration.
You should use the configure option --libdir=/usr/local/lib64
Can the generated binaries be installed for all supported processor architectures in parallel?
Not that I know. If you want to support multiple architectures on the same machine, I suggest you look at how we do that on Fedora:
http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=tree;f=fedora;hb=HEAD
Will any fine-tuning be needed in the configuration script? http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=blob;f=configure.ac;h=...
Not that I know.
I suggest to consider some updates for your configuration script. - How do you think about to move any auxiliary files into a subdirectory? - Would you like to complete any quoting for macro parameters?
Regards, Markus
Markus Elfring wrote:
Will any fine-tuning be needed in the configuration script? http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=blob;f=configure.ac;h=...
Not that I know.
I suggest to consider some updates for your configuration script.
- How do you think about to move any auxiliary files into a subdirectory?
Which file would you move and why?
- Would you like to complete any quoting for macro parameters?
What would we gain from this extra quoting? For example, what is the advantage of
AC_MSG_RESULT([quick])
over
AC_MSG_RESULT(quick)
?
Your patch seems also to suggest that `dnl' is a better comment delimiter than `#'. Is this the case? Thanks,
Roberto
Which file would you move and why?
I propose to group the auxiliary files that belong to the macro "AC_CONFIG_AUX_DIR" into their own subdirectory. Would you like to support a clearer file hierarchy?
What would we gain from this extra quoting? For example, what is the advantage of
AC_MSG_RESULT([quick]) over AC_MSG_RESULT(quick) ?
It ensures that the given strings are not interpreted by the M4 processor as macro names. I suggest to be more explicit where an additional level of macro expansion will not be required. http://www.gnu.org/software/autoconf/manual/html_node/Quotation-and-Nested-M... http://autogen.sourceforge.net/acquoting.html
Your patch seems also to suggest that `dnl' is a better comment delimiter than `#'. Is this the case?
This key word has got the effect that some lines will not be copied to the generated configure script.
Regards, Markus
participants (2)
-
Markus Elfring -
Roberto Bagnara