Hi,
Thanks to you and Connie for your suggestions. Indeed I had the needed 32-bit libraries already installed; the problem was in the root Makefile as you had also suggested:
ifeq ($(F77),g77)
LIBFRTBEGIN := $(shell $(F77) -print-file-name=libfrtbegin.a)
F77LIBS := $(LIBFRTBEGIN) $(F77LIBS)
endif
That will give you the path to the 64-bit library even if you have configured for running in 32-bit mode. Changing to the following worked:
ifeq ($(F77),g77)
ifeq ($(ARCH),linux)
LIBFRTBEGIN := $(shell $(F77) -m32 -print-file-name=libfrtbegin.a)
F77LIBS := $(LIBFRTBEGIN) $(F77LIBS)
else
LIBFRTBEGIN := $(shell $(F77) -print-file-name=libfrtbegin.a)
F77LIBS := $(LIBFRTBEGIN) $(F77LIBS)
endif
endif
Cheers,
Ken
On Dec 11, 2012, at 1:51 PM, Konstantin Olchanski <[log in to unmask]>
wrote:
> On Tue, Dec 11, 2012 at 01:37:37PM -0600, Connie Sieh wrote:
>> 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.
>>
>
> I routinely cross-compile 32-bit ROOT on 64-bit machines, and indeed lack
> of 32-bit devel packages in the default installation is a minor difficulty.
>
> Here is the complete list of packages I have to install for building 32-bit ROOT (and some other packages)
>
> yum install --skip-broken giflib.i386 giflib.i686 giflib.x86_64 compat-libf2c-34.i386 compat-libf2c-34.i686 mysql-devel mysql-devel.i686 openssl-devel.i686 sysstat "libusb-devel*" unixODBC-devel unixODBC-devel.i686 postgresql-devel libxml2-devel libXpm-devel libgfortran libstdc++-devel.i386 libstdc++-devel.i686 git compat-readline43 "graphviz*" dcap "zlib-*.i686" "libXext-*.i686" "libXtst-*.i686" "tigervnc*" telnet glibc"*" glibc-static.i686 freetype.i686 fontconfig.i686 libpng.i686 libXrender.i686 strace "fftw*" libpng "freetype*" xpdf "xemacs*" tkcvs xterm mutt "*g77*" joe "libXmu*" glibc-devel.i686 libX11-devel.i686 libXpm-devel.i686 libXft-devel.i686 mysql-devel.i686 dcap-devel dcap-devel.i686 gsl-devel gsl-devel.i686 pcre-devel pcre-devel.i686 fontconfig-devel.i686 freetype-devel.i686 libpng-devel.i686 libjpeg-devel.i686 libgfortran.i686 libxml2-devel.i686 h5py gd-devel gd-devel.i686 readline-devel.i686 ncurses-devel.i686 libXdmcp.i686 xorg-x11-fonts"*" rdesktop minicom xfig"*"
>
> (Note that this list is "historical" - packages are added to but never removed from this list)
>
> http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall
>
> The reason for cross-compilation is that we have:
> a) proprietary "32-bit only" libraries
> b) 32-bit VME-form-factor computers that do not have sufficient memory for building ROOT & similar.
>
> And of course cross-compilation of ARM binaries is on the way...
>
> K.O.
>
>
>
>
>
>> -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=
>>>
>
> --
> Konstantin Olchanski
> Data Acquisition Systems: The Bytes Must Flow!
> Email: olchansk-at-triumf-dot-ca
> Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
|
