[haiku] Re: Haiku gcc2hybrid and software for gcc4
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Thu, 05 Nov 2009 08:04:28 +0100
On 2009-11-05 at 00:09:10 [+0100], Urias McCullough <umccullough@xxxxxxxxx>
wrote:
> On Wed, Nov 4, 2009 at 2:49 PM, scott mc <scottmc2@xxxxxxxxx> wrote:
> > And you'd be correct. Guess we missed the meno about requiring gcc2
> > and gcc4 subdirs under lib. Perhaps someone who knows the details of
> > what must be put where can post a wiki page on HaikuPorts about this
> > so we can start doing this. For any binaries you find there, dated
> > before today at least, assume they don't conform to this. Most of
> > them do have the gcc version listed in the file names. As far as I
> > know the SDL libs should only be in C though... but that may not have
> > prevented some apps from being compiled with gcc4 compiled libs.
> > Perhaps those affected apps should be rebuilt using the gcc2 SDL libs.
> > If that's the case then open a ticket on HaikuPorts to report any
> > broken apps you find and sooner or later we'll get them all fixed up.
>
> Actually, it's not as simple as making gcc2 or gcc4 subdirs...
>
> If you're on a gcc2hybrid (where the base Haiku is compiled with gcc2,
> but contains alternative gcc4 libraries), then all gcc2 libs would be
> in just lib - while gcc4 c++ libs (since only C++ compiled stuff
> causes the ABI issue) go into a gcc4 sub dir... whereas if you're on a
> gcc4hybrid all the gcc4-compiled libs go into just lib, while gcc2 c++
> compiled libs go into a gcc2 subdir.
>
> Thus, you can't just always put stuff in gcc2 or gcc4 - but rather you
> must evaluate it based on the target version of Haiku. This makes it
> hard to anticipate from the porter point of view.
>
> Any ideas?
I see two possible alternatives:
1. If an optional package is not available for both compilers, a repackaged
version for the other compiler's hybrid would need to be provided. E.g. for
a C++ gcc2 libfoo package a second package for a gcc4 hybrid would need to
be created by moving the libraries (and possibly add-ons) into respective
gcc2 subdirectories.
2. The optional packages could be left alone and the installation process
would need to move the contained libraries to the respective subdirectories.
Option 1. is more explicit and no-brainer for the one installing the
package (as long as the correct package is chosen), while 2. doesn't
additionally burden the porter/packager. 2. does indeed require some sort
of installer, but not a complete package manager -- a small script should
suffice. If the optional packages were only used by the build system, as I
originally envisioned it, the matter could be solved by a small change to
the build system.
CU, Ingo
Other related posts:
