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

Option to build app as a shared library #57

Closed
code-disaster opened this issue Feb 19, 2015 · 7 comments
Closed

Option to build app as a shared library #57

code-disaster opened this issue Feb 19, 2015 · 7 comments
Labels

Comments

@code-disaster
Copy link
Contributor

E.g. via fips_begin_app({name} shared).

@floooh
Copy link
Owner

floooh commented Feb 20, 2015

I would rather add a new keyword 'fips_begin_sharedlib()'? I currently don't have a use case for shared libs, and might not be able to test this well on all platforms though.

@floooh
Copy link
Owner

floooh commented Feb 24, 2015

I have added a fips_begin_sharedlib()/fips_end_sharedlib() macro, and added a very simple example to fips-hello-dep1 (https://github.com/floooh/fips-hello-dep1/blob/master/src/sharedlib_test/CMakeLists.txt), I only quickly tested compilation on OSX (results in a .dylib file) and Windows, the DLL is built to fips-deploy/[project]/[config].

Let me know if I forgot something :)

@floooh
Copy link
Owner

floooh commented Feb 24, 2015

Reminder for Linux:

Linking CXX shared library /home/travis/build/floooh/fips-deploy/fips-hello-dep1/linux-make-debug/libdep1shared.so

/usr/bin/ld: ../dep1/libdep1.a(dep1.cc.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC

../dep1/libdep1.a: could not read symbols: Bad value

collect2: error: ld returned 1 exit status

make[2]: *** [/home/travis/build/floooh/fips-deploy/fips-hello-dep1/linux-make-debug/libdep1shared.so] Error 1

make[1]: *** [src/sharedlib_test/CMakeFiles/dep1shared.dir/all] Error 2

make[1]: *** Waiting for unfinished jobs....

[100%] Built target dep1test

@code-disaster
Copy link
Contributor Author

For some reason I don't understand, dependencies are not handled properly yet. I have a shared library with one module using "fips_libs(OpenGL32)" which fails to link because of missing GL symbols. Debug CMake output indicates that the module is processed after the shared lib.

OS X links fine. Linux gives a linker relocation error similar to yours above.

edit:

I "fixed" the dependency issue by changing the order in which fips_add_subdirectory() was called, moving the directory which contains the shared library after the module which depends on OpenGL32.lib.

It may be unreasonably complicated to change the system to be independent of declaration order of modules, which would probably mean to defer all the fips_end_*() logic until the fips_finish() call.

@floooh
Copy link
Owner

floooh commented Feb 26, 2015

Hmm, good catch, I can reproduce this by moving the Oryol samples includes above the modules in the root CMakeLists.txt. I'll open a separate ticket for this, but I agree that moving dependency resolution to the end might be too complex... I'll put at least a note into the docs for now.

@floooh
Copy link
Owner

floooh commented Feb 25, 2016

Can I close this ticket?

@code-disaster
Copy link
Contributor Author

Sure. :)

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

2 participants