Summary: | cross compiling gcc fails because of broken library search paths | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | zeuner |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | zeuner |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/x86_64-pc-linux-gnu/libiberty/config.log
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/x86_64-pc-linux-gnu/libstdc++-v3/config.log |
Description
zeuner
2007-12-11 14:29:21 UTC
Created attachment 138260 [details]
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/x86_64-pc-linux-gnu/libiberty/config.log
Created attachment 138261 [details]
/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/x86_64-pc-linux-gnu/libstdc++-v3/config.log
no idea why you're talking about ROOT ... crossdev does everything independent of ROOT use crossdev like normal and you get glibc installed into /usr/$CTARGET/ (In reply to comment #3) > no idea why you're talking about ROOT ... crossdev does everything independent > of ROOT > > use crossdev like normal and you get glibc installed into /usr/$CTARGET/ > Yes, creating glibc and gcc in /usr/$CTARGET using crossdev worked fine. The problem was raised by trying to create a working gcc inside $ROOT using the toolchain created by crossdev with regular emerge. Is there a better way to have a cross-compiled $ROOT with a working compiler inside (thus not being forced to cross-compile anymore)? i still dont understand what you're attempting to do when you run `crossdev <target>`, it builds up a proper cross-compiler toolchain which includes glibc being installed into /usr/<target> if you want to build up a gcc to run on <target>, then you do: ROOT=/some/place emerge gcc (assuming you've setup everything else) please post any questions you have to the embedded list ... bugzilla is for fixing bugs, not handling support (In reply to comment #5) > i still dont understand what you're attempting to do > but interestingly, you describe what I'm attempting to do in detail > when you run `crossdev <target>`, it builds up a proper cross-compiler > toolchain which includes glibc being installed into /usr/<target> > Did that. (Step 1 in the bug report) > if you want to build up a gcc to run on <target>, then you do: > ROOT=/some/place emerge gcc Tried that. (Step 3 in the bug report, and the actual bug) > (assuming you've setup everything else) Did that before. (Step 2 in the bug report) > > please post any questions you have to the embedded list ... bugzilla is for > fixing bugs, not handling support > So it looks like I was already doing it correctly, when I encountered the bug. Furthermore, I provided a workaround and asked for the bug to be fixed. As you correctly stated, bugzilla is for fixing bugs, so I put it in the correct place. But it is not for making fun of bug reporters, so it may be more helpful to ask for possibly missing information instead for doing so. if you're symlinking stuff, you're doing it wrong crossdev already takes care of making sure the crt objects are in the right place for the cross-compiler toolchain if it's not finding it, you're doing something wrong. look for help on the embedded mailing list, not here. i dont know why you think i'm "making fun of you" when i'm not. i'm simply telling you you're doing (whatever it is you're doing) wrong. whether it be the commands you're running or improperly setting up your cross-environment, i dont know. ask for help on the mailing list. |