-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
compilers: Try harder to dedup builtin libs
-ldl, -lm, -lpthread should always be de-duplicated, no matter what. Closes #2150
- Loading branch information
Showing
2 changed files
with
17 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8b06553
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks too specific to those libraries. If I go and add a dependency on e.g. libnuma or libpcap to the base DPDK EAL library, for instance, I will hit exactly the same problems.
Looking at the build.ninja file generated, it appears that all the library flags are being enclosed in "--start-group" and "--end-group" flags, which means that all "-l" flags can be deduplicated as they won't be needed more than once.
8b06553
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is indeed too specific to these libraries, but this is a fix that can go into the stable release since it's low-risk.
Generally, external dependencies are resolved to the full path to the
.a
,.so
,.dylib
, or.lib
, so this shouldn't be happening for other libraries. We made it so that-L
and-l
pairs are added as-is for a 'conservative' fix to the problem of always picking libraries from the correct-L
path. I think changing that code will definitely lead to regressions, so it's something for the next release if someone wants to work on it.8b06553
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, understood on the risk aspect. Can you perhaps also include "-lexecinfo" into the list, as it's a frequently needed library on freebsd.
8b06553
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, no problem.