gmake: Add support for linker groups
KageKirin opened this issue · comments
Hi again,
another issue I plan on fixing while working on #434 is to have to precise the links libraries in correct order and with possible duplicates, lest the application or shared library will not link correctly.
To do so, I want to generate the linker command so that $LIBS is wrapped by -Wl,--start-group and -Wl,--end-group when using clang or gcc. This forces the linker to iterate over the libraries until no further symbols can get resolved. This lengthens the linking stage, but resolves more symbols without having to think about precising the libs in the correct order.
Full disclosure: I'm currently patching the generated makefiles with sed to this extent, but I'd prefer to have them generated by GENie in the correct way directly.
(here's my sed expression if someone needs it: sed -e "s|$$.LIBS.|-Wl,--start-group \\$$\\(LIBS\\) -Wl,--end-group|g").
Should I make this an optional modification as well or enforce it for clang and gcc?
Cheers.
I had this in the past, issue was clang / osx linker that didn't support it at all, so I removed support for it. Make sure all relevant linkers nowadays support this feature.
Sounds like I'll make it a buildflag then. This way it can be activated per toolchain (e.g. in BX' toolchain.lua).
Not build flag, but just make sure it works with clang. It's actually better just to be supported and default everywhere if possible.
As you've seen in. GENie/pull/436, it's on by default, but can be disabled with a flag.
Thanks for merging.
@bkaradzic I saw you reverted the commits from #436. Was there something not working with them?
@KageKirin I made comment here: #436 (comment)
Basically I couldn't compile GENie on Linux with clang 6.0, nor I could compile bgfx on OSX with clang 10.0. I would have to add NoLibGroups flag in order to do it. My assumption was that this link groups became available everywhere, and NoLibGroups was fine if only few project need to specify it.
Oh, that's... unfortunate.
I've been testing this with Android clang (8.0.2) on my large project and verified that the flags were mentioned in the clang documentation.
Android (5058415 based on r339409) clang version 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec746213857d083c0e8b0abb568790) (https://android.googlesource.com/toolchain/llvm 7a6618d69e7e8111e1d49dc9e7813767c5ca756a) (based on LLVM 8.0.2svn)
Ok, how do we proceed from here?
I can redo the changes, and this time make it optional, so projects that require -Wl,--start-group/-Wl,--end-group need to precise it in the build flags. I.e. basically turn the NoLibGroups flag into UseLibGroups.
What do you think?
Also, since what should I build BGFX with, as a test?
OSX/clang10
Is that the latest XCode's bundled clang or one to be installed separately (via brew)?
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I can redo the changes, and this time make it optional, so projects that require -Wl,--start-group/-Wl,--end-group need to precise it in the build flags. I.e. basically turn the NoLibGroups flag into UseLibGroups.
Yes. But use LinkSupportCircularDependencies name instead.
--start-group archives --end-group
The archives should be a list of archive files. They may be either explicit file names, or -l options.>The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that reference. By grouping the archives, they all be searched repeatedly until all possible references are resolved.
Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.
Alright. Will do so on Friday.
With #446 merged, I'm now closing this issue.