[haiku-bugs] Re: [Haiku] #10077: x86 (GCC4) packages aren't clearly installables on gcc2h System

  • From: "bonefish" <trac@xxxxxxxxxxxx>
  • Date: Wed, 09 Oct 2013 23:32:44 -0000

#10077: x86 (GCC4) packages aren't clearly installables on gcc2h System
-------------------------+-------------------------------------------------
   Reporter:  Giova84    |      Owner:  nobody
       Type:  bug        |     Status:  closed
   Priority:  normal     |  Milestone:  R1
  Component:  System     |    Version:  R1/Development
 Resolution:  invalid    |   Keywords:  x86 GCC4 packages aren't clearly
 Blocked By:             |  installables on gcc2h System
Has a Patch:  0          |   Blocking:
                         |   Platform:  x86
-------------------------+-------------------------------------------------

Comment (by bonefish):

 Replying to [comment:2 kallisti5]:
 > How do you specify in a hpkg recipe if it is "gcc4" or "gcc2h - gcc4"?

 In the package you specify the primary architecture according to what
 Haiku the package is intended for, i.e. "x86_gcc2" for a package for an
 x86 gcc 2 (hybrid) Haiku respectively "x86" for an x86 gcc 2 (hybrid or
 not) Haiku. The package name itself should contain the name of the
 secondary architecture, if the package targets that (e.g. foo_x86_devel
 names the devel package for a foo built for x86 gcc 4 for a primary x86
 gcc 2 Haiku), as should the provided (and required (as necessary))
 resolvables.

 haikuporter does most of that automatically already. You have to assist by
 specifying in your recipe, which secondary architectures are supported and
 add "$secondaryArchSuffix" to resolvable names where necessary.

 > I had the same thoughts on Mesa as the gcc2h - gcc4 version should place
 it's renderer in a gcc4 directory (as well as it's libGL)

 In your build recipe you can use the respective directory variables
 provided by haikuporter, which will contain the secondary architecture
 specific subdirectory, if necessary (I just fixed "addOnsDir" in that
 respect). The runtime loader already searches the subdirs depending on the
 architecture the executable has been built for.

 > This would all be a lot easier if we decided to switch to gcc4h as the
 primary release and drop gcc2h. That way we could always assume to use the
 gcc2 subdirectories.

 We'll get the same problem for x86-64 and 32 bit support and I'm not sure,
 what other architectures (like ARM) have in store in that respect. So,
 hard-coding a particular subdir name won't work universally anyway.

 It might be a good idea to adjust `find_directory()` to return the
 respective subdirectory when invoked from secondary architecture code.
 That would relieve most code from having to deal with whether it has been
 built for the primary or secondary architecture.

--
Ticket URL: <http://dev.haiku-os.org/ticket/10077#comment:3>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: