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

Builds static library with relocatable code (-fPIC) #89

Open
yurivict opened this issue Apr 29, 2020 · 3 comments
Open

Builds static library with relocatable code (-fPIC) #89

yurivict opened this issue Apr 29, 2020 · 3 comments

Comments

@yurivict
Copy link

The static library doesn't need relocatable code because it would marginally hurt performance in static executables.

@jan-wassenberg
Copy link
Member

We're sharing the object files between the .a and .so. To keep the build simple, do you think we could tolerate the slight overhead of relocations in the static library?

@yurivict
Copy link
Author

For example, this project https://github.com/ccxvii/mujs performs compilation for static and shared libraries separately.

cc -std=c11 -pedantic -Wall -Wextra -Wno-unused-parameter -I/usr/local/include -O3  -DHAVE_READLINE -DJS_INSTRUCTION=int -fPIC -shared -o build/release/libmujs.so one.c -lm
cc -std=c11 -pedantic -Wall -Wextra -Wno-unused-parameter -I/usr/local/include -O3  -DHAVE_READLINE -DJS_INSTRUCTION=int -o build/release/libmujs.o -c one.c

@jan-wassenberg
Copy link
Member

@yurivict Unfortunately my make skills are reaching their limits here. We conditionally extend the list of object files depending on the target macros, and I think it would be undesirable to have two sets of them so that the SO can depend on the fPIC objs and others on the non-fPIC.
Again, is the overhead of relocations costly enough to justify the more complex build?

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

No branches or pull requests

2 participants