[haiku-development] Re: Fwd: [Haiku] #7203: gcc4 seems to have an issue locating libraries
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 06 Mar 2011 17:50:52 +0100
On 2011-03-06 at 13:15:34 [+0100], Matt Madia <mattmadia@xxxxxxxxx> wrote:
> On Sun, Mar 6, 2011 at 10:50, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> > On 2011-03-05 at 22:38:27 [+0100], Matt Madia <mattmadia@xxxxxxxxx> wrote:
> >> On Sat, Mar 5, 2011 at 17:46, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> >> > On 2011-03-05 at 18:22:20 [+0100], Matt Madia <mattmadia@xxxxxxxxx>
> >> > wrote:
> >> >> How does this affect running hybrids?
> >> >>
> >> >> For instance, let's look at a gcc4 built Web+ and it's dependences
> >> >> (Curl LibXML2 SQLite OpenSSL), which are also built under gcc4.
> >> >>
> >> >> When building a GCC 2 Hybrid, the build system will give preference to
> >> >> packages built for the host/main/primary gcc -- creating an image with
> >> >> (gcc4) Web+ and (gcc2) Curl LibXML2 SQLite OpenSSL.
>
> > On a gcc 2 hybrid installation when loading a gcc 4 programm the runtime
> > loader first searches a needed library in the gcc4 subdirectories and only
> > when it fails falls back to the primary search paths. If the full set of
> > libaries is available for both compilers now, we can as well disable that
> > fallback. As Oliver wrote, the package management will consider the two
> > x86
> > gcc version as separate architectures and the case won't happen anyway,
> > since
> > the package dependency resolution would already ensure that all the needed
> > libraries are available anyway.
> >
>
> But in the meantime, the build system won't install both sets of
> libraries -- both due to the way optional packages are tracked with
> the subjam process and not automagically moving the affected bits into
> the alt-gcc-subdir. ...Or am i overlooking something?
Ah, now I'm getting what you're talking about. Indeed, ATM gcc 4 library
packages are not installed correctly on a gcc 2 hybrid, since there isn't any
package built in such a way (i.e. with the libraries in the gcc4 subdirectory
and ideally not clashing with the other version either) and the build system
isn't handling this case anyway. I guess this also means that one actually
would have to build those packages under a gcc 2 hybrid.
CU, Ingo
Other related posts: