Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 71582 - EM64T fails when bootstrapping
Summary: EM64T fails when bootstrapping
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: High major (vote)
Assignee: AMD64 Project
URL:
Whiteboard:
Keywords:
: 73451 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-11-17 12:13 UTC by Ben Lull
Modified: 2005-03-28 09:06 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Lull 2004-11-17 12:13:03 UTC
On a EM64T ssytem (intel xeon 3.2GHz), when installing from a stage1 amd64 tarball, bootstrapping the system fails when atemping to compile sys-devel/gettext-0.14.1.

Here is the GCC error:

gcc -shared  .libs/bindtextdom.o .libs/dcgettext.o .libs/dgettext.o .libs/gettext.o .libs/finddomain.o .libs/loadmsgcat.o .libs/localealias.o .libs/textdomain.o .libs/l10nflist.o .libs/explodename.o .libs/dcigettext.o .libs/dcngettext.o .libs/dngettext.o .libs/ngettext.o .libs/plural.o .libs/plural-exp.o .libs/localcharset.o .libs/relocatable.o .libs/localename.o .libs/log.o .libs/printf.o .libs/osdep.o .libs/plural.o .libs/plural-exp.o .libs/localcharset.o .libs/relocatable.o .libs/localename.o .libs/log.o .libs/printf.o .libs/osdep.o .libs/intl-compat.o  -lc  -march=nocona -mcpu=nocona -Wl,-soname -Wl,libgnuintl.so.3 -o .libs/libgnuintl.so.3.4.0
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.2/../../../../x86_64-pc-linux-gnu/bin/ld: .libs/bindtextdom.o: relocation R_X86_64_32S can not be 
used when making a shared object; recompile with -fPIC
.libs/bindtextdom.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[3]: *** [libgnuintl.la] Error 1
make[3]: Leaving directory `/var/tmp/portage/gettext-0.14.1/work/gettext-0.14.1/gettext-runtime/intl'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/gettext-0.14.1/work/gettext-0.14.1/gettext-runtime'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/var/tmp/portage/gettext-0.14.1/work/gettext-0.14.1/gettext-runtime'
make: *** [all-recursive] Error 1


Here is my make.conf:

# These settings were set by the catalyst build script that automatically built this stage
# Please consult /etc/make.conf.example for a more detailed example
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=nocona -mcpu=nocona"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j2"
GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://vlaai.snt.ipv6.utwente.nl/pub/os/linux/gentoo/ http://gentoo.binarycompass.org http://gentoo.llarian.net/"
USE="mmx 3dnow sse multilib userlocales"


Reproducible: Always
Steps to Reproduce:
1. Boot system
2. Perform normal installation steps (ie. partioning and mounting)
3. type chroot /mnt/gentoo
4. type emerge sync
5. type cd /usr/portage
6. type scripts/bootstrap.sh

Actual Results:  
Compilation failed on sys-devel/gettext-0.14.1

Expected Results:  
Compiled sys-devel/gettext-0.14.1 correctly

System is a Supermicro Dual Intel Xeon 3.2GHz  EM64T.
Comment 1 nobody 2004-11-20 21:39:48 UTC
You might find that comments stupids but...
I wonder what an EM64T could be...

You are using amd64 tarball to install on a intel 32 bits platform ?

If i'm right:
Xeon are 32 bits, made by intel using IA32 arch
And if your computer was using 64bits Intel processors like the Itanium then its arch will be ia64 not x86-64 (the arch for amd 64 bits processors)

Notice also the 3dnow flag shouldn't be present as no Intel processors support these feature.

Seems pretty sure (not certain until someone tells me what is a EM64T system) you're using wrong tarball and that's why you get that error.

If i'm right you should grab an x86-IA32 tarball...
Comment 2 nobody 2004-11-20 23:00:03 UTC
http://www.intel.com/technology/64bitextensions/faq.htm

I can go sleep now, IA32 arch with 64bits processors :)
3dnow still not support, and you should use a IA32 tarball anyway.
Comment 3 Robert Moss (RETIRED) gentoo-dev 2004-11-21 12:41:25 UTC
No, he should be using an EM64T tarball. Unfortunately one doesn't exist yet. Seeing as the amd64 tarball is compiled with -march=x86_64 AFAIK, this should work. However, the real issue here is that the new architecture has thrown up another shared library which isn't PIC and indeed should be. This is a very real bug, I'm afraid, and an IA32 tarball won't help!

This is indeed a gettext Makefiles bug. Anyone got a spare half hour and a nocona?!
Comment 4 Ben Lull 2004-11-21 20:08:46 UTC
I am willing to give access to one of these systems and/or willing to perform tests.  You can contact me via email at ben@easynews.com.  We can set up a means of real time communication via email to do any tested needed.

Also I thought I would mention 2 other things.

1) When building the system with the CFLAG -fPIC, gettext builds correctly.  I was able to get 4 systems up and running this way.

2) When attempting to upgrade the profile from a 2004.2 -> 2004.3, gcc builds fail, which seems to be a seperate bug, but thought I would note it here for reference.

Is there any work being done on a EM64T stage?  If not, what can I do to get one going?  I'm sure my company would be willing to provide perm access to a machine for testing on and I am willing to donate my time for testing builds or whatever else is needed.  We are in the process of migrating to a pure gentoo environment, so having a "supported" stage for em64t would be of interest to us.
Comment 5 nobody 2004-11-22 00:35:12 UTC
From Intel's faq:
Is it possible to write software that will run on Intel's processors with Intel
Comment 6 nobody 2004-11-22 00:35:12 UTC
From Intel's faq:
Is it possible to write software that will run on Intel's processors with Intel® EM64T, and AMD's 64-bit capable processors?
A9: Yes, in most cases. Even though the hardware microarchitecture for each company's processor is different, the operating system and software ported to one processor will likely run on the other processor due to the close similarity of the instruction set architectures.

Anytime i read things like that, reality is: NO.

So 100% compatible with IA32 and got some compatibilities with x86-64...

So: until gcc implement the new instructions set to build 64 bits code for EM64T. You should

- Use a IA32 arch
- Use a stage1 tarball to max out optimization on your cpu
- Use a well craft kernel (build one optimize to smp, ht, p4)
- Use theses flags with gcc 3.4: -mmmx -msse3 -msse2 -msse -march=nocona -mcpu=nocona -mfpmath=sse

You will got the most of what today you could have, but to me, more important, you will never fail into the "Yes, IN MOST CASES"

* You could try also the "-m64" but i'm not sure if results will be safe...
Comment 7 nobody 2004-11-22 05:43:21 UTC
Ok, sad i can't solve your problem personally, but here's why it fail (as Robert Moss said)

Why?
http://gcc.gnu.org/faq.html#picflag-needed

How ? :)
http://bugs.gentoo.org/show_bug.cgi?id=40162

(finally drop some real help after 3 posts).

Comment 8 Robert Moss (RETIRED) gentoo-dev 2004-11-23 10:54:10 UTC
St
Comment 9 Robert Moss (RETIRED) gentoo-dev 2004-11-23 10:54:10 UTC
Stéphane, that bug isn't relevant. It's a classic R_X86_64_32S -fPIC bug. There's been about 100 so far that I'm aware of just on amd64. For various reasons relating to gratuitous use of #ifdef by some packages, these will continue to pop up, even with a relatively minor change in architecture. Note that GCC fully supports the nocona (EM64T) architecture, so that's not something to worry about, and that the above is not a decent set of CFLAGS - it should be more like CFLAGS="-march=nocono -O2 -fprefetch-loop-arrays -pipe".

A patch along the lines of what we're after here is here:

/usr/portage/dev-libs/libmcal/files/libmcal-0.7-fpic.patch

That relates to bug 32591, if you're interested.
Comment 10 SpanKY gentoo-dev 2004-12-05 09:38:45 UTC
*** Bug 73451 has been marked as a duplicate of this bug. ***
Comment 11 nobody 2004-12-23 14:11:54 UTC
This bug should have it's severity raise to blocker and Assign to AMD64 team.

Anyway still thinks removing the "3Dnow" from use will be safer for nocona :D


Robert: if i understand clearly: everyone (well, dev at least) is aware of
1/ the problem 2/ the cause 3/ the solve
1/ is missing -fPIC when building shared libs that use -fPIC, limitation (or feature) of gcc that need -fPIC in that case
2/ ppl remove -fPIC by missusing $ifdef in packages
3/ apply patch to add -fPIC or educ ppl with the issue

Why not educ ppl about the issue and enforce better usage of $ifdef in package ?
Seems better for me than building per problem patch to add the -fPIC

As the example you gave: /usr/portage/dev-libs/libmcal/files/libmcal-0.7-fpic.patch
Using a patch to correct that bug as solve it.
But, if the "teach ppl why not playing with -fPIC" method was used instead, maybe that bug should have never born. (and you saw ~100 times that kind of bug)


Comment 12 SpanKY gentoo-dev 2005-02-06 15:45:20 UTC
has nothing to do with gettext

fact of the matter: we need em64t devs
Comment 13 christophe kumsta 2005-02-07 07:58:05 UTC
Hi,
 tried out the last stage1-amd64-2004.3.tar.bz2 on a Xeon-em64t-ht booted with the amd64-livecd.
with make.conf:
----
CFLAGS="-march=nocona -O3 -msse3 -fomit-frame-pointer -pipe -m64"
CHOST="x86_64-pc-linux-gnu"
CXXFLAGS="${CFLAGS}"
----
As described in em64t intel's technology tutorial.

I've got 1st stage and 2nd stage running properly and after kernel recompilation with "Intel x86-64" processor family, I have now a whole system running in 64bits.

I had many problem at the beginning trying to boot from x86 boot cd or PXE ... and the problem was solved by booting on amd64-livecd kernel (64bits) which gave me a whole 64bits installation toolchains to install 64bits system 

(cross-compiling 64bits from 32bits bootstrap is very very complicated ... and I did not solve my problem by this way).
Comment 14 Raffi Chaglassian 2005-02-17 14:49:14 UTC
that's because EM64T is a different arch than amd64.  

take it out of your make.conf's USE flags
Comment 15 Raffi Chaglassian 2005-02-17 14:55:32 UTC
damn, i'm sorry for that ((#12) dumbass comment.  i failed to scroll down to get the pertininent info (#1-11).  
Comment 16 Danny van Dyk (RETIRED) gentoo-dev 2005-03-27 06:55:25 UTC
Malc: Did you try bootstrapping with the 2005.0 stages ?
Comment 17 Simon Stelling (RETIRED) gentoo-dev 2005-03-28 03:06:13 UTC
is this still an issue with 2005.0?
Comment 18 Alex Howells (RETIRED) gentoo-dev 2005-03-28 09:06:40 UTC
Again, this is a bug which hasn't received response from Ben Lull in over three months. We've had a lot of success reports in #gentoo-amd64 from people building Gentoo on EM64T systems, and all I see at the moment is a couple of unanswered queries and, I quote, "dumbass comments" =)  Bug closed, Ben please feel free to reopen if there is still a problem with your EM64T using 2005.0