Re: Toolchain has UID dependency

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Rod, All,

On Wednesday 30 June 2010 163814 Rod Nussbaumer wrote:
> Well, on further reflection, I now see what seems to be the origin of 
> the problem. The default setting in the CT-NG config:
> CT_PREFIX_DIR="${HOME}/x-tools/${CT_TARGET}"

> This setting seems to promote the use of a home directory as the 
> destination for the built toolchain. Then there is
> CT_INSTALL_DIR="${CT_PREFIX_DIR}"

This is in prevision of out-of-tree install, but is not currently handled.
In the end, I'd like that oine can set prefix=/usr, and use the autotools'
DESTDIR feature. This could in the end solve the issue you were facing.
But that's not that easy for now with crosstool-NG... (I have a plan for
that, but I have to think it a litle more in depth...)

> and the distinction between the two is not clear to me, especially since 
> they end with the same value. Does it seem reasonable that if ${HOME} is 
> to be part of the directory that is used, and embedded in the created 
> binaries, a note should be part of the menuconfig help, explaining the 
> possible ramifications?

The fact is that the sysroot should take care of that. By default, gcc (and
the other tools) have to know where to find their supportive files (eg.
includes, backends...). So the runtime prefix has to be somewhat embedded
in the tools.

When the toolchain is relocated, the way the tools search for these files
is (seems to be) in order:
- look in the configured paths, embedded in the binaries
- then substract the configured prefix from those paths, and
  add the new runtime prefix

So if the toolchain is configured with:
  --prefix=/home/foo/bar/tuple
  --with-sysroot=/home/foo/bar/tuple/tuple/sysroot

The search paths are then (for includes and libs):
  /home/foo/bar/tuple/tuple/sysroot/usr/include
  /home/foo/bar/tuple/tuple/sysroot/lib
  /home/foo/bar/tuple/tuple/sysroot/usr/lib

Then the toolchain is moved to /opt/tuple. Lets substract the original
prefix and we get relative sysroot path:
  /tuple/sysroot

Then add that to the new prefix to get the new sysroot path:
  /opt/tuple/tuple/sysroot

The new search paths are thus:
  /opt/tuple/tuple/sysroot/usr/include
  /opt/tuple/tuple/sysroot/lib
  /opt/tuple/tuple/sysroot/usr/lib

Of course, your issue has to do with the fact that the first paths are
searched for, but gcc mis-interprets denied permissions with non-existing
path, when it should continue the search with the mangled paths.

And non-sysrooted toolchain can *not* be relocated. Or only with highly
complicated munging...

> Or, perhaps using ${HOME} as part of the default  
> setting should be changed altogether.

By default, the only place I know for sure that the user has write-access
to is ${HOME}. Any other place on the system will most probably not be
writable. The default has to be something in ${HOME}.

Regards,
Yann E .MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< O_o >==-- '------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL    |  """  conspiracy.  |
'------------------------------'-------'------------------'--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq