gcc4 seems to have an issue locating libraries

[scottmc]

This was with hrev40352. At first I thought it may have been an incorrect configure setting when trying to build openssh-5.8p1: ​http://ports.haiku-files.org/ticket/495 But then when trying to build Beacon from svn, gcc4 isn't able to locate -lclucene even though I have just installed it with installoptionalpackage CLucene.

In both cases the .a and .la files were located in /boot/common/lib gcc --version gives 4.4.4

[phoudoin]

I failed to reproduce this issue. I just succeed to run:

haikuporter -i openssh-5.8p1

under Haiku hrev40527 gcc4 hybrid system.

Could you give more output?

[scottmc]

(In #7286) I just checked this with a build of Haiku hrev39567 and it builds fine with that and includes openssl, but it fails to build correctly with recent Haiku builds. So marking this as being blocked by #7203.

[mmadia]

To note, installoptionalpackage doesn't handle the isGCCAgnostic flag. (it is marked with a TODO in the script) So right there, some issues could rise due to not creating links in the alternate-gcc-subdir (lib/gcc4 or lib/gcc2).

Taking a closer look at build/jam/Optional* it looks like several packages now (needlessly?) have builds for gcc2 and gcc4. For example and IIRC, cURL and SSL are can be compiled once and used with either gcc environment. One major impact of having dedicated builds for each GCC, is that when hybrids are built the build system will download only one archive (that or it'll download both and one will be over-written ... i'm not sure yet)

Having a script in src/tools, to check if a certain package is indeed gcc-agnostic would be help to ensure only gcc-sensitive packages have 2 archives. Though, in the case of LibFoo being gcc-sensitive, there would need to be some type of additional logic to extract the other-gcc package into the gcc-subdir (eg, lib/gcc2 or lib/gcc4)

[mmadia]

Replying to mmadia:

Taking a closer look at build/jam/Optional* it looks like several packages now (needlessly?) have builds for gcc2 and gcc4. For example and IIRC, cURL and SSL are can be compiled once and used with either gcc environment.

In addition, it looks like the isGCCAgnostic flag isn't being used on those packages.

[scottmc]

In trying to narrow down when the issue started, I'm able to build curl ok with gcc4 using hrev39567, but not ok with hrev40312. I will try to narrow it down in the next couple days. If anyone else would like to help out, it's just a matter of installing a gcc2 hybrid build from between these two versions and then running these commands:

cd /boot/develop
svn co http://ports.haiku-files.org/svn/haikuporter/trunk haikuporter
cd haikuporter
./installhaikuporter.sh

The install should take a few minutes or longer depending on your connection speed. Then:

haikuporter -c -d curl-7.21.4

Review the build to see if it detected ssl or if it gives an error. Then recheck it with gcc4:

setgcc gcc4
haikuporter -c -d curl-7.21.4

Report here with a pass or fail and the haiku version number.

[scottmc]

(In #7286) Ok, I removed the installed pcre and curl files from my gcc2h Haiku and installed fresh builds of each using the latest .bep files. Seems the problem is using gcc4 libs when they aren't needed and don't currently build correctly anyways. After the removal of the old pcre and curl files I verified that both Pe/lpe and WebPositive broke as was reported on this ticket. I then installed the new gcc2 builds and then tested both Pe/lpe and WebPositive and both are now working, the way they should. Even https is working. I have attached a patch to re-add them to OptionalPackages. I've also inserted a note to remind anyone updating these two in the near term that the gcc2 libs should work for gcc4 needs. Can someone who is setup to do gcc4 builds and/or gcc2h and gcc4h build apply this patch and verify that it's correct? It's building fine for me with plain gcc2.

I've removed the blocked by on this as if this works it shouldn't be a blocker for alpha3 anymore.

[bonefish]

I would strongly advise against mixing gcc 2 and gcc 4 executables and libraries even if the runtime loader still supports that. With the introduction of support for weak symbols and symbol preemption gcc 4 shared objects, unlike gcc 2 ones, are no longer linked symbolically. As a result, with such mixing, symbol resolution will be inconsistent. This doesn't necessarily need to lead to problems -- it will probably work just fine in most cases -- but that's virtually impossible to predict. Hence I'd recommend to treat gcc 2 and gcc 4 as separate architectures and build complete library sets for each.

Regarding building packages for the hybrid-other compiler, I'm not sure whether the compiler/linker does search the gcc* subdirectories as expected. IIRC I introduced some symlink trickery that should make those directories visible to the compiler, but I don't recall whether there are built-in paths that would be searched first, thus potentially finding the wrong libraries first. The safest way to build gcc 4 libraries is on a gcc4[h] haiku.

[scottmc]

I'll try out building the gcc4 libs using a gcc4 Haiku virtual machine over the next day or two here.

[scottmc]

Ok, so far it looks good. Building a gcc4 curl on a plain gcc4 Haiku with a gcc4 build openssl in place and it is finding it just fine now. More testing to come but so far it's looking good.

[scottmc]

So building the gcc2 packages on a gcc2 or gcc2h system seems to work, along with building the gcc4 packages on a gcc4 system, and/or presumably a gcc4h, but not ok to build the gcc4 packages on a gcc2 hybrid system. So, marking this one as invalid.