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

[SR-235] The package manager fails to link C static libraries #5439

Closed
swift-ci opened this issue Dec 15, 2015 · 9 comments
Closed

[SR-235] The package manager fails to link C static libraries #5439

swift-ci opened this issue Dec 15, 2015 · 9 comments
Labels

Comments

@swift-ci
Copy link
Contributor

Previous ID SR-235
Radar None
Original Reporter valentinradu (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment

OS: OSX El Capitan
Toolchain: swift-2.2-SNAPSHOT-2015-12-01-a

Additional Detail from JIRA
Votes 0
Component/s Package Manager
Labels Bug
Assignee valentinradu (JIRA)
Priority Medium

md5: 9e4f456ddc0b50ca3c704f851d707f05

Issue Description:

Out of the box, with no tweaks or workarounds, trying to link a C system module pointing to a static library fails. It works fine when the same library is dynamic.

An example module map:

module CFCGI [system] {
header "/usr/local/include/cfcgi/cfcgi.h"
link "cfcgi"
export *
}

And the output:

swift build --clean && swift build -v
Cloning into '/Users/valentinradu/Playgrounds/April/Packages/libcfcgi'...
warning: --depth is ignored in local clones; use file:// instead.
done.
/Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-01-a.xctoolchain/usr/bin/swiftc -module-name April -incremental -emit-dependencies -emit-module -emit-module-path /Users/valentinradu/Playgrounds/April/.build/debug/April.swiftmodule -output-file-map /Users/valentinradu/Playgrounds/April/.build/debug/April.o/April/output-file-map.json -c /Users/valentinradu/Playgrounds/April/Sources/main.swift -I /Users/valentinradu/Playgrounds/April/.build/debug -j8 -Onone -g -target x86_64-apple-macosx10.10 -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -Xcc -F-module-map=/Users/valentinradu/Playgrounds/April/Packages/libcfcgi-1.0.0/module.modulemap -I /Users/valentinradu/Playgrounds/April/Packages/libcfcgi-1.0.0 -I /usr/local/include
/Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-01-a.xctoolchain/usr/bin/swiftc -o /Users/valentinradu/Playgrounds/April/.build/debug/April /Users/valentinradu/Playgrounds/April/.build/debug/April.o/Sources/main.swift.o -Xlinker -all_load -target x86_64-apple-macosx10.10 -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -L/usr/local/lib
Undefined symbols for architecture x86_64:
"_cfcgi_create", referenced from:
_main in main.swift.o
"_cfcgi_free", referenced from:
_main in main.swift.o
"_cfcgi_start_and_wait", referenced from:
_main in main.swift.o
ld: symbol(s) not found for architecture x86_64
<unknown>:0: error: build had 1 command failures
swift-build: exit(1): ["/Library/Developer/Toolchains/swift-2.2-SNAPSHOT-2015-12-01-a.xctoolchain/usr/bin/swift-build-tool", "-v", "-f", "/Users/valentinradu/Playgrounds/April/.build/debug/April.o/llbuild.yaml"]

It looks like the linker ignores the `link cfcgi` part.

Additional info:

  • libcfcgi.a is in /usr/local/lib and it’s compiled for x86_64

  • libcfcgi.a contains the above mentioned symbols, tested it with nm and linked it in a small C program: it works.

@drewcrawford
Copy link
Contributor

I've PRed a workaround for this issue, #107. If that PR is merged, we can say

extraLinkerOptions: ["-Lpath/to/folder", "-lcfcgi"] 

to work around this bug.

@mxcl
Copy link
Contributor

mxcl commented Jan 8, 2016

So this doesn't work even though the library path is:

/usr/local/lib/libcfgi.a

?

@swift-ci
Copy link
Contributor Author

swift-ci commented Jan 8, 2016

Comment by Valentin Radu (JIRA)

Yes, that is correct. It does work if the library is dynamic, in the same location: `/usr/local/lib/libcfgi.dylib`

@swift-ci
Copy link
Contributor Author

swift-ci commented Mar 1, 2016

Comment by James Richard (JIRA)

I had a similar problem where the .a file was targeted for Mac OS, but the build system was Linux, so it couldn't find the symbols. Could your .a have been built improperly, such as that, or only with 32bit support?

@swift-ci
Copy link
Contributor Author

swift-ci commented Mar 1, 2016

Comment by Valentin Radu (JIRA)

Yes, the lib was properly built. I had the exact same lib linked manually with clang in C and it worked.

@swift-ci
Copy link
Contributor Author

Comment by Dr. Kibitz (JIRA)

I had a similar issue while trying to link against libgit2, which was installed in '/usr/local/lib'.

After some fighting, I finally landed on this issue and landed on doing this:

swift build -v -Xlinker -L/usr/local/lib

Some more info is when I was inspecting the output of `swift build -v`. I noticed that it was specifying '-sdk' as '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk'

Just for testing, I tried this:

ln -s /usr/local/lib/libgit2.dylib /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib

With that, just plain ol' `swift build -v` works. I really think `/usr/local` should be a default, and wonder why it's not.

@swift-ci
Copy link
Contributor Author

swift-ci commented Apr 1, 2016

Comment by Valentin Radu (JIRA)

@mxcl This is fixed in swift-DEVELOPMENT-SNAPSHOT-2016-03-24. Should I close it, or needs to be tested by you guys?

@mxcl
Copy link
Contributor

mxcl commented Apr 2, 2016

I'll verify. Thanks.

@abertelrud
Copy link
Contributor

If this is verified as fixed by the originator, then it can be closed. Sending back as resolved.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 4, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants