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] |
> 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |