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:
Martin, Rod, All,

On Wednesday 30 June 2010 105550 Martin Guy wrote:
Let me guess... /home/bomr exists and is not accessible to anyone
other than bomr,
so bomr can follow the long path and fails when it can see that a
certain directory does not exist, while any other user can't look in
/home/bomr, so can't see whether the dir exists or not, hence 2
different errors, one of which is trapped and ignored, the other of
which is considered fatal.

Bingo. That seems to be exactly the case.


IMHO, gcc should treat it the same way, and fallback to using the new
location, as if the searched path did in fact not exist.

So, is there a way to make the cross compiler NOT look there?
Your answer is to get the /home/bomr stuff out of the toolchain you
are installing.
It has no business being in there - you should be installing in
/usr/local or /opt or somewhere like that.

Well, it the tool demands it, then so be it. IMHO, I should be able to do all of my work in my home directory, and then move the product of the build to it's production destination.



Unfortunately, not all users can write to either place. On my machine, I made my main usr member of a grou pthat can write to /op, but it requires root priviledges, which you might not have on a production system.

So really, I think gcc is at fault here. The right solution would be for
gcc not to fail on permission denied, and continue searching the other
paths.

Regards,
Yann E. MORIN.


After thinking about it, I came to a similar conclusion. I was hoping that the list of 'places to look for stuff' could be controlled in some way when the cross compiler was built (by CT-NG). It sounds like you're saying that is not the case.
So, in my uncanny way, I've found a way to work outside the box of normalcy, again. I feel proud. Maybe someone in the Gnu cc community will read this and see fit to change it.
I have already tried running CT-NG from a directory that is normally readable by other users, and that seems to produce a toolchain that works as expected when transported to another host. It still bugs me that there are build-host dependencies built into the toolchain, but having a method that gets my job done will suffice.


I will consider this case closed. Thanks for your help.

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