On 09/12/2015 18:43, William Dillon via swift-dev wrote:
I have no intention of addressing every issue here, but there is another I have a question about while I’m at it. While linking Swift.o, there is an undefined reference to __mulodi4. I found that __muloti4 is copied from compiler-rt into Stubbs.cpp to avoid new dependencies on compiler-rt in linux. I went ahead and copied __mulodi4 into the same file after __muloti4, but that seems a little hack-y.
I had the same issues with my proof-of-concept Linux i386 port. I also copied the __mulodi4 implementation from compiler-rt.
Is there a better way to get that symbol, and why wasn’t this a problem for x86_64?
AFAICS, this is a problem for x86_64 Linux. It's not a problem on Apple platforms, because there C++ binaries are linked with compiler-rt instead of the GCC runtime.
(also, is this: typedef int di_int __attribute__ ((mode (DI))); an appropriate way to define di_int?)
I think so.
Even with that hack, I’m still getting undefined references to __multi3 and __divti3.
I fixed that by disabling the __muloti4 implementation on i386 which created the references to __multi3 and __divti3:
https://github.com/nwellnhof/swift/commit/1a5962c890e43f115fc5d629a7b2ec108e1f489a#diff-197db3bb942ecdeff5ddb9e82c59de22 Nick _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
