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

libsfml-window.so does not link to udev #734

Closed
danijar opened this Issue Nov 7, 2014 · 13 comments

Comments

Projects
None yet
5 participants
@danijar
Contributor

danijar commented Nov 7, 2014

We just closed Issue #728 which was about static linkage. Now I build SFML again and tried to link it dynamically. When building my project, I get very similar error messages. So, unfortunately, the dependency handling isn't fixed completely yet.

<sfml>/lib/libsfml-window.so: undefined reference to `udev_device_new_from_subsystem_sysname'
<sfml>/lib/libsfml-window.so: undefined reference to `udev_device_unref'
<sfml>/lib/libsfml-window.so: undefined reference to `udev_device_get_property_value'
<sfml>/lib/libsfml-window.so: undefined reference to `udev_device_get_sysattr_value'
<sfml>/lib/libsfml-window.so: undefined reference to `udev_device_get_parent_with_subsystem_devtype'
<sfml>/lib/libsfml-window.so: undefined reference to `udev_unref'
<sfml>/lib/libsfml-window.so: undefined reference to `udev_new'

Same errors on Ubuntu 12.04 and 14.04. What do you think? How can we fix this?

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Nov 7, 2014

Member

I think the latest commit from @MarioLiebisch messed up sfml-window building a bit. UDEV_LIBRARIES was renamed to UDEV_LIBRARY in src/SFML/Window/CMakeLists.txt although that is not what the FindUDev.cmake script specifies. Replacing all occurences of UDEV_LIBRARY with UDEV_LIBRARIES (yes... including the one in FindSFML.cmake that works anyway, for consistency reasons) should fix this.

Member

binary1248 commented Nov 7, 2014

I think the latest commit from @MarioLiebisch messed up sfml-window building a bit. UDEV_LIBRARIES was renamed to UDEV_LIBRARY in src/SFML/Window/CMakeLists.txt although that is not what the FindUDev.cmake script specifies. Replacing all occurences of UDEV_LIBRARY with UDEV_LIBRARIES (yes... including the one in FindSFML.cmake that works anyway, for consistency reasons) should fix this.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Nov 7, 2014

Member

Hm... this is really odd. Everything builds for me properly using Linux Mint 17 (essentially Ubuntu 14.04). Did you just update CMake or start with an empty build directory? There've been issues in the past when switching between static/shared building.

Member

MarioLiebisch commented Nov 7, 2014

Hm... this is really odd. Everything builds for me properly using Linux Mint 17 (essentially Ubuntu 14.04). Did you just update CMake or start with an empty build directory? There've been issues in the past when switching between static/shared building.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Nov 7, 2014

Member

@binary1248 I think it actually defines both, have to check that again, although this doesn't solve why it's working for me... evil...

Edit: Okay, it doesn't, so let's go with UDEV_LIBRARIES everywhere? Or the more common UDEV_LIBRARY (since it's also just a single file)?

Member

MarioLiebisch commented Nov 7, 2014

@binary1248 I think it actually defines both, have to check that again, although this doesn't solve why it's working for me... evil...

Edit: Okay, it doesn't, so let's go with UDEV_LIBRARIES everywhere? Or the more common UDEV_LIBRARY (since it's also just a single file)?

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Nov 7, 2014

Member

@MarioLiebisch I checked... and searching for UDEV_LIBRARY didn't yield any results.

Member

binary1248 commented Nov 7, 2014

@MarioLiebisch I checked... and searching for UDEV_LIBRARY didn't yield any results.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Nov 7, 2014

Member

Yep, most likely something that sneaked in while reverting some other change (that didn't end up in the public commit/pull request). Just updating line 221 of sfml-window's CMakeLists.txt should fix this. Although this doesn't explain why I can still create makefiles from scratch and build successfully.

Member

MarioLiebisch commented Nov 7, 2014

Yep, most likely something that sneaked in while reverting some other change (that didn't end up in the public commit/pull request). Just updating line 221 of sfml-window's CMakeLists.txt should fix this. Although this doesn't explain why I can still create makefiles from scratch and build successfully.

@binary1248

This comment has been minimized.

Show comment
Hide comment
@binary1248

binary1248 Nov 7, 2014

Member

There are 2 options:

  1. Replace all UDEV_LIBRARIES (including the ones inside FindUDev.cmake) with UDEV_LIBRARY
  2. Replace all UDEV_LIBRARY with UDEV_LIBRARIES.

Whichever is chosen, it would be nice if things stayed consistent, so we don't end up using UDEV_LIBRARY in some places and UDEV_LIBRARIES in others.

Member

binary1248 commented Nov 7, 2014

There are 2 options:

  1. Replace all UDEV_LIBRARIES (including the ones inside FindUDev.cmake) with UDEV_LIBRARY
  2. Replace all UDEV_LIBRARY with UDEV_LIBRARIES.

Whichever is chosen, it would be nice if things stayed consistent, so we don't end up using UDEV_LIBRARY in some places and UDEV_LIBRARIES in others.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Nov 8, 2014

Member

So is anyone going to provide another PR or do I have to start my VM? 😉

Member

eXpl0it3r commented Nov 8, 2014

So is anyone going to provide another PR or do I have to start my VM? 😉

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Nov 8, 2014

Member

Theoretically it should be just that one variable name. Can't verify/test it though, since it builds for me properly (for whatever reason).

Member

MarioLiebisch commented Nov 8, 2014

Theoretically it should be just that one variable name. Can't verify/test it though, since it builds for me properly (for whatever reason).

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Nov 8, 2014

Member

Can't verify/test it though, since it builds for me properly (for whatever reason).

Don't forget to clear your CMake cache.

Member

LaurentGomila commented Nov 8, 2014

Can't verify/test it though, since it builds for me properly (for whatever reason).

Don't forget to clear your CMake cache.

@danijar

This comment has been minimized.

Show comment
Hide comment
@danijar

danijar Nov 10, 2014

Contributor

@MarioLiebisch Do you have a VM were it works and that you could share? I'd like to find out the differences between this and my fresh Ubuntu LTS installs. Maybe even one of the other guys finds the time to create a VM. It would be interesting so know which one of our systems is abnormal.

Contributor

danijar commented Nov 10, 2014

@MarioLiebisch Do you have a VM were it works and that you could share? I'd like to find out the differences between this and my fresh Ubuntu LTS installs. Maybe even one of the other guys finds the time to create a VM. It would be interesting so know which one of our systems is abnormal.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Nov 10, 2014

Member

@danijar Used a blank/fresh install of Linux Mint 17. I noticed that UDev actually isn't in my sfml-window_LIB_DEPENDS variable, yet it builds just fine. With the fixed variable (as described above) it's included once again, the library is linked once more during another call to make, but besides that, no difference.

Member

MarioLiebisch commented Nov 10, 2014

@danijar Used a blank/fresh install of Linux Mint 17. I noticed that UDev actually isn't in my sfml-window_LIB_DEPENDS variable, yet it builds just fine. With the fixed variable (as described above) it's included once again, the library is linked once more during another call to make, but besides that, no difference.

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Nov 10, 2014

Member

I had the issue with master under Debian and then applied @binary1248's fixes which seems to have worked, see #736

Member

eXpl0it3r commented Nov 10, 2014

I had the issue with master under Debian and then applied @binary1248's fixes which seems to have worked, see #736

@eXpl0it3r eXpl0it3r added this to the 2.2 milestone Nov 10, 2014

@eXpl0it3r eXpl0it3r self-assigned this Nov 10, 2014

@eXpl0it3r

This comment has been minimized.

Show comment
Hide comment
@eXpl0it3r

eXpl0it3r Nov 10, 2014

Member

Merged in e257909

Member

eXpl0it3r commented Nov 10, 2014

Merged in e257909

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