search

Obsidian-StudiosInc / ecrire

General purpose graphical Text Editor built on the Enlightenment Foundation Libraries (EFL)
GNU General Public License v3.0
7 stars 1 forks source link

[efl + meson < 0.52.0] /usr/lib/libefreet_mime.so.1: error adding symbols: DSO missing from command line #47

Closed jlslinux closed 4 years ago

jlslinux commented 5 years ago
Description

Description of issue ninja package error:

/usr/bin/ld: src/bin/CMakeFiles/ecrire.dir/main.c.o: undefined reference to symbol 'efreet_mime_type_get' //usr/local/lib/x86_64-linux-gnu/libefreet_mime.so.1: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed.

Steps to reproduce

1. 2. 3. ...

System information
wltjr commented 5 years ago

@jlslinux thanks for the report. This was brought to my attention by @ApostolosB in https://github.com/Obsidian-StudiosInc/ecrire/issues/45#issuecomment-500489427, which I assumed had something to do with EFL being built with meson. That may or may not be the case. I am able to build it myself using ninja generator with EFL built using autotools, I haven't done it via meson, yet. You can see the local_utils.sh script I use is set to use ninja.

Because I can build it against EFL built with autotools using Ninja generator for cmake. I assume it is some bug in EFL built with meson. Maybe it is changing the order of stuff in a cmake file, causing things to be out of order for the linker. Likely need to compare or diff a cmake file generated from EFL meson build against one from EFL autotools to see any differences.

Otherwise, not sure how I can fix within ecrire codebase.

wltjr commented 5 years ago

Finally, I am able to confirm this issue. I do not have a resolution yet. I am still looking into what is causing the issue. The efreet-mime.pc files look similar enough. However, I do not see -lefreet_mime on the line that is failing. I see only -lefreet. That is where the problem lies. It should be included, as it is in the CMakeLists.txt

/usr/bin/x86_64-pc-linux-gnu-gcc -O2 -pipe -march=amdfam10 -mcx16 -msahf -mabm -mlzcnt -Wl,-O1 -rdynamic src/bin/CMakeFiles/ecrire.dir/main.c.o src/bin/CMakeFiles/ecrire.dir/cfg.c.o src/bin/CMakeFiles/ecrire.dir/ui/file_related.c.o src/bin/CMakeFiles/ecrire.dir/ui/search_dialog.c.o src/bin/CMakeFiles/ecrire.dir/ui/settings_dialog.c.o src/bin/CMakeFiles/ecrire.dir/ui/alerts.c.o -o src/bin/ecrire -leo -leina -lelementary -lefl -lm -lecore -lecore_input -lefreet -levas -leet

wltjr commented 4 years ago

@jlslinux @NuLogicSystems I found the problem! It is an upstream issue. The efreet-mime.pc file is messed up when created via Meson.

Autotools

Libs: -L${libdir} -lefreet_mime

Found efreet_mime: /usr/lib64/libefreet_mime.so

Meson

Libs: -lm -L${libdir} -lefreet_mime

Found efreet_mime: /usr/lib64/libm.so

All that ends up is -lm, as seen in two places configure and compile. The line that fails only has -lm and not -lefreet_mime as a result.

You can work around this for now by editing /usr/lib64/pkgconfig/efreet-mime.pc, remove the -lm and ecrire will compile.

NuLogicSystems commented 4 years ago

OK, but that doesn't explain why it doesn't build using cmake + gnu make. That is what my original issue was, not meson/ninja.

When I use: cmake -DCMAKE_INSTALL_PREFIX=/usr make

I also get -- Found efreet_mime: /usr/lib/libm.so , so maybe it's a cmake issue, and not meson.

https://sourceforge.net/p/nulogicos/PKGBUILD/ci/master/tree/ecrire-git/PKGBUILD

wltjr commented 4 years ago

@NuLogicSystems it is an upstream EFL issue. Since they switched to meson, the generation of the efreet-mime.pc file is messed up. It does not matter what build system is used downstream, cmake + make, cmake + ninja, or any other build system. They all use the same pc file for pkg-config. I could be using autotools or possibly even meson. It would still break, as the pc file has some issues for some reason. I am not sure -lm should even be in there, it was never in past versions.

It needs to be corrected in EFL itself. Edit your efreet-mime.pc file and see, it will build after using anything.

NuLogicSystems commented 4 years ago

OK, thanks for the explanation. I really hate having to edit pkgconfig files manually just to build some packages, this really should be reported upstream so it can be fixed there.

NuLogicSystems commented 4 years ago

Well, I got it built, but it crashes on trying to open it's settings. Segmentation fault (core dumped)

wltjr commented 4 years ago

I agree, editing pc files it is not ideal. I reported it on IRC. My phab account is still disabled, I rather not bother with creating another.

The crash is likely unrelated, but another issue to fix with changes in EFL. I will see about replicating that. Feel free to open another issue on the crash. If there are issues I can fix, I will!

wltjr commented 4 years ago

@NuLogicSystems, I just tried it locally and no crash. May try to delete your settings file, ~/.config/ecrire.cfg. If it continues, please file a bug so I can see about replicating or fixing. Thanks!

NuLogicSystems commented 4 years ago

OK, deleted ~/.config/ecrire.cfg still core dump. I'm using efl 1.23.0, maybe it's something there. It could also be that i'm running it on KDE. I'll make a new issue for this in the morning.

wltjr commented 4 years ago

@NuLogicSystems I am also on 1.23.0, so, not sure what is going on. Please do file a new issue when you get a chance. Thank you!

vtorri commented 4 years ago

https://phab.enlightenment.org/T8334

wltjr commented 4 years ago

@vtorri, thank you very much!

vtorri commented 4 years ago

don't use cmake, use meson :p

wltjr commented 4 years ago

@vtorri, ecrire was using cmake, which is why I continued that. I may switch to meson, but that requires a fair amount of work.

It looks like the problem is not the pc files, but possibly efl cmake config files. Using -D CMAKE_FIND_DEBUG_MODE=ON

Checking file [/usr/lib64/cmake/Edje/EdjeConfig.cmake]
-- Found edje: /usr/lib64/libm.so
Checking file [/usr/lib64/cmake/Efreet/EfreetConfig.cmake]
-- Found efreet_mime: /usr/lib64/libm.so

May need to update upstream bug from pc file issues to cmake file issues. I believe the libraries are found and passed along via those Config.cmake files.

At the same time, looking at EFL 1.22, a few files have -lm now that did not before. Not sure if -lm is really required. Either way, it has revealed another underlying issue.

vtorri commented 4 years ago

i understand. for Etui i switch to meson because it's faster than autotools (and cmake) and i prefer the syntax quite a lot

wltjr commented 4 years ago

I am impartial, pros and cons to each. However, if I was using Meson, this problem may go undiscovered for some period of time. Unless, EFL will stop supporting cmake build system for downstream. I cannot tell exactly where the problem lies, but seems its in the Config.cmake files. Those do not seem to be handling the change to multiple libraries in pc files.

It could be a larger cmake issue, but I would think many projects have multiple libs in pc files, and would be very strange to just come across this now. Seems EFL specific. I am looking into what I can change on ecrire's end.

wltjr commented 4 years ago

Looks like the problem is coming from EfreetConfig.cmake. I modified the file to test,

-NAMES ${PC_LIBEFREET_${_COMPONENT}_LIBRARIES}
+NAMES efreet_mime ${PC_LIBEFREET_${_COMPONENT}_LIBRARIES}

It finds the right library now,

Checking file [/usr/lib64/cmake/Efreet/EfreetConfig.cmake]
-- Found efreet_mime: /usr/lib64/libefreet_mime.so

Ecrire compiles as a result.

It seems like the problem lies within the EfreetConfig.cmake file, due to the change of the pc files having -lm now.

wltjr commented 4 years ago

I also tried,

-NAMES ${PC_LIBEFREET_${_COMPONENT}_LIBRARIES}
+NAMES efreet_${_component} ${PC_LIBEFREET_${_COMPONENT}_LIBRARIES}

That is likely a more proper solution, as any _component passed will work rather than a hard coded one as in my test. That also finds the correct library allows ecrire to compile.

vtorri commented 4 years ago

for Windows, technically speaking the generation of pc files with meson is wrong : the order of libraries is very important on Windows. Hopefully, -lm is ignored on Windows

wltjr commented 4 years ago

@vtorri check the version of meson. I believe, the pc files are fully generated by meson. I think > 52.x has the order corrected. Another with that version on IRC had a different order. I am on 51.2.

The order really should only be an issue for cmake builds not other build systems. They may or may not be affected at all by the order.

vtorri commented 4 years ago

automatically generating pc files with meson is an error imho, there are variables which were in pc.in files which are not anymore

i would have preferred keeping .pc.in and using substitution, like gstreamer does, and like i do for Etui.

wltjr commented 4 years ago

I can understand the automation but also the lack of customization--always trade-offs. How many pc files are missing variables that used to have them? If that number is small, then it does make more sense for the automation. Given, EFL has some 42 pc files, it makes sense to automate rather than creating and maintaining 42 .pc.in files. It seems a few can have a little different format or additions, like is done for ethumb_client.. Or maybe, other variables can be added to the automation across all pc files. Either way, I have little to no influence, my opinion is about as worthwhile as a single square of toilet paper. :)

Nonetheless, it seems the change in pc files has revealed a deficiency in the Config.cmake files.

vtorri commented 4 years ago

we have too much pc files. some of them should be dropped some of them are for c++, we can ignore them embryo.pc is used only internally, the pc file is useless first efreet should be rewritten, and one pc file should be enough ethumb should die, some should (or will not) be installed (ecore_evas for example or ecore_input) and when we will drop the legacy code, a lot of pc files will be removed

this will decrease a lot the number of pc files, i think

wltjr commented 4 years ago

Looks like building EFL using meson >= 0.52.0 resolves this issue.

Although, it still has revealed an underlying problem with EFL cmake file for efreet as mentioned in https://github.com/Obsidian-StudiosInc/ecrire/issues/47#issuecomment-543438184

wltjr commented 4 years ago

I am planning on closing this issue. It seems to be resolved with newer meson. Unless someone is still experiencing this with EFL built under >= meson 0.52.0.

vtorri commented 4 years ago

so i will close https://phab.enlightenment.org/T8334

wltjr commented 4 years ago

@vtorri yes, although, it was a pc file generation issue. It was a meson issue not efl. However, efl could modify its cmake files for efreet to ensure this issue does not come up again. But, given it is likely a one off issue, that may or may not be necessary.

vtorri commented 4 years ago

btw, if you can try etui : https://github.com/vtorri/etui , branch yoz-wip, that would be nice

wltjr commented 4 years ago

@vtorri sure thing, I can follow up via IRC. I updated my gentoo ebuild the other day for etui. Some tags/release for etui would be nice, if you get a chance, thanks!

wltjr commented 4 years ago

Close per https://github.com/Obsidian-StudiosInc/ecrire/issues/47#issuecomment-549565951