[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 11:50:33 +0100

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.
> >
> > At least theoretically both gccs should search the paths corresponding to
> > the currently set gcc. I wouldn't rule out that something goes wrong,
> > though. Have you tested it?
> 
> Not yet, at least. The "with such mixing, symbol resolution will be
> inconsistent.", part concerned me as that sounds like what will
> typically happen on a gcc2h image -- running some GCC4 apps with GCC2
> libs.
> 
> >> So ... could this scenario lead to unexpected problems for the end user?
> >
> > Obviously when linking against static libraries the code for the wrong gcc
> > will be linked in, which alone is a reason, which where pure C code is
> > concerned probably doesn't matter much. I don't know whether there are any
> > consequences with respect to shared libraries. I'd rather avoid the
> > situation.
> 
> Err, I meant as far as running software. I haven't given much thought
> to building software, as I've preferred to not use the setgcc script.

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.

CU, Ingo

Other related posts: