This is replacing hard-coded compiler/linker flags in the source code of the project with pkg-config sourced info - works fine on mac and debian derivatives by default for me, since they all provide pc files for libfdk-aac with the appropriate include and lib locations.
If both the static and dynamic versions exist in the system, this will pick-up the dynamic one by default (unless the whole build is -static). If ONLY the static version exist, the static version will be picked-up in all cases without any modification of the go source code.
If one wants to force static linking of JUST fdk-aac, when both dyn and static versions are available on the system, one can manually edit the lib pc file.
As for what should happen in the dockerfile / future binary distribution of this project, I do believe it should be built fully statically (possibly including glibc - but more on that later with an updated dockerfile).
@AlbanSeurat let me know if you think this is an acceptable trade-off.
I do believe the upsides are:
build will now work by default on all supported platforms, including anything with a non-standard location, as long as PKG_CONFIG_PATH is pointed in the right direction
picking your flavor (static vs. dynamic) is no longer a matter of changing go code and is properly delegated to the system
Suggestion to fix #22
This is replacing hard-coded compiler/linker flags in the source code of the project with pkg-config sourced info - works fine on mac and debian derivatives by default for me, since they all provide pc files for libfdk-aac with the appropriate include and lib locations.
If both the static and dynamic versions exist in the system, this will pick-up the dynamic one by default (unless the whole build is -static). If ONLY the static version exist, the static version will be picked-up in all cases without any modification of the go source code.
If one wants to force static linking of JUST fdk-aac, when both dyn and static versions are available on the system, one can manually edit the lib pc file.
As for what should happen in the dockerfile / future binary distribution of this project, I do believe it should be built fully statically (possibly including glibc - but more on that later with an updated dockerfile).
@AlbanSeurat let me know if you think this is an acceptable trade-off. I do believe the upsides are: