Re: Final toolchain dir

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

Javier, All,

On Monday 28 March 2011 10:13:58 Javier Viguera wrote:
> On 03/26/2011 02:24 AM, Yann E. MORIN wrote:
> > The goal is to render the whole toolchain read-only, and especially the
> > sysroot of the toolchain, to avoid poluting the sysroot with alian stuff
> > from other packages.
> >
> > Once the toolchain is built, nothing, really nothing should be added to
> > it, and especially the sysroot should not be modified.
> 
> Your comments sound reasonable, but i am one that usually populates the 
> sysroot with other stuff (maybe my bad).
> 
> Because i am always open to learn what is then your suggestion to avoid 
> sysroot population in an use case like the following:
> 
> I maintain the toolchains inside my company for a group of 
> developers/customers which needs for example build QT graphic apps, or 
> anything which links to zlib, etc...
> 
> So i keep building those QT, zlib, libraries and installing them 
> *inside* the sysroot, so later customers can use the toolchain to build 
> QT apps.
> 
> Where should i install those 3rd party libraries instead of the sysroot 
> them? Any suggestion on how to solve this without polluting the sysroot.

Well, your use case is one that requires writing into the sysroot, I
suppose. I have no other suggestion, but yet I wonder: once the Qt apps
are built, how do you manage to make them run? Do you use populate (or
any similar tool) to get needed Qt libs into the staginf area?

Also, even if you put your additional libs in the sysroot, do you ship
the toolchain RO or RW? I mean: when your customers build the Qt apps,
the libs will be found (as they are in the sysroot); but where do they
install the generated apps? What if they build their ownadditional libs?
Do they put them in the sysroot? Or do they use a kind of staging area
like I suggest?

Your use-case is more akin to providing an SDK than providing a toolchain.
So I would do it that way if I had to ( but if I had my say, everything
would be compiled from source everytime ;-) ).

There might be a more complex solution (in fact I have a rather good idea
about it, but it is not so trivial to do). It involves putting the Qt libs
in their own dir, potentially side-by-side with the toolchain, or even the
side-by-side with the sysroot, and replacing gcc and all the other tools
with shell wrappers that would add appropriate path ( -I and -L ) and call
to the real tools. Not unlike the tools wrapper that crosstool-NG installs
when the companion libraries are build dynamic, to set the LD_LIBRARY_PATH.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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