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

vibe.d linking issue #558

Closed
dnadlinger opened this issue Dec 26, 2013 · 0 comments · Fixed by #559
Closed

vibe.d linking issue #558

dnadlinger opened this issue Dec 26, 2013 · 0 comments · Fixed by #559

Comments

@dnadlinger
Copy link
Member

Trying to build a simple vibe.d application with LDC yields the following undefined symbols (see e.g. vibe-d/vibe.d#388):

_D4vibe4data4bson14BsonSerializer25writeCompositeEntryHeaderMFE4vibe4data4bson4Bson4TypeZv7Wrapper3putMFaZv
_D4vibe4data4bson14BsonSerializer25writeCompositeEntryHeaderMFE4vibe4data4bson4Bson4TypeZv7Wrapper3putMFxAaZv

The issue is that we (correctly) detect them as being internal nested function, but the frontends appends some std.range templates to vibe.concurrency.core instead of vibe.data.bson, making compilation fail (as the internal function definitions are renamed during bitcode linking the two modules together).

I think the way to go is just to disable the internalizing feature as long as the related logic in the frontend isn't rock-solid.

dnadlinger added a commit to dnadlinger/ldc that referenced this issue Dec 26, 2013
This works around linking problems such as vibe-d/vibe.d#338,
caused by the frontend appending template instances to the wrong
module.

GitHub: Fixes ldc-developers#558.
redstar pushed a commit that referenced this issue Sep 27, 2014
remove bad contraints on overlapping rvalues of array operations
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 a pull request may close this issue.

1 participant