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: Final toolchain dir


Andy, All,

On Monday 28 March 2011 18:12:45 ANDY KENNEDY wrote:
> Some of the above use cases is what I'm dealing with.  I just missed
> that option.  What I'm doing is providing a toolchain that is 100%
> statically bound to the RFS that I generate.  Now, to that end, we
> have a few libs that many other packages are dependant upon.  To that
> end I have to be able to put those puppies into the sysroot as I
> don't even want to go down the "you have to use --sysroot in your
> make system" as I don't want to fight that battle

I see nothing really wrong in this case. Personnaly, I would try to avoid
doing this, and suggest always building from source. But I can see how it
can help to have a basic set of common libs in the sysroot.

I have an option here, that implies some union mounts, and can ease the
stuff (absolutely untested, product of my insane brain!), but that does
not cover the SDK case you and Javier need to handle:

- create a directory that will be used to _hold_ the staging area
- create another directory, that will be used _as_ the staging area
- union mount the sysroot as a RO branch and the real staging area
  (ie the first created dir above) as a RW branch onto the final
  staging area (the second dir created above).
- rename all the toolchain tools (eg. tuple-gcc, tuple-g++, tuple-ld
  and so on...) and provide wrappers to replace them
- have the wrapper always include --sysroot=/the/union/mount/point
- use /the/union/mount/point as DESTDIR when installing
- once eveything is installed, unmount the union, and use the real
  staging area (the first dir created above) as the source for
  populate
- use populate as previously explained.

That way, you ensure that:
- the sysroot is not poluted with secondary libs (eg. zlib, Qt...)
- the apps always find the system libs *and* the secondary system libs
  thanks to the --sysroot option forced by the wrappers
- the target directory does not contain headers and static stuff from
  the sysroot

However:
- you have to cleanup the real staging area of the headers and static libs
  and other stuff that have no say in the target file system

> (I'm still the new guy here [with 17 years Linux development]).

The New Guy (TM) !

> So, I install zlib, etc in the toolchain's sysroot.  If this is the
> wrong approach just punch up delete on your e-mail client and go
> take a walk to cool off ;).

Hehe! ;-)

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]