This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Rod,
Please, keep the mailing CCed next time.
OK, I just tried here, and It Works For Me (TM). Steps: - as UID/GID = 1000/1000, build a toolchain, into /tmp/toolchains/x-tools/(tuple) - as root, mv /tmp/toolchains/x-tools/(tuple) /opt/x-tools/(tuple) - as root, chown -R 2000:2000 /opt/x-tools - as root, chmod -R ugo+rX-w /opt/x-tools Now the toolchain belongs to UID/GID = 2000/2000, it is readable by everybody, directories are 'listable', and executables are executable.
Now, with this trivial ess.c: #include <stdio.h> #include <stdlib.h> int main( int argc, char** argv ) { printf( "Hello, World!\n" ); return 0; }
- as UID/GID=1001/1001: (tuple)-gcc ess.c -o ess I properly get an execuable, gcc does not complain, whatever...
So: i build the toolchain with a UID/GID pair, install it as if it belong to a second UID/GID pair, and run it as a third UID/GID pair. There is no issue with that. I do it everyday.
[--SNIP--]As root, try to run: chmod -R go+rX /usr1/local/support/Xtools/arm-unknown-linux-gnu (or wherever you did move the toolchain to).Done. No change.
OK, this is turning weird... So, back to the drawing board...
Do you have some kind of policy enforcement on your RHEL4 box, such as SELinux, and the policy forbids some users access to some paths.. (wild guess here, I don't know nor use SELinux, nor any other policy kit).
Regards, Yann E. MORIN.
Okay, I think this is both a permission thing, and a sysroot thing. I think I need a small amount of guidance about how to set the sysroot stuff when I build the toolchain. I tried (cross) compiling with the --verbose switch. When I compare the output of the working and non-working instances, I come to these:
ignoring nonexistent directory "/home/bomr/x-tools/arm-unknown-linux-gnu/lib/gcc/arm-unknown-linux-gnu/4.1.2/include" ignoring nonexistent directory "/home/bomr/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include"
cc1: error: /home/bomr/x-tools/arm-unknown-linux-gnu/lib/gcc/arm-unknown-linux-gnu/4.1.2/include: Permission denied cc1: error: /home/bomr/x-tools/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include: Permission denied
The directory that is being referenced never did exist on this, the RHEL host, but is the default output directory on the Debian host where CT-NG runs (i.e. where the toolchain was born). The base directory '/home/bomr/.....' on the toolchain host does exist, but the user running the toolchain (gcc, etc.) has no permissions there, hence it bugs out. At least this much seems to make sense. To me...
So, is there a way to make the cross compiler NOT look there? I'm guessing it is related to the sysroot configuration, but I don't fully understand the sysroot mechanisms. I'll try some research offlist, but a suggestion about building a toolchain that gets me around this would be gratefully accepted.
No, there is no Selinux or any other such encumbrances on this host. The example output I showed above happened after I did all of the steps you recommended.
-- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |