Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
AMD 64 system no longer backwards compatible.
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Duplicate Threads
View previous topic :: View next topic  
Author Message
Garrett0718
n00b
n00b


Joined: 25 May 2005
Posts: 47
Location: Oklahoma State University

PostPosted: Sun Jun 12, 2005 11:07 pm    Post subject: AMD 64 system no longer backwards compatible. Reply with quote

For a while, the doom3 demo, enemy territorry, and americas army ran flawlessly. To the best of my knowledge, the only thing I did around the time that every 32 bit binary quit working, was to emerge the emul-linux-x86-baselibs and other packages in that directory. These were dependencies of enemy territory, and should have been installed anyway, so I do not see how that should have changed my system.

Edit: Just so it is unambiguous, other non openGL 32 bit binaries (firefox, openoffice) do not work either.

Enemy Territory now crashes on

/usr/games/bin/et: line 4: /opt/enemy-territory/et.x86: No such file or directory
/usr/games/bin/et: line 4: /opt/enemy-territory/et.x86: Success

The first few lines of /opt/enemy-territory/et.x86 are

/lib/ld-linux.so.2
libdl.so.2
dlerror
dlclose
dlsym
__gmon_start__
dlopen

Here is the output of emerge --info

emerge --info
Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r7 x86_64)
=================================================================
System uname: 2.6.11-gentoo-r7 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.4.16
Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, May 19 2005, 03:26:27)]
dev-lang/python: 2.3.4-r1
sys-apps/sandbox: [Not Present]
sys-devel/autoconf: 2.59-r6, 2.13
sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.5
sys-devel/binutils: 2.15.92.0.2-r7
sys-devel/libtool: 1.5.16
virtual/os-headers: 2.6.8.1-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-O2 -march=athlon64"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon64"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://gentoo.osuosl.org/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo/ http://gentoo.chem.wisc.edu/gentoo/ ftp://gentoo.chem.wisc.edu/gentoo/ http://cudlug.cudenver.edu/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="amd64 X acpi aim alsa berkdb bitmap-fonts cdr crypt cups doc dvd dvdr dvdread emul-linux-x86 esd fam font-server fortran gif gpm gtk imagemagick imlib ipv6 java joystick jp2 jpeg junit kde lzw lzw-tiff mad motif mozilla mp3 ncurses nls nvidia ogg opengl oss pam perl png python qt readline sdl ssl tcltk tcpd tiff truetype truetype-fonts type1-fonts usb userlocales vorbis xml xml2 xmms xpm xrandr xv zlib userland_GNU kernel_linux elibc_glibc"
Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY


For some reason, multilib does not show up here, even though it is declared in /etc/make.conf.

Additionally, at the same time this problem arose, emerge started failing on an improper upgrade error. I found the error in /etc/make.profile/profile.bashrc, and more or less fixed the problem with emerge by commenting the whole thing out:

# Make sure they updated to 2005.0 properly
#if [ -L /lib32 -o -L /usr/lib32 ] && [ ${PORTAGE_CALLER} != "repoman" ] ; then
# eerror "It appears you have switched to the 2005.0 profile without follo
wing"
# eerror "the upgrade guide. Please see the following URL for more inform
ation:"
# eerror "http://www.gentoo.org/proj/en/base/amd64/2005.0-upgrade-amd64.xm
l"
# exit 1
#fi

So now emerge works fine. I assume that condition that it checks and fails is at the very least related to my present problem, but I do not know exactly how to interpret "if [ -L /lib32 -o -L /usr/lib32 ]}"

I still cannot run any 32-bit binaries. I assume that nothing is looking in the right place for the 32-bit libraries, but I have no idea how to fix it.
_________________
AMD 64 3200+ on GA-KV8T800 MB
1 GB PC 3200
GeForce FX 7800GS w/256 MB
Back to top
View user's profile Send private message
Garrett0718
n00b
n00b


Joined: 25 May 2005
Posts: 47
Location: Oklahoma State University

PostPosted: Mon Jun 20, 2005 2:35 am    Post subject: Reply with quote

Any guesses at all would be appreciated. I am about to have to write a few scientific papers for my summer job, and as it stands openoffice will not run. In the next week I will either be dual booting for reasons other than the occasional game, or else I will have to throw in another hard drive and triple boot with a 32 bit linux. Taking random suggestions from people who might not even be as capable as I am would certainly be favorable to the first, and random suggestions from people who do actually know what they are doing would be favorable to the second.
_________________
AMD 64 3200+ on GA-KV8T800 MB
1 GB PC 3200
GeForce FX 7800GS w/256 MB
Back to top
View user's profile Send private message
jwagner26
n00b
n00b


Joined: 23 Dec 2004
Posts: 10

PostPosted: Thu Jun 23, 2005 4:51 am    Post subject: Reply with quote

I'm not 100% sure, but I thought the purpose of multilib in 2005.0 was to eliminate the need for the emul-linux-x86* packages. Perhaps you messed up your /usr/lib* files by emerging the emul-linux-x86-baselibs. Not sure how to fix it, though as I'm still a bit of a Gentoo noob. I would probably try emerge unmerge emul-linux-x86-baselibs and any other emul-linux-x86 packages and if that doesn't fix things, which it probably won't, emerge -av world. That's probably unnecessary and may not fix things, but that's what I would try.
Back to top
View user's profile Send private message
Konsti
l33t
l33t


Joined: 10 Dec 2002
Posts: 691

PostPosted: Thu Jun 23, 2005 7:08 am    Post subject: Reply with quote

At the moment multilib only abandones the emul*glibc package.
What emul Packages do you have still installed?
What does "ldd opt/enemy-territory/et.x86" say?
Why don't you emerge OOo natively by source and let emerge it compile against amd64 natively?
Back to top
View user's profile Send private message
canal
Apprentice
Apprentice


Joined: 28 Sep 2004
Posts: 203

PostPosted: Thu Jun 23, 2005 7:18 am    Post subject: Reply with quote

Konsti wrote:
Why don't you emerge OOo natively by source and let emerge it compile against amd64 natively?

Huh ??? DO you know how to emerge 32bit OOo natively on AMD64 ??? This is news to me.

P.S. OOo 1.x is not 64bit clean AFAIK and OOo 2.0 is still in "beta" state...
Back to top
View user's profile Send private message
Konsti
l33t
l33t


Joined: 10 Dec 2002
Posts: 691

PostPosted: Thu Jun 23, 2005 8:23 am    Post subject: Reply with quote

No I did not know. And it was only a question by me, I don't know everything :wink:
Back to top
View user's profile Send private message
kallamej
Administrator
Administrator


Joined: 27 Jun 2003
Posts: 4920
Location: Gothenburg, Sweden

PostPosted: Thu Jun 23, 2005 10:23 am    Post subject: Reply with quote

Moved from Portage & Programming to Gentoo on AMD64, perhaps there's someone who knows everything here. @OP, don't know the status of your following the upgrade instructions as mentioned in your other thread.
Back to top
View user's profile Send private message
lookup
n00b
n00b


Joined: 03 Feb 2005
Posts: 17

PostPosted: Thu Jun 23, 2005 11:29 am    Post subject: Reply with quote

I came across the same problem just a couple of days ago.
I solved it by reemerging emul-linux-x86-glibc. Not sure though if that is the best
way to solve it, but it works for me :D .
Back to top
View user's profile Send private message
rambam
Tux's lil' helper
Tux's lil' helper


Joined: 16 Oct 2004
Posts: 104
Location: /dev/null

PostPosted: Thu Jun 23, 2005 2:06 pm    Post subject: Reply with quote

Garrett0718 wrote:
Any guesses at all would be appreciated. I am about to have to write a few scientific papers for my summer job, and as it stands openoffice will not run.


Ahem.....
Scientific papers are better written using Latex.
_________________
The soul, when accustomed to superfluous things, acquires a strong habit of desiring things. This desire is without limit, while things which are necessary are few in number.
Back to top
View user's profile Send private message
spielc
Guru
Guru


Joined: 20 Apr 2004
Posts: 452

PostPosted: Thu Jun 23, 2005 2:39 pm    Post subject: Reply with quote

Konsti wrote:
At the moment multilib only abandones the emul*glibc package.


