libbsc
libbsc copied to clipboard
IlyaGrebnov
makefile improvements, enable dynamic library
A question - I had to disable -mavx2 when building on my system (arm64 macOS), are there similar optimization flags for arm64?
A question - I had to disable
-mavx2when building on my system (arm64 macOS), are there similar optimization flags for arm64?
ARM Neon optimizations are enabled by default for Arm64 targets. I will look into PR later today. Thank you for contribution.
I tried a new Makefile and encountered the following error:
g_QlfcStatisticalModel1' cannot be used when creating a shared object; recompile with -fPIC.
Additionally, there are other issues:
-
Clang is not being used for compilation; instead, GCC is used. -
OpenMP support is not enabled.
I tried a new Makefile and encountered the following error:
g_QlfcStatisticalModel1' cannot be used when creating a shared object; recompile with -fPIC. Additionally, there are other issues:
Where is this g_QlfcStatisticalModel1? I might need to add -fPIC when compiling that file. I'm not very familiar with this flag tho, is it recommended to add it to all object files?
Clang is not being used for compilation; instead, GCC is used.OpenMP support is not enabled.
I have added the ability to specify these as args. You want CC=clang CXX=clang++ or whatever your compiler filenames are, and OPENMP=1. I added these as they make it easier for automated builds (I'm using MacPorts).
Clang and OpenMP is needed for optimal performance, so it would be great if we can use it by default without need of additional make parameters. As of PIC (position independent code) I am not sure myself, but likely we just missing -fPIC somewhere as suggested by compiler.
@i0ntempest Please also drop hardcoding of libc++, that is unnecessary when that runtime is used and breaking when libstdc++ is used instead (which is the default with GCC outside of MacPorts, as well as the default on < 10.9).
@i0ntempest Please also drop hardcoding of
libc++, that is unnecessary when that runtime is used and breaking whenlibstdc++is used instead (which is the default with GCC outside of MacPorts, as well as the default on < 10.9).
@barracuda156 It is necessary on my end, when not using Xcode clang. Without it I get undefined symbols. Also it’s hardcoded in the portfile only.
Also it’s hardcoded in the portfile only.
Well that is easy to fix then, just do it as
if {${configure.cxx_stdlib} eq "libc++"} {
. . .
}
So that this does not break GCC builds.
Greetings! Is this PR still being worked upon?
I did small changes in makefile before reading through this PR and finding out that some of the things are addressed in comments here (such as using CXXFLAGS and duplication in rules).
It's here if you're interested: https://github.com/iam28th/libbsc/pull/1/files
It is but I've been busy with life so didn't make any progress recently. I'll take a look at your changes later.
This PR no longer relevant as I Replaced makefile with modern CMake build file.
@IlyaGrebnov It would be useful to have a switch to disable arch optimizations even when the flag is supported. That is needed when a package is built on a buildbot for distribution (which is what FreeBSD, MacPorts etc. do). Otherwise that has to be patched out, and if it goes unnoticed, then end-users may get a package with incompatible or suboptimal optimizations.
P. S. If you care to add optimizations for powerpc (platform-agnostic, gonna apply to Linux just as well), then possible choices are -mtune= or -mcpu= (can be combined, -mtune= is safer, it retains compatibility across cpu subtypes).
@barracuda156 That makes sense; thanks for the explanation. I’ll work on this over the next few days.
Regarding architecture‑specific optimizations: as of 2022 on AArch64, -march=native now implies -mcpu=native (just as it does on x64), making it the platform‑agnostic choice.
@IlyaGrebnov -march= is not a valid flag on powerpc. If it is passed unconditionally, compiler will error out, but here CMake is supposed to check for its support, so it just won’t be used.
@barracuda156 I have added an option to disable platform-native optimizations. And since code does not have any PowerPC-specific tuning (unlike the x64 code which benefits from AVX2 and SSE intrinsics), falling back to the generic compiler optimizations is fine.