This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG 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] |
Michael Hope <michael.hope <at> linaro.org> writes: > > Hi there. Why does crosstool-NG create a symlink from > $tuple/$sysroot/lib to $tuple/lib? It causes GCC to install support > libraries like libgcc_s.so into the sysroot instead of the default > location which makes it tricky to replace the sysroot later. > > For our binary builds we plan to supply a few different sysroots > including a minimal libc, developer image with GTK and X, and a > desktop image with a wide range of packages. They'll come as tarballs > and the intent is for people to delete the old $tuple/$sysroot and > extract the new one in its place. Currently this means that the > support libraries will also get deleted. The target comes with these > libraries preinstalled. > I'm exploring similar sysroot setups (but in my case I want the sysroot to work for both gcc and clang). Other than size, what would go wrong with having all sysroots including the GCC's support libraries and whatever additional library the specific sysroot introduces? Obviously it would require redistribution of all sysroot tarfiles whenever the compiler toolchain changes, but other than that and size, I don't see problems. I've just started with this setup, so I might be missing the obvious. Maurizio -- 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] |