This is not 100% true. Atm the only REAL multilib enabled package is glibc (that's why glibc is compiled at least twice now when you do a
Code:
emerge glibc
since 2005.0 on the amd64-arch) but you still have the dummy-package emul-linux-x86-glibc-1000. The developers are working on the other emul-packages but it will take time till these are really multilib-enabled packages
Back to top
View user's profile Send private message
Garrett0718
n00b
n00b


Joined: 25 May 2005
Posts: 47
Location: Oklahoma State University

PostPosted: Thu Jun 23, 2005 5:36 pm    Post subject: Reply with quote

After the install, I think I had emul-linux-x86 declared as a use flag, but sadly I am not sure now. I know that I did not have multilib declared, and that the above named 32-bit binaries worked flawlessly (though now that I think about it, I am not so sure about openoffice, but to emerge on AMD 64, try emerge openoffice-bin), so emulation was likely enabled. Now, if I remove emul and replace with multilib, multilib does not show up in emerge info. I have tried setting the emul flag and reemerging everything and it changes nothing. I will verify this when I get home this evening, but I think that even without either flag declared and the emulation packages unmerged, installing a 32 bit app will emerge them as dependencies. I have not tried reemerging glibc yet, but what flags should I have declared prior to doing so?

And I know I should use Latex, but openoffice is so damn easy and comes with a very capable equation editor. I have not personally tried Latex though, and probably will, especially if this problem is not resolved soon.

And once again, if anyone simply knows how to interpret the following syntax from /etc/make.profile/profile.bashrc,
if [ -L /lib32 -o -L /usr/lib32 ] ,
I am sure that is at least related to my problem, but personally have no idea what it means. I have just tried linking the directories various ways, and obviously this has accomplished nothing.
_________________
AMD 64 3200+ on GA-KV8T800 MB
1 GB PC 3200
GeForce FX 7800GS w/256 MB
Back to top
View user's profile Send private message
spielc
Guru
Guru


Joined: 20 Apr 2004
Posts: 452

PostPosted: Thu Jun 23, 2005 6:14 pm    Post subject: Reply with quote

Garrett0718 wrote:
After the install, I think I had emul-linux-x86 declared as a use flag, but sadly I am not sure now. I know that I did not have multilib declared, and that the above named 32-bit binaries worked flawlessly (though now that I think about it, I am not so sure about openoffice, but to emerge on AMD 64, try emerge openoffice-bin), so emulation was likely enabled. Now, if I remove emul and replace with multilib, multilib does not show up in emerge info. I have tried setting the emul flag and reemerging everything and it changes nothing. I will verify this when I get home this evening, but I think that even without either flag declared and the emulation packages unmerged, installing a 32 bit app will emerge them as dependencies. I have not tried reemerging glibc yet, but what flags should I have declared prior to doing so?

And I know I should use Latex, but openoffice is so damn easy and comes with a very capable equation editor. I have not personally tried Latex though, and probably will, especially if this problem is not resolved soon.

And once again, if anyone simply knows how to interpret the following syntax from /etc/make.profile/profile.bashrc,
if [ -L /lib32 -o -L /usr/lib32 ] ,
I am sure that is at least related to my problem, but personally have no idea what it means. I have just tried linking the directories various ways, and obviously this has accomplished nothing.


I would first make sure the upgrade to 2005.0 really succeded, before i would change anything that the system put for you into a configuration file... If the upgrade to 2005.0 succeded

btw. there is no such thing as a emul-flag (neither USE-flag nor anything else) what you probably meant was the multilib use-flag but if the profile-update worked you don't have to add it as this use-flag is under portage's control now (means you can't set/unset this USE-Flag manually...)
Back to top
View user's profile Send private message
Garrett0718
n00b
n00b


Joined: 25 May 2005
Posts: 47
Location: Oklahoma State University

PostPosted: Thu Jun 23, 2005 7:30 pm    Post subject: Reply with quote

"emul" was referring to emul-linux-x86, and I did not upgrade; I just started getting that error at the same time I lost backwards compatibility. The installation is about one month old.

At least that explains why adding multilib to make.conf does nothing to emerge --info.
_________________
AMD 64 3200+ on GA-KV8T800 MB
1 GB PC 3200
GeForce FX 7800GS w/256 MB
Back to top
View user's profile Send private message
Garrett0718
n00b
n00b


Joined: 25 May 2005
Posts: 47
Location: Oklahoma State University

PostPosted: Thu Jun 23, 2005 8:58 pm    Post subject: Reply with quote

To verify what was said earlier, emerging Enemy Territory even without emul-linux-x86 declared emerges as dependencies the emulation packages.

Also, emerging glibc fails with the following error in the x86 configure stage. I was not entirely sure how much of this could be relevant, so I have posted a fairly large section. I am curious why it references kernel 2.4.1, but that is probably irrelevant.


>>> Source unpacked.
* Compiling x86 glibc
* Configuring GLIBC for linuxthreads with: --disable-dev-erandom --with-tls --without-__thread --enable-add-ons=linuxthreads,c_stubs,libidn --enable-kernel=2.4.1 --without-cvs
--enable-bind-now
--build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu
--disable-profile
--without-gd
--with-headers=//usr/include
--prefix=/usr
--mandir=/usr/share/man
--infodir=/usr/share/info
--libexecdir=/usr/lib/misc

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
running configure fragment for add-on linuxthreads
running configure fragment for add-on c_stubs
running configure fragment for add-on libidn
checking sysdep dirs... sysdeps/i386/elf linuxthreads/sysdeps/unix/sysv/linux/i386 linuxthreads/sysdeps/unix/sysv/linux linuxthreads/sysdeps/pthread sysdeps/pthread linuxthreads/sysdeps/unix/sysv linuxthreads/sysdeps/unix linuxthreads/sysdeps/i386/i686 linuxthreads/sysdeps/i386 libidn/sysdeps/unix sysdeps/unix/sysv/linux/i386 sysdeps/unix/sysv/linux sysdeps/gnu sysdeps/unix/common sysdeps/unix/mman sysdeps/unix/inet sysdeps/unix/sysv/i386 sysdeps/unix/sysv sysdeps/unix/i386 sysdeps/unix sysdeps/posix sysdeps/i386/i686/fpu sysdeps/i386/i686 sysdeps/i386/i486 sysdeps/i386/fpu sysdeps/i386 sysdeps/wordsize-32 sysdeps/ieee754/ldbl-96 sysdeps/ieee754/dbl-64 sysdeps/ieee754/flt-32 sysdeps/ieee754 sysdeps/generic/elf sysdeps/generic
checking for a BSD-compatible install... /bin/install -c
checking whether ln -s works... yes
checking for i686-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking for i686-pc-linux-gnu-g++... no
checking for i686-pc-linux-gnu-c++... no
checking for i686-pc-linux-gnu-gpp... no
checking for i686-pc-linux-gnu-aCC... no
checking for i686-pc-linux-gnu-CC... no
checking for i686-pc-linux-gnu-cxx... no
checking for i686-pc-linux-gnu-cc++... no
checking for i686-pc-linux-gnu-cl... no
checking for i686-pc-linux-gnu-FCC... no
checking for i686-pc-linux-gnu-KCC... no
checking for i686-pc-linux-gnu-RCC... no
checking for i686-pc-linux-gnu-xlC_r... no
checking for i686-pc-linux-gnu-xlC... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking whether /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/as is GNU as... yes
checking whether /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld is GNU ld... yes
checking for /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/as... /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/as
checking version of /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/as... 2.15.92.0.2, ok
checking for /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld... /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld
checking version of /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld... 2.15.92.0.2, ok
checking for pwd... /bin/pwd
checking for i686-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc
checking version of x86_64-pc-linux-gnu-gcc... 3.4.3, ok
checking for gnumake... no
checking for gmake... gmake
checking version of gmake... 3.80, ok
checking for gnumsgfmt... no
checking for gmsgfmt... gmsgfmt
checking version of gmsgfmt... 0.14.1, ok
checking for makeinfo... makeinfo
checking version of makeinfo... 4.8, ok
checking for sed... sed
checking version of sed... 4.1.4, ok
checking for autoconf... autoconf
checking whether autoconf works... yes
checking whether ranlib is necessary... no
checking LD_LIBRARY_PATH variable... ok
checking whether GCC supports -static-libgcc... -static-libgcc
checking for bash... /bin/sh
checking for gawk... gawk
checking for perl... /usr/bin/perl
checking for install-info... /usr/bin/install-info
checking for bison... /usr/bin/bison
checking for signed size_t type... no
checking for libc-friendly stddef.h... yes
checking whether we need to use -P to assemble .S files... no
checking whether .text pseudo-op must be used... yes
checking for assembler global-symbol directive... .globl
checking for .set assembler directive... yes
checking for assembler .type directive prefix... @
checking for .symver assembler directive... yes
checking for ld --version-script... yes
checking for .previous assembler directive... yes
checking for .protected and .hidden assembler directive... yes
checking whether __attribute__((visibility())) is supported... yes
checking for broken __attribute__((visibility()))... no
checking for broken __attribute__((alias()))... no
checking whether to put _rtld_local into .sdata section... no
checking for .preinit_array/.init_array/.fini_array support... yes
checking for libunwind-support in compiler... no
checking for -z nodelete option... yes
checking for -z nodlopen option... yes
checking for -z initfirst option... yes
checking for -z relro option... yes
checking for -Bgroup option... yes
checking for libgcc_s suffix... _32
checking for --as-needed option... yes
checking whether --noexecstack is desirable for .S files... yes
checking for -z combreloc... yes
checking for -z execstack... yes
checking for -fpie... no
checking for -fno-unit-at-a-time... yes
checking whether cc puts quotes around section names... no
checking for assembler .weak directive... yes
checking whether CFI directives are supported... yes
checking if -g produces usable source locations for assembler-with-cpp... yes
checking for ld --no-whole-archive... yes
checking for gcc -fexceptions... yes
checking for DWARF2 unwind info support... no_registry_needed
checking for __builtin_expect... yes
checking for __builtin_memset... no
checking for redirection of built-in functions... yes
checking for local label subtraction... yes
checking for libgd... no
checking for is_selinux_enabled in -lselinux... no
checking for egrep... grep -E
checking for ANSI C header files... no
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for long double... yes
checking size of long double... configure: error: cannot compute sizeof (long double), 77
See `config.log' for more details.

!!! ERROR: sys-libs/glibc-2.3.4.20041102-r1 failed.
!!! Function glibc_do_configure, Line 709, Exitcode 1
!!! failed to configure glibc
!!! If you need support, post the topmost build error, NOT this status message.
_________________
AMD 64 3200+ on GA-KV8T800 MB
1 GB PC 3200
GeForce FX 7800GS w/256 MB
Back to top
View user's profile Send private message
brankob
Apprentice
Apprentice


Joined: 29 Apr 2004
Posts: 183

PostPosted: Thu Jun 23, 2005 9:49 pm    Post subject: Reply with quote

Ewww, shit. I have that exact error and after trying many things ( like re-emergeing gcc, linux-headers etc) without results, I have hoped to find the answer here... :?


Regards,

Branko
Back to top
View user's profile Send private message
radagast
Apprentice
Apprentice


Joined: 20 Mar 2004
Posts: 217
Location: sydney, .au

PostPosted: Fri Jun 24, 2005 2:46 am    Post subject: Re: AMD 64 system no longer backwards compatible. Reply with quote

Garrett0718 wrote:

# eerror "It appears you have switched to the 2005.0 profile without following"
# eerror "the upgrade guide. Please see the following URL for more information:"
# eerror "http://www.gentoo.org/proj/en/base/amd64/2005.0-upgrade-amd64.xml"
# exit 1
#fi


and so here was i, about to be cheeky and ask whether you had tried following the upgrade guide before you deleted the warning. but i thought i'd better check it myself first. and got a 404 not found.

that's worth a bug report, at least...

i don't think i know anything about that line in profile.bashrc... it's checking whether either of those directories are links. for me they're not. which is why i don't have your problem. that's helpful, isn't it?
Back to top
View user's profile Send private message
Garrett0718
n00b
n00b


Joined: 25 May 2005
Posts: 47
Location: Oklahoma State University

PostPosted: Fri Jun 24, 2005 5:47 am    Post subject: Reply with quote

Ok. Emerging the emulation packages turned /usr/lib32 into a symlink pointing /emul/some_shit_that_isn't_there_anymore/lib32. After uninstalling those packages, I pointed the link /lib32, and that is how it is now. How do I get those libraries back? I just tried emerging the emulation shit again, and copying the corresponding directory to /usr/lib32, and that will let emerge run without the upgrade error and without commenting out system scripts, but that is all it did. All 32-bit programs behave just as they did before, even after reemerging. They also all still install the emulation packages when emerged.

In any case, thanks for all the help so far.

Edit: The /usr/lib32 that I just created survives emerging emulation packages, so I have no idea how this would have changed initially.
_________________
AMD 64 3200+ on GA-KV8T800 MB
1 GB PC 3200
GeForce FX 7800GS w/256 MB


Last edited by Garrett0718 on Fri Jun 24, 2005 7:05 pm; edited 1 time in total
Back to top
View user's profile Send private message
kallamej
Administrator
Administrator


Joined: 27 Jun 2003
Posts: 4920
Location: Gothenburg, Sweden

PostPosted: Fri Jun 24, 2005 10:48 am    Post subject: Reply with quote

You can find the upgrade instructions at http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=1 should they still be necessary for you.
_________________
Please read our FAQ Forum, it answers many of your questions.
irc: #gentoo-forums on irc.freenode.net
Back to top
View user's profile Send private message
Garrett0718
n00b
n00b


Joined: 25 May 2005
Posts: 47
Location: Oklahoma State University

PostPosted: Fri Jun 24, 2005 7:09 pm    Post subject: Reply with quote

In following those directions, even though I have not upgraded, gcc fails on "checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'.", and the script approach fails when it cannot find a lib32/ libsandbox.
_________________
AMD 64 3200+ on GA-KV8T800 MB
1 GB PC 3200
GeForce FX 7800GS w/256 MB
Back to top
View user's profile Send private message
stuartguthrie
n00b
n00b


Joined: 19 Jun 2005
Posts: 58

PostPosted: Tue Jun 28, 2005 11:54 am    Post subject: Reply with quote

I am hitting the same road blocks as Garrett0718

I'm trying to get multilib going and all is awash so far :(
Back to top
View user's profile Send private message
joaander
Tux's lil' helper
Tux's lil' helper


Joined: 30 Apr 2004
Posts: 132

PostPosted: Tue Jun 28, 2005 10:58 pm    Post subject: Reply with quote

Quote:
In following those directions, even though I have not upgraded, gcc fails on "checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'.", and the script approach fails when it cannot find a lib32/ libsandbox.


There were a bunch of posts a while ago about these problems, you could try there. What worked for me was to do the emerge glibc step with the USE flag "nptlonly" set. Note that some of your binary installs might depend on the ntpl glibc, so you will have to take nptlonly back out of your USE flags when you are fully converted to 2005.0 and re-emerge glibc.
Back to top
View user's profile Send private message
Garrett0718
n00b
n00b


Joined: 25 May 2005
Posts: 47
Location: Oklahoma State University

PostPosted: Wed Jun 29, 2005 6:38 pm    Post subject: Reply with quote

Downloading the x86 minimal install CD at the moment. I am not going to wipe the 64 bit installation, but I am going to treat it as a project for a while. Even if everything worked as it should, I would get tired of having to deal with all the masked packages. It is starting to look like my computer will be obselete before its architecture is truly practical.

To comment on a brief tangent that occured earlier in this thread, Lyx is a great frontend for latex if you do not want to bother with the syntax.
_________________
AMD 64 3200+ on GA-KV8T800 MB
1 GB PC 3200
GeForce FX 7800GS w/256 MB
Back to top
View user's profile Send private message
hjh
n00b
n00b


Joined: 20 Jul 2004
Posts: 37

PostPosted: Thu Jun 30, 2005 4:23 am    Post subject: Reply with quote

rambam wrote:
Ahem.....
Scientific papers are better written using Latex.


Off topic I guess, but how do you find using this when you are relying on multiple people to work on a document and it is not just your own learning curve involved? I'd happily migrate to Latex for my own purposes but I am not sure how I would go sharing documents with co-authors who are entirely unlikely to make such a switch.
Back to top
View user's profile Send private message
Shapemaker
n00b
n00b


Joined: 22 Aug 2004
Posts: 64
Location: Finland

PostPosted: Sat Jul 02, 2005 5:53 am    Post subject: glibc and nptl / multilib Reply with quote

As I understand it, glibc is compiled twice, first to enable 32-bit compatibility and secondly 64-bit native. Profiles before 2005.0 achieved that with USE="multilib" flag, but 2005.0+ profiles have it implied, thus the flag is always "on".

Now, if you also have USE="nptl", glibc will also be compiled twice, first with Linux 2.4.x Linuxthreads threading model, secondly with Linux 2.6.x NPTL (Native POSIX Threads Library) support. Linuxthreads live in /lib, NPTL live in /lib/tls (this is tried first by linker). If you have USE="nptlonly", Linuxthreads fallback will not be built at all.

All that comes to is, if you have USE="multilib nptl" [or USE="(-multilib) nptl"], glibc will be built FOUR times, twice for NPTL/Linuxthreads and twice for 32/64-bit.

That said, I had that exact same "cannot compute sizeof long double" error a while ago while trying to emerge glibc. I finally managed to solve that on my own, by rigorously checking library paths and re-merging critical packages.

First check that library paths are correct:
Code:
# ls -la / |grep lib
lrwxrwxrwx    1 root root    5 Jun 17 08:35 lib -> lib64/
drwxr-xr-x    3 root root 1.7K Jun 16 23:35 lib32/
drwxr-xr-x   11 root root 5.5K Jun 29 06:58 lib64/
Code:
# ls -la /usr |grep lib
lrwxrwxrwx    1 root root    5 Jun 17 08:35 lib -> lib64/
drwxr-xr-x    8 root root 2.1K Jun 17 11:27 lib32/
drwxr-xr-x   95 root root  78K Jun 30 09:37 lib64/

If libraries are not where they should be, that will wreak havoc with runtime linker and cause all kinds of problems (as you have already noticed).

/emul directory is strictly for emul-linux-x86-* packages and is not necessary (anymore) for glibc as such. It will only be needed for now until multilib compatibility is achieved with other affected packages (qt, gtk, baselibs and friends) as it is achieved with glibc now. Hence package emul-linux-x86-glibc-1000 is a stub.

My /usr/lib32 was a symlink pointing to /emul/linux/x86/usr/lib and I suppose part of my problems resulted from that. Also, /lib was a directory and /lib64 was a symlink pointing to it. Fixing those, among others, permitted me to bring my 32-bit subsystem back to its knees.

What I did:
- made sure that library paths were as above (browse 2005.0 amd64 stage3 tarball for correct paths)
- if paths weren't ok, I created the necessary directories (lib32 lib64) and symlinks (lib -> lib64), moving files where they belong in the process
- then I switched profile back to 2004.3 and made sure that USE flags contained "multilib" and "nptl"
- after, and only after that, I renamed /emul directory (to /emul.old) and re-merged the emul-linux-x86-* packages I had installed
- then I re-merged the whole toolchain (portage linux-headers glibc binutils-config binutils gcc-config gcc)
- then I switched profile back to 2005.0 by following the guide
- then I removed /emul.old and ran "ldconfig -v |grep error" (to see that linking was ok)
- lo, behold, 32-bit system was back up and kicking

The "long double" error was corrected by having temporarily a "real" emul-linux-x86-glibc package in /emul AND having switched back to old profile while recompiling the toolchain. It took almost two long days for me to sort this out, so beware. A real help is to have binary packages ready for reinstallation by having "buildpkg" in FEATURES in make.conf.
_________________
"Intellectual Property" should be an affront to anyone capable of independent thought.
Back to top
View user's profile Send private message
Shapemaker
n00b
n00b


Joined: 22 Aug 2004
Posts: 64
Location: Finland

PostPosted: Sat Jul 02, 2005 6:01 am    Post subject: Reply with quote

Garrett0718 wrote:
And once again, if anyone simply knows how to interpret the following syntax from /etc/make.profile/profile.bashrc,
if [ -L /lib32 -o -L /usr/lib32 ] ,
I am sure that is at least related to my problem, but personally have no idea what it means. I have just tried linking the directories various ways, and obviously this has accomplished nothing.

From "man bash":
Code:
-L file
       True if file exists and is a symbolic link.

I.e. if /lib32 or /usr/lib32 are symbolic links, bomb out with error.
_________________
"Intellectual Property" should be an affront to anyone capable of independent thought.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Duplicate Threads All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum