Hi,
I'm trying to compile an application[1]. The compilation succeeds, but fails at the last linking step like this.
LINK(target) out/Release/Brackets /usr/bin/ld: warning: libudev.so.0, needed by Release/libcef.so, not found (try using -rpath or -rpath-link) LINK(target) out/Release/Brackets: Finished
When I search with `repoquery -f */libudev*', I get back systemd-libs and systemd-devel; both of which are installed. systemd-libs provides /usr/lib64/libudev.so.1, and systemd-devel provides /usr/lib64/libudev.so, which is a symlink to the actual library. I'm not sure what I'm doing wrong.
Any ideas?
Thanks,
Footnotes:
[1] https://github.com/adobe/brackets-shell/wiki/Building-brackets-shell
On 05/13/14 07:13, Suvayu Ali wrote:
I'm trying to compile an application[1]. The compilation succeeds, but fails at the last linking step like this.
LINK(target) out/Release/Brackets /usr/bin/ld: warning: libudev.so.0, needed by Release/libcef.so, not found (try using -rpath or -rpath-link) LINK(target) out/Release/Brackets: Finished
When I search with `repoquery -f */libudev*', I get back systemd-libs and systemd-devel; both of which are installed. systemd-libs provides /usr/lib64/libudev.so.1, and systemd-devel provides /usr/lib64/libudev.so, which is a symlink to the actual library. I'm not sure what I'm doing wrong.
Any ideas?
libudev.so.0 ≠ libudev.so.1
Along with that, from [1]
"Currently, the core Brackets team only supports Debian/Ubuntu as a development environment and for our binary packages"
On Tue, May 13, 2014 at 01:13:31AM +0200, Suvayu Ali wrote:
Hi,
I'm trying to compile an application[1]. The compilation succeeds, but fails at the last linking step like this.
LINK(target) out/Release/Brackets /usr/bin/ld: warning: libudev.so.0, needed by Release/libcef.so, not found (try using -rpath or -rpath-link) LINK(target) out/Release/Brackets: Finished
When I search with `repoquery -f */libudev*', I get back systemd-libs and systemd-devel; both of which are installed. systemd-libs provides /usr/lib64/libudev.so.1, and systemd-devel provides /usr/lib64/libudev.so, which is a symlink to the actual library. I'm not sure what I'm doing wrong.
To clarify, I know I can probably solve this by symlinking /usr/lib64/libudev.so.0 to /usr/lib64/libudev.so.1, but I would really like to avoid hackish solutions like that. Moreover, I thought this kind of issues should be handled by the /usr/lib64/libudev.so symlink. Does that mean the brackets project has a buggy build system? Or does the fault lie with Fedora?
Cheers,
Hi Ed,
On Tue, May 13, 2014 at 07:25:31AM +0800, Ed Greshko wrote:
On 05/13/14 07:13, Suvayu Ali wrote:
I'm trying to compile an application[1]. The compilation succeeds, but fails at the last linking step like this.
LINK(target) out/Release/Brackets /usr/bin/ld: warning: libudev.so.0, needed by Release/libcef.so, not found (try using -rpath or -rpath-link) LINK(target) out/Release/Brackets: Finished
When I search with `repoquery -f */libudev*', I get back systemd-libs and systemd-devel; both of which are installed. systemd-libs provides /usr/lib64/libudev.so.1, and systemd-devel provides /usr/lib64/libudev.so, which is a symlink to the actual library. I'm not sure what I'm doing wrong.
Any ideas?
libudev.so.0 ≠ libudev.so.1
Yes, for precompiled binaries that should be true. But if there are no backwards incompatible changes, I should be able to build just fine with libudev.so.1. The error above is during the build. If I'm building from source, it should just work, isn't it?
Along with that, from [1]
"Currently, the core Brackets team only supports Debian/Ubuntu as a development environment and for our binary packages"
Yes, I know that. That is why I was building from source. Anyway, in the end I extracted the deb, and did the symlink hack to get it running. Although I have the feeling their build system is quite broken.
Cheers,
PS: More and more I'm noticing, all these new projects doesn't have any semblance of decent packaging. They just seem to throw some stuff together with hardcoded or relative paths, and say try it. Every community seems to have its own package manager. In this particular case it (npm) couldn't detect the system wide libraries, and dragged them in again!
On 05/13/14 08:07, Suvayu Ali wrote:
Yes, I know that. That is why I was building from source. Anyway, in the end I extracted the deb, and did the symlink hack to get it running. Although I have the feeling their build system is quite broken.
Cheers,
PS: More and more I'm noticing, all these new projects doesn't have any semblance of decent packaging. They just seem to throw some stuff together with hardcoded or relative paths, and say try it. Every community seems to have its own package manager. In this particular case it (npm) couldn't detect the system wide libraries, and dragged them in again!
You can do as you wish.... Just happen to have an old F17 system and with it comes libudev.so.0.
Maybe it will work to do what you did, maybe it won't. I've found that doing such is a recipe for disaster down the road.
On 05/13/2014 01:26 AM, Suvayu Ali wrote:
On Tue, May 13, 2014 at 01:13:31AM +0200, Suvayu Ali wrote:
Hi,
I'm trying to compile an application[1]. The compilation succeeds, but fails at the last linking step like this.
LINK(target) out/Release/Brackets /usr/bin/ld: warning: libudev.so.0, needed by Release/libcef.so, not found (try using -rpath or -rpath-link) LINK(target) out/Release/Brackets: Finished
This kind of warning (Why is this not an error? It should be one!), could have different causes.
I'd guess, you are trying to link something against a pre-build library binary (Release/libcef.so), which was built against libudev.so.0. I.e. this Release/libcef.so is incompatible to Fedora.
The appropriate fix for this would be rebuild libcef.so from source against the libudev from Fedora. Should this be closed source, you've lost.
To clarify, I know I can probably solve this by symlinking /usr/lib64/libudev.so.0 to /usr/lib64/libudev.so.1, but I would really like to avoid hackish solutions like that.
Well, you don't want to do this - You REALLY don't want to do this! :-)
Moreover, I thought this kind of issues should be handled by the /usr/lib64/libudev.so symlink.
Correct. Linking is supposed to use -ludev, which will pickup the libudev.so in GCC's linker path.
Does that mean the brackets project has a buggy build system?
Probably, but the build-log is not verbose enough to be sure about it (Which is a bug on its own).
Or does the fault lie with Fedora?
Ralf
On Mon, May 12, 2014 at 4:13 PM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
Hi,
I'm trying to compile an application[1]. The compilation succeeds, but fails at the last linking step like this.
LINK(target) out/Release/Brackets /usr/bin/ld: warning: libudev.so.0, needed by Release/libcef.so, not found (try using -rpath or -rpath-link) LINK(target) out/Release/Brackets: Finished
When I search with `repoquery -f */libudev*', I get back systemd-libs and systemd-devel; both of which are installed. systemd-libs provides /usr/lib64/libudev.so.1, and systemd-devel provides /usr/lib64/libudev.so, which is a symlink to the actual library. I'm not sure what I'm doing wrong.
CEF in this case seems to be the Chromium Embedded Framework. The buildsystem for brackets grabs a binary version of CEF from an Adobe server. Presumably this is built on one of Debian or Ubuntu with libudev.so.0.
The "proper" way to fix it would be to build CEF on your own [1], which would give you a copy of CEF linked to the proper version of udev. You can then plop the libcef.so you built in place of the Adobe-provided binary and use that, and linking should work as normal.
However, building anything chromium-related is...fun to say the least. I wouldn't judge you if you just ran 'ln -sf libudev.so.1 libudev.so.0' and hoped it doesn't segfault. :-)
-T.C.
[1] https://code.google.com/p/chromiumembedded/wiki/BranchesAndBuilding
Hi TC, and Ralf,
On Mon, May 12, 2014 at 06:56:45PM -0700, T.C. Hollingsworth wrote:
On Mon, May 12, 2014 at 4:13 PM, Suvayu Ali fatkasuvayu+linux@gmail.com wrote:
Hi,
I'm trying to compile an application[1]. The compilation succeeds, but fails at the last linking step like this.
LINK(target) out/Release/Brackets /usr/bin/ld: warning: libudev.so.0, needed by Release/libcef.so, not found (try using -rpath or -rpath-link) LINK(target) out/Release/Brackets: Finished
When I search with `repoquery -f */libudev*', I get back systemd-libs and systemd-devel; both of which are installed. systemd-libs provides /usr/lib64/libudev.so.1, and systemd-devel provides /usr/lib64/libudev.so, which is a symlink to the actual library. I'm not sure what I'm doing wrong.
CEF in this case seems to be the Chromium Embedded Framework. The buildsystem for brackets grabs a binary version of CEF from an Adobe server. Presumably this is built on one of Debian or Ubuntu with libudev.so.0.
The "proper" way to fix it would be to build CEF on your own [1], which would give you a copy of CEF linked to the proper version of udev. You can then plop the libcef.so you built in place of the Adobe-provided binary and use that, and linking should work as normal.
That makes perfect sense with what I'm seeing.
However, building anything chromium-related is...fun to say the least. I wouldn't judge you if you just ran 'ln -sf libudev.so.1 libudev.so.0' and hoped it doesn't segfault. :-)
In the end I resorted to extracting the deb, and moving the compiled binaries to /opt, followed by symlinking libudev; no segfaults. Since it is in /opt, I do mind the symlink as much.
Cheers,
On Tue, May 13, 2014 at 08:42:19AM +0800, Ed Greshko wrote:
On 05/13/14 08:07, Suvayu Ali wrote:
Yes, I know that. That is why I was building from source. Anyway, in the end I extracted the deb, and did the symlink hack to get it running. Although I have the feeling their build system is quite broken.
You can do as you wish.... Just happen to have an old F17 system and with it comes libudev.so.0.
Maybe it will work to do what you did, maybe it won't. I've found that doing such is a recipe for disaster down the road.
I'm not comfortable doing that at all. Thankfully the deb installs everything in /opt. So this symlink nastyness stays in /opt. If I had to do it in the standard directories, I would give up on trying out brackets.
Cheers,
-
Ed Greshko -
Ralf Corsepius -
Suvayu Ali -
T.C. Hollingsworth