regression: building haiku on haiku fails with "openssl/ssl.h no such file or directory"

[taos]

I was trying to build haiku hrev48679 on gcc2hybrid hrev48678. However, I've seen the following error message before (I think the first time right after the latest update of the openssl package):

C++ /GIT/haiku/generated.x86gcc2/objects/haiku/x86/release/kits/network/libnetapi/ssl/SSL.o 
/GIT/haiku/src/kits/network/libnetapi/SSL.cpp:11:25: fatal error: openssl/ssl.h: No such file or directory
 #include <openssl/ssl.h>
                         ^
compilation terminated.

[anevilyak]

does pkgman install openssl_devel help?

[anevilyak]

And/or possibly openssl_x86_devel if you're trying a hybrid build.

[taos]

Except for the openssl source package, all other openssl packages are already installed ("normal" + devel packages for x86_gcc2 and x86, all with version 1.0.0p). But I can try to remove all of them and reinstall them if you think that this might help.

[anevilyak]

No need, I just wanted to ensure it wasn't missing entirely. In that case, please try ../configure --update from your generated.x86_gcc2 folder.

[taos]

I ran ../configure --update from my generated.x86gcc directory. Unfortunately, this didn't work either.

Question: ../configure --target-arch x86_gcc2 --target-arch x86 --distro-compatibility official --include-gpl-addons is run every time I execute my build script. Is this equivalent to using the --update option?

[anevilyak]

Replying to taos:

Question: ../configure --target-arch x86_gcc2 --target-arch x86 --distro-compatibility official --include-gpl-addons is run every time I execute my build script. Is this equivalent to using the --update option?

--update reruns configure while preserving your existing options, so it should be.

[luroh]

taos: can you tell us a bit more about the Haiku host you were trying to build on? hrev48678 doesn't seem to be a nightly build, so I'm guessing it's either something updated or home brewed.

For what it's worth, I seem to have no trouble building pure gcc2 images here on my pure gcc2 install built with the @nightly profile.

[taos]

It's been regularily updated via pkgman. I can try with one of my home brewed systems - if it's not too old. I don't have enough time to find an empty sd card to test with an anyboot image at the moment, maybe over the weekend.

[luroh]

Did it start its life as a downloaded nightly build at some point? Do you possibly remember its date of birth? I'd like to see if I can repeat things over here.

[bonefish]

Given that the compilation appears to be for the target (not the build host) the openssl packages installed on the build host are not relevant. Please remove the "build_packages/" directory in your generated directory and jam again. Please attach a full log, if it still fails.

[anevilyak]

Replying to bonefish:

Given that the compilation appears to be for the target (not the build host) the openssl packages installed on the build host are not relevant.

I mainly asked since I wondered if they were getting included from the host as seen in ticket #8730. Is it safe to assume that can't happen in this circumstance?

[taos]

Replying to luroh:

Did it start its life as a downloaded nightly build at some point? Do you possibly remember its date of birth? I'd like to see if I can repeat things over here.

Yes, it started its life as an installation from a downloaded nightly raw image in early August.

[taos]

Replying to bonefish:

Given that the compilation appears to be for the target (not the build host) the openssl packages installed on the build host are not relevant. Please remove the "build_packages/" directory in your generated directory and jam again. Please attach a full log, if it still fails.

I've tried a build from one of my self-compiled systems that's still on hrev48619 (openssl 1.0.0o). It didn't work. So, I'll now remove my generated directory completely and start over again (I think I've done this not so long ago - might have been around the time of the openssl update) to see what will happen. That will probably take at least 12 hours on my old machine here.

[bonefish]

Replying to anevilyak:

I mainly asked since I wondered if they were getting included from the host as seen in ticket #8730. Is it safe to assume that can't happen in this circumstance?

The failing jam actions refer to "<generated>/objects/haiku/..." which means it is related to the target portion of the build. Ticket #8730 only has to do with the host (build tools) portion, unless I have missed some other mention in the comments. Host headers (with the exception of host compiler headers, if the host compiler is used on Haiku) aren't used when building the target portion. Or if they are, that's a bug.

I suspect the issue is similar to #11194 in that the openssl packages weren't extracted correctly for some reason. The extraction directory exists -- so subsequent builds won't try to extract the packages again -- but the headers from the devel package are missing. Simply removing the directory, as suggested in comment:10, would fix the issue in this case.

[taos]

Thanks to outsourcing a lot of code in the last year, a complete build didn't take too much time.

Sorry for the noise, this ticket can be closed as invalid.

Thanks for your help!