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]

Re: Toolchain has UID dependency


Yann E. MORIN wrote:
Rod,

Please, keep the mailing CCed next time.

Oops. My bad.


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:

the WORKING user:

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"

...then, the compilation and linkage completes.


the NON-WORKING user:


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

Compilation quits with error.


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.

Thanks for sticking with me.

--- rod.




-- 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]