This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
report and queries on building 64bit + 32bit bi-arch amd64/i686 multilib glibc-2.8.90+ with gcc-4.2.4 on x86_64 AMD-TL64 linux-2.6.26+ GNU Linux
- From: Jason Vas Dias <jason dot vas dot dias at gmail dot com>
- To: libc-help at sourceware dot org
- Date: Sat, 7 Jun 2008 22:36:29 -0400
- Subject: report and queries on building 64bit + 32bit bi-arch amd64/i686 multilib glibc-2.8.90+ with gcc-4.2.4 on x86_64 AMD-TL64 linux-2.6.26+ GNU Linux
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-disposition:reply-to :organization:to:subject:user-agent:mime-version:date:content-type :content-transfer-encoding:message-id:from; bh=ik/7ZIIUs50c56+u9D6UOUcvWbbcuX6IMQHG9bXbchk=; b=ezP4TfpaMVvfpzEXZCif/zW1lospCeo4rVSfXuQSV7mJMrAnDwYTCotmtPGalnTFue V/KpQWkBr4ZrhMfS4Vf9o79tytXVvMZUJ4HNb5ptYtBiJBuo58dEArChusUhQg2vBSyG xFiMRWUr8OcS7QOb9NVzV3wiDd6F9J9mQ2Oqk=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-disposition:reply-to:organization:to:subject:user-agent :mime-version:date:content-type:content-transfer-encoding:message-id :from; b=dyZPmmvmMuB8aREy1YqkafbHevQtCFS23jqrBy1cdPu2k6/J7E6pK8h3pRbD2SSSvO KVi52tAIxBqb8M9dlvMlkE2wDTsdf2wVjAxeYJRHkHb9lpcayZkvBoXiMx2xYQycC/Q5 yKhkUAHXcFxxBA6gqcdZZnSd2Ybka3CEvI8io=
- Organization: at&t labs research inc.
- Reply-to: jvdias at research dot att dot com
Report and questions on building from glibc-2.8-20080602+ on x86_64 GNU/Linux 2.6.26+ (Gentoo/My_Own_distro...):
---------- Forwarded Message ----------
Subject: git 200806020+ crypt addon deprecated but required + 64/32-bit multilib woes ?
Date: Sunday 01 June 2008
From: Jason Vas Dias <jvdias@research.att.com>
To: libc-alpha@sourceware.org
When I attempt to build the HEAD branch after
cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/glibc co libc
for an Linux x86_64 machine, under kernel 2.6.26-rc3, glibc-2.8
(built OK from release tarball) with gcc-4.2.4 , binutils 2.18.50.20080526,
at first any valid configure invocation fails when ${SRCDIR}/crypt exists:
$ (setarch i686; export ASFLAGS='-Wa,--32,-march=i686' CFLAGS=${ASFLAGS}' -march=i686 -mtune=generic -O -g -pipe -m96bit-long-double'
GCC='/usr/libexec/gcc/i686-pc-linux-gnu/4.2.4/gcc -m32' CC=${GCC}
CPPFLAGS=-I/usr/include/32; LDFLAGS='-melf_i386';
../configure --prefix=/usr --libdir=/usr/lib32 --bindir=/usr/bin/32 --includedir=/usr/include/32 --sysconfdir=/etc/32 --datadir=/usr/share/32 --enable-shared \
--enable-threads=posix --enable-tls --with-binutils='/usr/bin/32' \
--enable-targets='i686-pc-linux-gnu' --host='i686-pc-linux-gnu' --host='i686-pc-linux-gnu' --target='i686-pc-linux-gnu' --with-cpu='i686')
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
configure: error:
*** It seems that you're using an old `crypt' add-on. crypt is now
*** part of glibc and using the old add-on will not work with this
*** release. Start again with fresh sources and without the old
*** `crypt' add-on.
The same happens for the 64-bit build, which was intended to have been an dual-arch build :
$ GCC='/usr/libexec/gcc/x86_64-pc-linux-gnu/4.2.4/gcc -m64' CC=${GCC} ASFLAGS='-Wa,--64' LDFLAGS='-Wl,-melf_x86_64' CFLAGS='-march=native -mtune=native -O -g -pipe'
../configure --prefix=/usr --libdir=/usr/lib64 --enable-shared --enable-threads=posix --enable-tls --with-binutils=/usr/bin \
--enable-targets='x86_64-pc-linux-gnu i686-pc-linux-gnu' --enable-multilib --host='x86_64-pc-linux-gnu'
Both /lib32/libcrypt.so.1 and lib64/libcrypt.so.1 were valid sym-links to glibc-2.8+ libcrypt-2.8+.so objects, with /lib being a link to /lib64,
and I wanted the locale shared objects to be installed under /usr/share/32 - had not yet been installed there during configure - they are correctly
built during the build.
So I do
$ mv ../crypt ../not-crypt
and then configure and build, until it fails because ../crypt does not exist;
then restoring ../crypt allows the build to succeed.
Then using gcc-4.2.4, for the 32-bit build, ONLY during the i686 glibc build, glibc's translation of
the GCC atomic built-ins :
__sync_fetch_and_add to __sync_fetch_and_add_4 and
__sync_fetch_val_compare_and_swap to __sync_fetch_val_compare_and_swap_acq
__sync_fetch_bool_compare_and_swap to __sync_fetch_bool_compare_and_swap_acq
are NOT FOUND during the libc.so link phase, but ARE found during a build of this
program under gcc-4.2.4 -m32 and -m64:
$ echo ' unsigned u_dec(unsigned u) { int u2=u; __sync_fetch_and_add_4(&u,-1); __sync_fetch_val_compare_and_swap(&u2,&u,0); return u; }
int main(){ unsigned u; return (int)u_dec(u); }
' |
gcc {both -m32 and -m64 work here!} - -o t;
So I added '-L/usr/lib/gcc/${i686/x86_64}-pc-linux-gnu' to LDFLAGS in the Makefile for libc.so and it linked OK -
but this cannot be modified globally .
These were then the ONLY errors in the build, and then "make install" succeeded.
/usr/lib{/gcc,exec/%{m32:i686}%{!m32:x86_64}-pc-linux-gnu/gcc-4.3.0} do exist, but ONLY the gcc-4.2.4 directories were in my $PATH -
No /usr/lib{32,64}/libgcc* libraries exist, and they can ONLY be found in the /usr/lib/gcc/*/[43].[3-8].[0-9]{,/32} directories.
I am trying to put together a multi-arch build environment for (gcc-3.3+.x - 4.3.x) / glibc-2.[5-8].x x86/x86_64 -
(glibc libraries 2.5, 2.6.1, 2.7, 2.8 also existed in /lib{32,64} ).
Anyone seen this / got any fixes / workarounds ?
Otherwise I'll raise a bug and maybe develop a fix.
It seems that better handling of auto-guessing the required add-ons and the correct gcc library path
is required during configure for the non-distro GNU build - this really ought to be quite easy to fix -
perhaps with true support for '--enable-multilib' configure option ?
Yes, the above bugs can be worked around, but are a pain ! Should I raise bugzillas about them ? Has anyone else done so ?
After *-2.8.90.so build after workarounds applied and 'make install' runs, everything works OK, except for this message from programs or
libraries that had linked to previous *-2.8.so objects, eg.:
$ perl -v
perl: /lib64/libcrypt.so.1: no version information available (required by /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/CORE/libperl.so)
perl: /lib64/libcrypt.so.1: no version information available (required by /usr/lib/perl5/5.10.0/x86_64-linux-thread-multi/CORE/libperl.so)
The configure had been unable to guess that the ${GCC} compiler had enabled versioning only for libcrypt, not for the other subdirs - rebuilding
libcrypt with --enable-versioning fixes ?
(BTW, the actual configure I used for the x86_64 /usr/lib64 install was:
$ ../configure --prefix=/usr --libdir=/usr/lib64 --enable-shared --enable-threads=posix --enable-tls --with-binutils=/usr/bin \
--enable-targets='x86_64-pc-linux-gnu i686-pc-linux-gnu' --enable-multilib --host=x86_64-pc-linux-gnu x86_64-pc-linux-gnu
The 'enable-multilib' and 'enable-targets' settings come from those I used for the target binutils and gcc ,
but actually appear to have no effect for glibc ? ie. it does not also build the i686 arch.
../configure --help provides no clues whatsoever about how to successfully achieve a dual-architecture i686 and x86_64 build and installation , and
there seems to be little online help on this subject.
In conclusion,
#1 on my glibc wish-list would be support for a configure argument such as:
o --enable-biarch='32 64' or just '--enable-multilib'
which would build and install 64-bit objects into the first library under ${DESTDIR}/${PREFIX} listed in /etc/ld.so.conf (without destdir)
that contains a 64-bit glibc installation, and 32-bit object into the first 32-bit glibc installation listed in /etc/ld.so.conf on the
target or as specified with:
o --libdir32=/usr/lib32 --libdir64=/usr/lib64 ...
Is anything like the above on the cards for the GNU / non-distro release ?
Worthwhile my developing fixes for the above issues and submitting to libc-alpha ?
Thanks in advance for any help / suggestions offered,
Jason Vas Dias<jvdias@research.att.com> / jason.vas.dias@gmail.com
-------------------------------------------------------