Everlasting configure error

[MG]

For many years, I encountered build errors like this but never found the actual problem or permanent solution:

While building openbox in a chroot:

checking whether the C compiler works... no
configure: error: in `/usr/ports/x11-wm/openbox/work/openbox-3.6':
configure: error: C compiler cannot create executables
See `config.log' for more details. A oneliner at the end of the file without any related action involved doesn't tell a lot.

- The compiler works with no problems. It does create executables.
- Config.log doesn't say anything of use. Error 77? Says who?
- It's is nearly impossible to trace back the cause due to the complexity if the configure code with all is variables and conditions.
- This time, the problem seems to be gone at the next build attempt in exactly the same circumstances. It wasn't necessary at all but breaks my build procedure and demands manual operation.
- I can't find the actual faulty command and it's output. That probably would be sufficient.

Is there any working approach to avoid wasting time on searching?

 

[Alain De Vos]

try:

rm -r /usr/ports/* /usr/ports/.??*
cd /usr/ports/
git clone --branch 2022Q4 https://git.FreeBSD.org/ports.git /usr/ports
mkdir /usr/ports/distfiles
mkdir /usr/ports/packages
cd /usr/ports/x11-wm/openbox
make

 

[MG]

try:

rm -r /usr/ports/* /usr/ports/.??*
cd /usr/ports/
git clone --branch 2022Q4 https://git.FreeBSD.org/ports.git /usr/ports
mkdir /usr/ports/distfiles
mkdir /usr/ports/packages
cd /usr/ports/x11-wm/openbox
make

This is kind of a static system with many involved ports and altered system sources. It builds allright, but it breaks on this, which is pretty frustrating regarding automation of the whole build. Is there really a problem?

Why should downloading this portstree from git help?

 

[zirias@]

- Config.log doesn't say anything of use. Error 77? Says who?

At least if GNU autotools is used, config.log is very verbose. You might have to scroll up a lot to find the actual error message....

 

[Alain De Vos]

This is kind of a static system with many involved ports and altered system sources. It builds allright, but it breaks on this, which is pretty frustrating regarding automation of the whole build. Is there really a problem?

Why should downloading this portstree from git help?

Maybe your current tree is not up to date ( i.e. now) or you made modifications producing errors.
In that case going to a "clean" , "recent" tree is the most logical way of solving problems.

 

[MG]

At least if GNU autotools is used, config.log is very verbose. You might have to scroll up a lot to find the actual error message....

Found something. It was trying to call clang80 which doesn't exist. But the output is overwritten, now no more errors. However, the extracted openbox portdir doesn't contain any reference to clang80.
Have to look to it again after the next build. Maybe a clang80->clang symlink in advance will solve it.

 

[MG]

Maybe your current tree is not up to date ( i.e. now) or you made modifications producing errors.
In that case going to a "clean" , "recent" tree is the most logical way of solving problems.

Call it a fork. It's a stripped down FreeBSD 12.3 to be fully running from RAM on POS systems. Minimal kernel, rc.d kicked out.... If I update the used ports, I will probably get 100 errors back for this.

 

[Alain De Vos]

Just be carefull, It could be in the long run you shoot yourself in the foot. Remaining to a system which is no longer in any way "upgradable" or where you can no longer install any package.