x86 (GCC4) packages aren't clearly installables on gcc2h System

[Giova84]

hrev46179 and also early revisions of PM branch.

I wished to install FFmpeg x86 (compiled with GCC4.7), since the provided GCC2 version, had some problem during encoding. Ok, i have grabbed the file ffmpeg-0.10.2-4-x86.hpkg, moved in /system/packages and an alert told me that i was unable to install this GCC4 version. So i opened the package with Expander, modified the architecture inside the .Packageinfo file from x86 to x86_gcc2, moved the libraries under /x86 folder and then i was able to install and use the GCC4 version of FFmpeg. Ok, this is absolutely a dirty workaround, but in fact now, despite the alert i am able to use this GCC4 version of ffmpeg (i have also packaged and installed a GCC4 version of ffmpeg with mp3 support which i built some months ago.. And works fine if i set this version as x86_gcc2 instead of x86). And the same is for some apps which i have packaged. These apps were built using GCC4 as compiler system and i was able to run them on the Haiku preceding to the PM branch, but if i package them specifying x86 as architecture, i'm not able to install them, instead, if i specify x86_gcc2 as architecture, i am able to install and use these apps.. I miss something?

[anevilyak]

The package has to match the system architecture. If it's a gcc4 executable/library targeted at a gcc2 hybrid, then it needs to be packaged appropriately, as it would for instance need to do things like put libraries and add-ons in a different subdir than it would on a gcc4 primary system.

[kallisti5]

How do you specify in a hpkg recipe if it is "gcc4" or "gcc2h - gcc4"?

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)

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.

[bonefish]

Replying to 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.