I have tried both of these on my x86_64 system: sudo crossdev --target ia64-unknown-linux-uclibc --stage1 --kernel 2.6.16 sudo crossdev --target ia64-unknown-linux-glibc --stage1 --kernel 2.6.16 These both fail presently. I'll attach the logs
Created attachment 87469 [details] cross-ia64-unknown-linux-uclibc-info.log
Created attachment 87470 [details] cross-ia64-unknown-linux-uclibc-uclibc-headers.log
Created attachment 87474 [details] cross-ia64-unknown-linux-gnu-info.log
Created attachment 87475 [details] cross-ia64-unknown-linux-gnu-glibc-headers.log
btw, I meant ia64-unknown-linux-gnu in the bug description, not ia64-unknown-linux-glibc
heh, I just looked at the uclibc failure for the first time ;-) I'll play with keywords and let you know what happens. The glibc failure is "real" though.
Sweet, the uclibc one works, just needed to add ~ia64 to uclibc
*** Bug 164035 has been marked as a duplicate of this bug. ***
the header situation should be resolved by now (and works for me)
Not working yet... It looks like gcc is probed before install...
Created attachment 125767 [details] cross-ia64-unknown-linux-gnu-info.log
Created attachment 125769 [details] cross-ia64-unknown-linux-gnu-glibc-headers.log
your system has a broken gcc-config binary installed, remove it
OK. Now I got: [I--] [ ~] sys-devel/gcc-config-2.0.0_rc1 (0) [I--] [ ~] app-admin/eselect-compiler-2.0.0_rc2-r1 (0) Still same result. Please notice that the message is correct, I don't have (yet) the ia64 gcc, as this step is before crossdev compiles it.
eselect-compiler is not supported my last comment *and* the message is correct because it means `ia64-unknown-linux-gnu-cpp` exists on your system even though you do not have the cross-compiler installed delete the binary
And how could I know that?!?!? Am I psychic? And why when updating gcc-config it does not clean up the invalid stuff?
you're supposed to know that because i told you how to fix it gcc-config should clean up after itself *now* but it didnt in the past for sure
Created attachment 125778 [details] cross-ia64-unknown-linux-gnu-glibc.log Still does not work... Now glibc assembly issue.
scroll up in the logs to see the real error most likely related to your selection of CFLAGS, dunno ... works fine for me `crossdev ia64`
Do you want to make it work for other people? If you do, please help. You are the expert... I cannot do much except of reporting back. 1. I don't see any of my CFLAGS used in the log. 2. It seems to have a problem with TLS: In file included from include/tls.h:6, from sysdeps/unix/sysv/linux/ia64/sysdep.h:28, from <stdin>:1: nptl/sysdeps/ia64/tls.h:61:3: error: #error "TLS support is required." 3. There is a missing header, which I cannot find on package and on my system ../sysdeps/ia64/hp-timing.h:27:24: error: ia64intrin.h: No such file or directory
Well... Please tell me where you got the ia64intrin.h from...
it's part of gcc /usr/lib/gcc/ia64-unknown-linux-gnu/4.2.0/include/ia64intrin.h
Please stop fixing this bug while it is not fixed. I've found *A* problem, and I guess it is not the last. You could have notice this (if you know what you are lookin for...) I guess something is wrong with gcc-config/eselect compiler whatever. From glibc log: checking for ia64-unknown-linux-gnu-gcc... no checking for gcc... gcc checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for gcc... gcc checking how to run the C preprocessor... gcc -E checking for ia64-unknown-linux-gnu-g++... no checking for ia64-unknown-linux-gnu-c++... no checking for ia64-unknown-linux-gnu-gpp... no checking for ia64-unknown-linux-gnu-aCC... no checking for ia64-unknown-linux-gnu-CC... no checking for ia64-unknown-linux-gnu-cxx... no checking for ia64-unknown-linux-gnu-cc++... no checking for ia64-unknown-linux-gnu-cl... no checking for ia64-unknown-linux-gnu-FCC... no checking for ia64-unknown-linux-gnu-KCC... no checking for ia64-unknown-linux-gnu-RCC... no checking for ia64-unknown-linux-gnu-xlC_r... no checking for ia64-unknown-linux-gnu-xlC... no checking for g++... g++ And: # ls /usr/bin/ia64-unknown-linux-gnu-* /usr/bin/ia64-unknown-linux-gnu-addr2line /usr/bin/ia64-unknown-linux-gnu-ld /usr/bin/ia64-unknown-linux-gnu-ar /usr/bin/ia64-unknown-linux-gnu-nm /usr/bin/ia64-unknown-linux-gnu-as /usr/bin/ia64-unknown-linux-gnu-objcopy /usr/bin/ia64-unknown-linux-gnu-cc /usr/bin/ia64-unknown-linux-gnu-objdump /usr/bin/ia64-unknown-linux-gnu-c++filt /usr/bin/ia64-unknown-linux-gnu-ranlib /usr/bin/ia64-unknown-linux-gnu-ia64-unknown-linux-gnu-cpp /usr/bin/ia64-unknown-linux-gnu-readelf /usr/bin/ia64-unknown-linux-gnu-ia64-unknown-linux-gnu-gcc /usr/bin/ia64-unknown-linux-gnu-size /usr/bin/ia64-unknown-linux-gnu-ia64-unknown-linux-gnu-gccbug /usr/bin/ia64-unknown-linux-gnu-strings /usr/bin/ia64-unknown-linux-gnu-ia64-unknown-linux-gnu-gcov /usr/bin/ia64-unknown-linux-gnu-strip Notice the double ia64-unknown-linux-gnu- How does this happen? I removed /usr/bin/ia64-* before trying again... But they keep appearing this way. Also remember: [I--] [ ~] sys-devel/gcc-config-2.0.0_rc1 (0) [I--] [ ~] app-admin/eselect-compiler-2.0.0_rc2-r1 (0)
i dont know nor do i care i told you eselect-compiler is not supported so if you insist on using it, you get to figure it out
From your own posting: Usage: gcc-config [<options>] WARNING: gcc-config is deprecated and is just a frontend to the compiler eselect module. In the future, gcc-config will be removed from portage. Please see 'eselect compiler help' What should I understand from this?!?!? And gcc-config is depended on eselect-compiler! So which version of any of these tools is working?!?!? If I cannot figure this out, what do you expect from other users?
i dont know what posting you're referring to, but i've never made that statement anywhere stop using masked utilities if you want things to "just work" gcc-config-2+ is masked as is eselect-compiler
OK. I will try. But from comment#13 I understood you want me to use newer gcc-config...
comment #13 was referring to a stale gcc-config wrapper binary installed in /usr/bin/ and nothing more
One more issue... If I have selinux USE flag glibc build fails... I had to had: cross-ia64-unknown-linux-gnu/glibc build To my package.use... Was it right to do? Should crossdev automatically add this?
not sure ... no one has ever tried doing selinux host or target afaik not surprised that it fails though as there wont be any cross-selinux libs built up ...
Can you please skip the selinux stuff if cross compile or to add the build USE flag?
Created attachment 125998 [details] cross-ia64-unknown-linux-gnu-glibc.log-tail-500 Still does not work... Now something in linkage... If it relates to build USE flag I understand... If not, I will be happy to know what can I do.
Created attachment 125999 [details] cross-mingw32-gcc-stage2.log Also stage2 of gcc (mingw32) does not work.
your tree is out of date, that glibc issue has been fixed as for mingw32, your host prob has outdated gmp/mpfr ... update it
(In reply to comment #34) > as for mingw32, your host prob has outdated gmp/mpfr ... update it No... I think the problem is that you don't set -fortran at stage2... Is there any special reason for: GUSE_DISABLE="-boundschecking -fortran -gtk -gcj -mudflap -objc -objc++ -objc-gc -d" GUSE_DISABLE_STAGE_2=${GUSE_DISABLE/-fortran} Why you turning on fortran... And if you do, why the fortran dependency is not merged? I currently have no mpfr on my system... * dev-libs/mpfr Latest version available: 2.2.1_p5 Latest version installed: [ Not Installed ]
gfortran cross compiles just fine ... my mingw32, ia64, and other cross-compilers all have gfortran enabled all cross packages are emerged with --nodeps by design ... install mpfr on your system first
OK. Working now! Summary... 1. Had to erase the /usr/bin/<prefix>-* (After I misunderstood what you tell me in a few words) 2. glibc was fixed. 3. Had to put "cross-ia64-unknown-linux-gnu/glibc build" at package.use 4. Had to put USE="-fortran" at make.conf Questions... 1. Why won't you revbump gcc-config to cleanup the invalid binaries for all users? 2.Can you please auto add the build USE flag for glibc in crossdev so that it only builds the glibc without selinux and maybe other future stuff, just like you do for other components. 3. If fortran USE flag is not available for sys-devel/gcc, can you please also not try to add this in cross-<>/gcc?
how many times do i have to point out *you were using eselect-compiler*. any and all tests done with that are invalid and i wont review any information/problems you have related to it. the only thing USE=build does in glibc is disable selinux. wrt to fortran, no. crossdev does not add any flags at all to your system. read the code, it applies filters to *your* host environment. if *you* dont want fortran, then put -fortran in your make.conf.
(In reply to comment #38) > how many times do i have to point out *you were using eselect-compiler*. any > and all tests done with that are invalid and i wont review any > information/problems you have related to it. Well... You assume the other side understand the meaning of "eselect-compiler"... At comment#15, you could have request: "Please downgrade to stable gcc-config" or better "Please use gcc-config-1.3.16". These terms are clearer, so both sides invested much less time... Just a few would have made the difference. > > the only thing USE=build does in glibc is disable selinux. So if selinux is not supported in cross compile, please auto add build for glibc in package.use just like you do for gcc. > wrt to fortran, no. crossdev does not add any flags at all to your system. You automatically update the package.use!!! All I asked is to add cross-<prefix>/gcc USE flag masked with current sys-devel/gcc USE flags. I had to solve the problem using global USE flag as you update the package.use before you merge the package, so I cannot update the flags for the cross stuff. > read the code, it applies filters to *your* host environment. if *you* dont > want fortran, then put -fortran in your make.conf. Why use global USE flag for specific package? Maybe you can add --gcc-use to crossdev, allowing the user to add some USE flags... So users may: crossdev --gcc-use="-fortran" ia64 But best to automatic take this from the current USE flags of sys-devel/gcc Anyway, Thanks for the environment.
either set up your env to be sane or dont bother crossdev respects your env, so if you dont want fortran just do: USE=-fortran crossdev ...
