Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Tweak the compiler's default linkage for dylibs #404

Closed

Conversation

alexcrichton
Copy link
Member

When the compiler generates a dynamic library, alter the default behavior to
favor linking all dependencies statically rather than maximizing the number of
dynamic libraries. This behavior can be disabled with the existing
-C prefer-dynamic flag.

Rendered

When the compiler generates a dynamic library, alter the default behavior to
favor linking all dependencies statically rather than maximizing the number of
dynamic libraries. This behavior can be disabled with the existing
`-C prefer-dynamic` flag.
@wycats
Copy link
Contributor

wycats commented Oct 21, 2014

Looks good to me. We have hit this issue in Skylight 😄

In english, the compiler will change its heuristics for when a dynamic library
is being generated. When doing so, it will attempt to link all dependencies
statically, and failing that, will continue to maximize the number of dynamic
libraries which are linked in.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason to not try to maximize the number of static libraries unless -C prefer-dynamic is passed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's mostly a matter of taste for which heuristic we think is best to do by default. Invariably each one will be right in some cases and wrong in others. I would intuitively expect that if any dynamic libraries must be linked, then you may as well choose as many others as possible.

Additionally, dynamic libraries impose restrictions to what kinds of other libraries can be linked. The compiler ensures that each library appears only once, so if an rlib A is linked to dylibs B/C (statically into both), you can't link B and C into any other future products because it would include the library A twice. I think that if each dylib maximizes the number of dylibs it links to (which is hopefully the case if they're all intermediate products) then it may be best to continue maximizing, but if each dylib separately maximizes the number of static libraries then it's likely that they're mostly incompatible.

I'm really sure which way is the best option, I think there may be downsides to both. Supposedly we need a distinction between an intermediate dylib and an end-product dylib where an intermediary maximizes dylib deps while an end-product minimizes dylib deps, but that's also somewhat complicated...

@Valloric
Copy link

👍 This is the right approach.

@nrc
Copy link
Member

nrc commented Oct 31, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants