Final toolchain dir

ANDY KENNEDY ANDY.KENNEDY@adtran.com
Mon Mar 28 16:13:00 GMT 2011


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

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'm still the new
guy here [with 17 years Linux development]).

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 ;).

Andy

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



More information about the crossgcc mailing list