Solved Multiple packages fails to build.

[ayleid96]

llvm, godot, libaac and many other packages just fails to build, i don't use any special flags besides in /etc/make.conf:

CFLAGS=-O2 -pipe
CPUTYPE=sandybridge

Everytime i make sure to update ports tree but this is just getting annoying. How can someone put a package when it fails to build on other systems? This is not the first time, i am seriously thinking to switch back to binary packages. I am not looking to solution here, i am just asking, does anybody have similar problems?

EDIT:
I am on 13.1-RELEASE.

 

[SirDice]

i don't use any special flags besides in /etc/make.conf:

Remove those CFLAGS. Do NOT set these unless you know what you are doing.

 

[jbo@]

How can someone put a package when it fails to build on other systems?

While not perfect, port updates are of course reviewed & tested.

This is not the first time, i am seriously thinking to switch back to binary packages.

Those are just build from the same ports. If there would be something inherently wrong with a port it would also fail to build for the official binary repositories and it would be marked as broken.

I am not looking to solution here, i am just asking, does anybody have similar problems?

No really. I started building my own packages about a year ago. Haven't had a single "non-explainable" issue. I'm also building literally every version of llvm.
I'd say the most attention goes into the package configurations

As SirDice said: Don't screw around with `CFLAGS` unless you know exactly what you're doing. Those flags would be applied to EVERY port you're compiling. This is most definitely not what you want.
Also, when setting CPUTYPE be sure that you're actually on that CPU type. This can be especially troublesome if you build packages in a centralized location and expect multiple clients to use the same repositories. Personally, I just don't specify CPUTYPE unless I have a separate, isolated system (such as an edge router).

 

[zirias@]

How can someone put a package when it fails to build on other systems?

Any port maintainer will test what they change before committing, at least with all-default options. So, build errors without customizations are rare. They still happen (an update to one port could for example break a dependent port), but then, they will be noticed quickly – the official package builders will send out "fallout" mail.

As soon as you change anything (even just some ports' options), expect to run into build errors every now and then. A good maintainer does extensive testing, but it's virtually impossible to test every possible configuration.

As SirDice hinted, fiddling with CFLAGS is especially dangerous. E.g. there might be upstream sources that just don't work with -O2, so better don't enforce it. Upstream ideally decides which optimization level makes sense. Even worse, some upstream build systems actually replace their default flags with the user-specified ones instead of merging them, so flags required for building this specific source might be missing...

As for CPUTYPE, this should rarely cause problems. But it won't buy you much (typically not even measurable) either. It will make the built packages non-portable though, so if you think about creating a repo with e.g. poudriere for multiple machines, drop it.

 

[VladiBG]

How much RAM memory you have when you try to build LLVM?

 

[zirias@]

VladiBG that's a valid concern for very large ports like llvm, still there are small ports on the list as well, so better first fix the "obvious" things

Concerning CFLAGS just gotta share this nice gentoo bug report (it's a classic!)

 

[Alain De Vos]

llvm is rather robust, it compiles fine for me. But like SirDice said only do it when you know what you are doing.
Just remove all flags and check if it works fine.

MYFLAGS="-fno-lto -O2 -pipe -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS -fstack-protector -fexceptions -fvisibility=default -fomit-frame-pointer"
CPUTYPE?=core-avx-i
#10
DEFAULT_VERSIONS+=llvm=13

 

[ayleid96]

Remove those CFLAGS. Do NOT set these unless you know what you are doing.

I am using sandybridge CPU, for like 7 years already I am using these flags, -O2 -pipe without any problem, why are these very simple flags suddenly a problem now?

 

[SirDice]

why are these very simple flags suddenly a problem now?

Ports already set the "best"[*] compiler settings, you are trampling all over it with those settings. Why is this suddenly a problem? Don't know. But setting CFLAGS globally in make.conf eventually always results in weird build issues or other odd instabilities. Best course of action, don't set them, at all. Rebuild everything with the options removed and I'm sure that most of your issues are going to disappear.

[*] That doesn't necessarily mean they're the most optimized, just that the compiler settings are going to cause the least amount of issues down the line.

 

[zirias@]

It's almost as if jbodenmann's (and my) answer was completely ignored ...

Just to elaborate a bit on the problem of globally enforcing compiler optimizations: -O2 only does "typically safe" optimizations (and even -O3 is completely safe if the code compiled is fully correct without any UB, but you'd be surprised how often this just isn't the case) and still, it contains optimizations relying e.g. on code correctly following aliasing rules. It will break some incorrect code. While this typically only manifests at runtime, it can affect tools that are later used for building something else, so you'll run into build issues.

For inconsistent handling of user-specified CFLAGS, also a very common problem, see my answer above.

Just accept it, globally setting CFLAGS is begging for trouble. You can never be sure unless you remove them (and rebuild everything).

 

[Jose]

Concerning CFLAGS just gotta share this nice gentoo bug report (it's a classic!)

I am intrigued by -ftree-dominator-opts. Sounds powerful!

 

[ayleid96]

Ports already set the "best"[*] compiler settings, you are trampling all over it with those settings. Why is this suddenly a problem? Don't know. But setting CFLAGS globally in make.conf eventually always results in weird build issues or other odd instabilities. Best course of action, don't set them, at all. Rebuild everything with the options removed and I'm sure that most of your issues are going to disappear.

[*] That doesn't necessarily mean they're the most optimized, just that the compiler settings are going to cause the least amount of issues down the line.

Thank you for clarification. I will remove them. I will instead try to build certain apps with -O2 -pipe if they don’t have those already in makefile.

It's almost as if jbodenmann's (and my) answer was completely ignored ...

Just to elaborate a bit on the problem of globally enforcing compiler optimizations: -O2 only does "typically safe" optimizations (and even -O3 is completely safe if the code compiled is fully correct without any UB, but you'd be surprised how often this just isn't the case) and still, it contains optimizations relying e.g. on code correctly following aliasing rules. It will break some incorrect code. While this typically only manifests at runtime, it can affect tools that are later used for building something else, so you'll run into build issues.

For inconsistent handling of user-specified CFLAGS, also a very common problem, see my answer above.

Just accept it, globally setting CFLAGS is begging for trouble. You can never be sure unless you remove them (and rebuild everything).

I didn’t ignore it, sorry. Can I at least keep CPUTYPE?

 

[zirias@]

I will remove them. I will instead try to build certain apps with -O2 -pipe if they don’t have those already in makefile.

Note that optimization flags are typically set upstream, not in the port ... so you'd have to look into the distfile to know. Although there might be cases of upstream maintainers who just don't care, most often they will set what they consider appropriate for a "release" build of their software.

Can I at least keep CPUTYPE?

I think I addressed that? Probably yes, it would be very uncommon that this would break things. But most of the time, there's very little to gain and the price you pay is a binary package that only works on that specific CPU (class).

I am intrigued by -ftree-dominator-opts. Sounds powerful!

Uhm, Angry Ent in action?

 

[ayleid96]

Note that optimization flags are typically set upstream, not in the port ... so you'd have to look into the distfile to know. Although there might be cases of upstream maintainers who just don't care, most often they will set what they consider appropriate for a "release" build of their software.

I think I addressed that? Probably yes, it would be very uncommon that this would break things. But most of the time, there's very little to gain and the price you pay is a binary package that only works on that specific CPU (class).


Uhm, Angry Ent in action?

Gotcha, I understand. Thank you, I will mark this thread as solved.

 

[Alain De Vos]

I just switched from "aggressive" flags to "conservative" flags:

MYFLAGS="-fno-lto -O2 -pipe"
.if ${.CURDIR:M*/usr/ports*}
CFLAGS+="${MYFLAGS}"
CXXFLAGS+="${MYFLAGS}"
.endif
CPUTYPE?=core-avx-i