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

Possible overlinkage #203

Closed
ghisvail opened this issue Aug 23, 2016 · 2 comments
Closed

Possible overlinkage #203

ghisvail opened this issue Aug 23, 2016 · 2 comments

Comments

@ghisvail
Copy link
Contributor

The following warning were raised by the Debian packaging utility responsible for calculating the package dependencies:

dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/glbinding-tools/usr/bin/glmeta debian/glbinding-tools/usr/bin/glfunctions debian/glbinding-tools/usr/bin/glqueries debian/glbinding-tools/usr/bin/glcontexts were not linked against libGL.so.1 (they use none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/glbinding-tools/usr/bin/glmeta debian/glbinding-tools/usr/bin/glfunctions debian/glbinding-tools/usr/bin/glqueries debian/glbinding-tools/usr/bin/glcontexts were not linked against libpthread.so.0 (they use none of the library's symbols)

which usually suggests that the corresponding targets are overlinked. These may also be false positives. Please let me know.

Cheers,

@scheibel
Copy link
Member

scheibel commented Aug 29, 2016

Thanks for reporting.

Linking pthread:
Indeed, linking against pthread is only required for multi-threaded googlemock tests on some systems.
Maybe we can investigate further to eliminate this dependency.

Linking libGL:
Our current implementation of symbol address loading doesn't use dlopen on self to extract the addresses but relies on the GLX interface. I'm pretty sure we want to support other window toolkit APIs in the future and I'm not sure if we will use dlopen. Until then, this dependency seems unnecessary.
However, if we omit the linking of the libGL we have to test first what happens if glbinding is used in an application without the libGL (e.g., if an application programmer forgets to link or relies on its dependencies).

I will discuss the dependency removal with the other maintainers.

@scheibel
Copy link
Member

I tested several executables with dpkg-shlibdeps and got the following results:

$ dpkg-shlibdeps glcontexts 
dpkg-shlibdeps: error: no dependency information found for /home/scheibel/dev/glfw/lib/libglfw.so.3 (used by glcontexts)
Hint: check if the library actually comes from a package.
$ dpkg-shlibdeps cubescape
dpkg-shlibdeps: error: no dependency information found for /home/scheibel/dev/glfw/lib/libglfw.so.3 (used by cubescape)
Hint: check if the library actually comes from a package.
$ dpkg-shlibdeps glinfo 
dpkg-shlibdeps: error: no dependency information found for /home/scheibel/dev/glfw/lib/libglfw.so.3 (used by glinfo)
Hint: check if the library actually comes from a package.
$ dpkg-shlibdeps glmeta 
dpkg-shlibdeps: error: no dependency information found for /home/scheibel/dev/glbinding/build/libglbinding-aux.so.3 (used by glmeta)
Hint: check if the library actually comes from a package.

Thus, I could not reproduce this issue anymore. Is this still a problem? If so, please reopen this issue and provide more information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants