I'm going through the instructions at http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml and am executing one of the steps in code listing 1.9 Compilation fails with the following error: sparc-sun-solaris2.10-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I../gnulib/lib -I../lib -I../gnulib/lib -I../intl -DLOCALEDIR=\"/scratch/mvandepo/gentoo/usr/share/locale\" -I/scratch/mvandepo/gentoo/usr/include -MT pred.o -MD -MP -MF .deps/pred.Tpo -c -o pred.o pred.c pred.c: In function `file_sparseness': pred.c:662: error: wrong type argument to unary minus make[3]: *** [pred.o] Error 1 The source line causing this is: return p->st_blocks < 0 ? -HUGE_VAL : HUGE_VAL; A possibly related post: http://old.nabble.com/-PATCH--Fix-Savannah-bug--26868:-compilation-error-on-Solaris-x86_64.-td26647116.html emerge --info: Portage 2.2.00.15134-prefix (prefix/sunos/solaris/5.10/sparc, gcc-3.4.3, unavailable, 5.10 sun4u) ================================================================= System uname: Solaris-2.10-sun4u-sparc-32bit-ELF Timestamp of tree: Tue, 19 Jan 2010 22:47:12 +0000 app-shells/bash: 4.0_p35 sys-devel/binutils: 2.20.51.0.4 sys-devel/gcc-config: 1.4.1-r00.2 ACCEPT_KEYWORDS="~sparc-solaris" ACCEPT_LICENSE="* -@EULA" CBUILD="sparc-sun-solaris2.10" CFLAGS="" CHOST="sparc-sun-solaris2.10" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/terminfo" CPPFLAGS="-I/scratch/mvandepo/gentoo/usr/include" CXXFLAGS="" DISTDIR="/scratch/mvandepo/gentoo/usr/portage/distfiles" FEATURES="assume-digests collision-protect distlocks fixpackages news nostrip parallel-fetch preserve-libs protect-owned sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.ISO8859-1" LDFLAGS="-L/scratch/mvandepo/gentoo/usr/lib -R/scratch/mvandepo/gentoo/usr/lib -L/scratch/mvandepo/gentoo/lib -R/scratch/mvandepo/gentoo/lib" PKGDIR="/scratch/mvandepo/gentoo/usr/portage/packages" PORTAGE_CONFIGROOT="/scratch/mvandepo/gentoo/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/scratch/mvandepo/gentoo/var/tmp" PORTDIR="/scratch/mvandepo/gentoo/usr/portage" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="cracklib cxx modules ncurses prefix readline sparc-solaris zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="SunOS" INPUT_DEVICES="keyboard mouse" KERNEL="SunOS" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
This is during bootstrap? I see you're still on the system provided compiler, and that 4.5.2 is rather oldish, given that 4.5.5 is the latest in tree.
Yes, this is during bootstrap. 4.5.3 through 4.5.5 are package masked for various reasons.
Fri Sep 4 01:17:21 2009 >>> sys-apps/findutils-4.5.2 Last time I installed findutils on my sparc-solaris box. I'm recompiling it now to see if it compiles using my 4.4.1 compiler.
ok, it compiled on my machine
$ gcc-config -l * gcc-config: Could not get portage CHOST! * gcc-config: You should verify that CHOST is set in one of these places: * gcc-config: - /scratch/mvandepo/gentoo//etc/make.conf * gcc-config: - active environment truss shows: 5323: ! ! ! g o n e w r o n g . H e r e i s t h e i n f o 5323: r m a t i o n w e g o t f o r t h i s e x c e p t i o 5323: n :\n 5323: write(2, 0x002EB654, 86) = 86 5323: l d . s o . 1 : p y t h o n 2 . 6 : f a t a l : l 5323: i b z . s o . 1 . 1 . 4 : o p e n f a i l e d : N o s u 5323: c h f i l e o r d i r e c t o r y\n\n 5323: llseek(3, 0, SEEK_CUR) = 0 5323: close(3) = 0 5323: write(2, 0x00104CB0, 35) = 35 5323: T r a c e b a c k ( m o s t r e c e n t c a l l l a s t 5323: ) :\n 5323: write(2, 0xFFBFF1D0, 73) = 73 5323: F i l e " / s c r a t c h / m v a n d e p o / g e n t o o 5323: / u s r / b i n / p o r t a g e q " , l i n e 4 7 , i n 5323: < m o d u l e >\n 5323: open64("/scratch/mvandepo/gentoo/usr/bin/portageq", O_RDONLY) = 3 5323: fstat64(3, 0xFFBFE3B0) = 0 5323: fstat64(3, 0xFFBFE258) = 0 5323: ioctl(3, TCGETA, 0xFFBFE33C) Err#25 ENOTTY 5323: read(3, " # ! / s c r a t c h / m".., 8192) = 8192 5323: write(2, " ", 4) = 4 5323: write(2, 0xFFBFE991, 15) = 15 5323: i m p o r t p o r t a g e\n 5323: llseek(3, 0xFFFFFFFFFFFFE517, SEEK_CUR) = 1303 5323: close(3) = 0 5323: write(2, 0xFFBFF1D0, 102) = 102 5323: F i l e " / u s r / l o c a l / a s m / m v a n d e p o / 5323: g e n t o o / u s r / l i b / p o r t a g e / p y m / p o r t a 5323: g e / _ _ i n i t _ _ . p y " , l i n e 4 6 , i n < m o 5323: d u l e >\n 5323: open64("/usr/local/asm/mvandepo/gentoo/usr/lib/portage/pym/portage/__init__.py", O_RDONLY) = 3 5323: fstat64(3, 0xFFBFE3B0) = 0 5323: fstat64(3, 0xFFBFE258) = 0 5323: ioctl(3, TCGETA, 0xFFBFE33C) Err#25 ENOTTY 5323: read(3, " # p o r t a g e . p y".., 8192) = 8192 5323: write(2, " ", 4) = 4 5323: write(2, 0xFFBFE991, 27) = 27 5323: f r o m r a n d o m i m p o r t s h u f f l e\n 5323: llseek(3, 0xFFFFFFFFFFFFE4E4, SEEK_CUR) = 1252 5323: close(3) = 0 5323: write(2, 0xFFBFF1D0, 88) = 88 5323: F i l e " / s c r a t c h / m v a n d e p o / g e n t o o 5323: / t m p / u s r / l i b / p y t h o n 2 . 6 / r a n d o m . p y 5323: " , l i n e 4 8 , i n < m o d u l e >\n 5323: open64("/scratch/mvandepo/gentoo/tmp/usr/lib/python2.6/random.py", O_RDONLY) = 3 5323: fstat64(3, 0xFFBFE3B0) = 0 5323: fstat64(3, 0xFFBFE258) = 0 5323: ioctl(3, TCGETA, 0xFFBFE33C) Err#25 ENOTTY 5323: read(3, " " " " R a n d o m v a".., 8192) = 8192 5323: write(2, " ", 4) = 4 5323: write(2, 0xFFBFE990, 41) = 41 5323: f r o m b i n a s c i i i m p o r t h e x l i f y a s 5323: _ h e x l i f y\n 5323: llseek(3, 0xFFFFFFFFFFFFE5D1, SEEK_CUR) = 1489 5323: close(3) = 0 5323: write(2, " I m p o r t E r r o r", 11) = 11 5323: write(2, " : ", 2) = 2 5323: write(2, 0x0038F09C, 80) = 80 5323: l d . s o . 1 : p y t h o n 2 . 6 : f a t a l : l i b z . 5323: s o . 1 . 1 . 4 : o p e n f a i l e d : N o s u c h f 5323: i l e o r d i r e c t o r y 5323: write(2, "\n", 1) = 1 There's no zlib 1.1.4 to emerge.
oh, your python is broken ;) is your binutils-config -l returning no selected linker either, perhaps?
No, that one works fine. $ binutils-config -l [1] sparc-sun-solaris2.10-2.20.51.0.4 *
ok, where does your python come from? is it the bootstrapped one, or an emerged one? (location reveals this -- the tmp in path)
It's the right python. Looks like it's loading binascii.so when it fails: 5865: open("/scratch/mvandepo/gentoo/tmp/usr/lib/python2.6/lib-dynload/binascii.so", O_RDONLY) = 8 5865: mmap(0x00010000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 8, 0) = 0xFF270000 5865: mmap(0x00010000, 90112, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFED80000 5865: mmap(0xFED80000, 13168, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_TEXT, 8, 0) = 0xFED80000 5865: mmap(0xFED92000, 8800, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_INITDATA, 8, 8192) = 0xFED92000 5865: munmap(0xFED84000, 57344) = 0 5865: memcntl(0xFED80000, 3324, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 5865: close(8) = 0 5865: stat("/usr/sfw/lib/librt.so.1", 0xFFBFB878) Err#2 ENOENT 5865: stat("/usr/sfw/lib/libaio.so.1", 0xFFBFB878) Err#2 ENOENT 5865: stat("/usr/sfw/lib/libmd5.so.1", 0xFFBFB878) Err#2 ENOENT 5865: stat("/usr/sfw/lib/libz.so.1.1.4", 0xFFBFB878) Err#2 ENOENT 5865: stat("/lib/libz.so.1.1.4", 0xFFBFB878) Err#2 ENOENT 5865: stat("/usr/lib/libz.so.1.1.4", 0xFFBFB878) Err#2 ENOENT 5865: munmap(0xFED80000, 13168) = 0 5865: munmap(0xFED92000, 8836) = 0 5865: munmap(0xFF270000, 8192) = 0 5865: llseek(7, 0, SEEK_CUR) = 0 5865: close(7) = 0 5865: llseek(6, 0, SEEK_CUR) = 0 5865: close(6) = 0 5865: fstat64(2, 0xFFBFDCD8) = 0 5865: write(2, "\n\n", 2) = 2 5865: write(2, 0x001F80F4, 70) = 70 5865: ! ! ! F a i l e d t o c o m p l e t e p y t h o n i m 5865: p o r t s . T h e s e a r e i n t e r n a l m o d u l e 5865: s f o r\n Strangely enough though the output of ldd is: $ ldd /scratch/mvandepo/gentoo/tmp/usr/lib/python2.6/lib-dynload/binascii.so librt.so.1 => /usr/lib/librt.so.1 libaio.so.1 => /usr/lib/libaio.so.1 libmd5.so.1 => /usr/lib/libmd5.so.1 libz.so.1.1.4 => /home/mvandepo/.caddir/SunOS_5.10/cadlib/libz.so.1.1.4 libgcc_s.so.1 => /home/mvandepo/.caddir/SunOS_5.10/cadlib/libgcc_s.so.1 libc.so.1 => /usr/lib/libc.so.1 /platform/SUNW,Sun-Blade-1500/lib/libmd5_psr.so.1 libm.so.2 => /usr/lib/libm.so.2 $ ls -l /home/mvandepo/.caddir/SunOS_5.10/cadlib/libz.so.1.1.4 lrwxrwxrwx 1 mvandepo asd 65 2009-10-12 12:35 /home/mvandepo/.caddir/SunOS_5.10/cadlib/libz.so.1.1.4 -> /home/mvandepo/.caddir/SunOS_5.10/.caddata/zlib/lib/libz.so.1.1.4 $ ls -al /home/mvandepo/.caddir/SunOS_5.10/.caddata/zlib/lib/libz.so.1.1.4 -rwxr-xr-x 1 support support 66804 2002-09-12 10:13 /home/mvandepo/.caddir/SunOS_5.10/.caddata/zlib/lib/libz.so.1.1.4 I also don't understand why statting of librt/libaio/libmd5 give ENOENT, but does not result in an exception. I can see from other so's like _struct.so that statting rt/aio/md5 also gives ENOENT, so I guess it really doesn't matter.
I'm now able to reproduce portageq failing from the command line using this command from the truss output: 24047: execve("/scratch/mvandepo/gentoo/tmp/usr/bin/env", 0x000F3DB0, 0x000ED798) argc = 6 24047: argv: env -i EPREFIX=/scratch/mvandepo/gentoo 24047: /scratch/mvandepo/gentoo/usr/bin/portageq envvar CHOST Could it be that in your case it does the same but still finds the libraries because everything is in /usr/lib or some path specified in Solaris' alternative to ld.so.conf? The command succeeds if I add the old LD_LIBRARY_PATH setting after env -i
"old LD_LIBRARY_PATH"? LD_LIBRARY_PATH is considered harmful, don't use it. With that one set, we don't support anything.
How do you propose I convince the sysadmins of that? ;-) And what would be the alternative? There's currently a whole bunch of paths in LD_LIBRARY_PATH when I log in.
It's a user setting, so you can easily unset it. LD_LIBRARY_PATH kills more than it fixes, it is just a hack to check things, not to fix/solve resolution problems. If you sysadmins claim this is necessary, they clearly don't comprehend dynamic linking sufficiently.
I unset LD_LIBRARY_PATH and restarted the bootstrap procedure. It's still going, but it has passed the findutils emerge. gcc-config -l is working now. Would it be an option to have bootstrap-prefix.sh warn about LD_LIBRARY_PATH being set? Because as we saw it caused problems during the bootstrap of python that only became visible many steps later, and even then it was not immediately clear what the problem was (portageq crashed because python was broken, but gcc-config just said it couldn't determine CHOST).
It is a tough situation to warn about env variables. :) How the heck do we know what crazy env you have...? It could go on forever. I personally always bootstrap with: "exec -c /bin/bash --norc --noprofile"
Theoretically yes, but in practice don't you think LD_LIBRARY_PATH is the most common variable to screw things up? Are there any others nearly as common? It wouldn't be so bad if gcc-config gave a better idea of what was wrong and print the output of the invocation of portageq that crashed.
ehhm, PATH, SHELL, and what more weird errors have we had in the past because people had the most weird stuff in their envs... We better add env -i HOME=${HOME} .... ${SHELL} -l to the bootstrap docs, or that snippet that darkside posted in that case.
(In reply to comment #16) > Theoretically yes, but in practice don't you think LD_LIBRARY_PATH is the most > common variable to screw things up? Are there any others nearly as common? It is probably the least common, actually. Which brings back the point: "how in the heck are we suppose to know what is in the env" Most of time it just works and doesn't warrant a separate step in the docs for edge cases like this. Maybe just a "note" in the docs :) > > It wouldn't be so bad if gcc-config gave a better idea of what was wrong and > print the output of the invocation of portageq that crashed. >
(In reply to comment #18) > It is probably the least common, actually. I have a hard time believing that. It's up to you guys to decide what to do if anything.
latest gcc installs a profile file which unsets LD_LIBRARY_PATH
