SCIENTIFIC-LINUX-USERS Archives

December 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Connie Sieh <[log in to unmask]>
Reply To:
Connie Sieh <[log in to unmask]>
Date:
Tue, 11 Dec 2012 13:37:37 -0600
Content-Type:
text/plain
Parts/Attachments:
text/plain (52 lines)
On Tue, 11 Dec 2012, Kenneth Herner wrote:

> Hello,
>
> I am attempting to build root 5.28 as part of testing some legacy =
> software, and for maximum compatibility I would like to use gcc/g++/g77 =
> 3.4 when building. I've installed all of the appropriate compatibility =
> rpms on two machines, one running SLF 5.7 and the other 6.3. When I =
> build on the SLF 5.7 machine everything works fine. When I do the same =
> thing on the SLF 6.3 machine it works until almost the end, where I get =
> the following error:
>
> g77 -m32 -O2  -o bin/g2root main/src/g2root.o \
>                   -Llib lib/libminicern.so \
>                   /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a =
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/32/libg2c.so -lnsl -lm -ldl  =
> -pthread   -rdynamic
>
> /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a: could not read =
> symbols: File in wrong format
> collect2: ld returned 1 exit status

A common reason for the above error is using a 32bit library/archive when 
a 64 bit one is expected and vice versa.

A default install for SL5 installs many i386 packages in addition to the 
x86_64 packages for a x86_64 install.  On SL6 only x86_64 packages are 
installed.

-Connie Sieh

> make: *** [bin/g2root] Error 1
>
> When I do rpm -qf /usr/lib/gcc/x86_64-redhat-linux/3.4.6/libfrtbegin.a I =
> get
>
> compat-gcc-34-g77-3.4.6-19.el6.x86_64
>
> for SLF6, and
>
> compat-gcc-34-g77-3.4.6-4.1.x86_64
>
> for SLF 5.7. Are there any changes in this package that would cause an =
> error such as the one above? It looks like it's the same version of the =
> compiler, but something important must have changed between version 4 =
> and 19. Does anyone have an idea regarding a workaround?
>
> Many thanks,
>
> Ken=
>

ATOM RSS1 RSS2