Hi, I can't compile freeradius-2.0.2 (Centos RPM is too old for what I need) on Centos 5.1 x86_64. It outputs:
/usr/lib/libltdl.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status
I tried with no success with export CFLAGS=-m64
any idea?
thanks in advance!!
Sergio Belkin wrote:
Hi, I can't compile freeradius-2.0.2 (Centos RPM is too old for what I need) on Centos 5.1 x86_64. It outputs:
/usr/lib/libltdl.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status
Maybe it should look for /usr/lib64/libltdl.so ?
Can't you use the Centos SRPM file as a template for the build process?
Mogens
2008/3/5, Mogens Kjaer mk@crc.dk:
Sergio Belkin wrote:
Hi, I can't compile freeradius-2.0.2 (Centos RPM is too old for what I need) on Centos 5.1 x86_64. It outputs:
/usr/lib/libltdl.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status
Maybe it should look for /usr/lib64/libltdl.so ?
Can't you use the Centos SRPM file as a template for the build process?
Mogens
Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk@crc.dk Homepage: http://www.crc.dk _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Ooops :S How can I do that?
Thanks in advance!
Sergio Belkin wrote:
2008/3/5, Mogens Kjaer mk@crc.dk:
Sergio Belkin wrote:
Hi, I can't compile freeradius-2.0.2 (Centos RPM is too old for what I need) on Centos 5.1 x86_64. It outputs:
/usr/lib/libltdl.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status
That error means you are trying to link against i386 libraries with -m64 ... which you can't do. You need to remove all i[3,4,5,6]86 RPMS from an x86_64 build server except for glibc.i686 and glibc-devel.i386 (and those packages are only needed to build a couple packages).
Maybe it should look for /usr/lib64/libltdl.so ?
Can't you use the Centos SRPM file as a template for the build process?
<snip>
Ooops :S How can I do that?
First thing is that building on x86_64 is quite a PITA.
You will need to either use mock with the appropriate configuration file or you will need to create a build machine that has only x86_64 RPMS (otherwise you will either try (and fail) to link to i386 libraries ... or if you have enough i386 software actually installed (binutils, libgcc, glibc and glibc-devel) then you will actually link against i386 libraries).
This will most likely make your binaries not work, or require mixed software on other installs.
So, I would recommend that you create a build VM or use mock.
Thanks, Johnny Hughes
Johnny Hughes wrote: <snip>
First thing is that building on x86_64 is quite a PITA.
You will need to either use mock with the appropriate configuration file or you will need to create a build machine that has only x86_64 RPMS (otherwise you will either try (and fail) to link to i386 libraries ... or if you have enough i386 software actually installed (binutils, libgcc, glibc and glibc-devel) then you will actually link against i386 libraries).
Hi,
I've seen several posts like Johnny's here saying that i386 libs are preferentially linked instead of x86_64 libs on x86_64 systems.
However I can't reproduce this, and seem to observe the opposite. See: http://lists.centos.org/pipermail/centos/2008-March/095576.html
Also, on a centos5 x86_64 machine ldd --verbose has: SEARCH_DIR("/usr/x86_64-redhat-linux/lib64"); SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/x86_64-redhat-linux/lib"); SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib"); which I understand as giving higher priority to x86_64 libs?
In the thread concerning snmppd linked above, the problem seemed to be caused by the Makefile, which specified -L/usr/lib hence imposing the highest priority for i386 libs.
I guess either I'm missing / misunderstanding something, or there's a widespread use of inappropriate -L directives in makefiles, maybe autogenerated ones eg by automake? In which case it's an automake bug and should be reported.
thanks, Nicolas
-
Johnny Hughes -
Mogens Kjaer -
Nicolas Thierry-Mieg -
Sergio Belkin