Summary: | [enlightenment overlay] dev-libs/efl-1.8.0_beta2 - lib/edje/.libs/libedje.so: undefined reference to `ecore_imf_context_input_panel_layout_variation_set' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | MickKi <confabulate> |
Component: | [OLD] Library | Assignee: | enlightenment+disabled |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | asturm, dschridde+gentoobugs, kentnl |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
dev-libs\:efl-1.8.0_beta2 build log
build.log |
Description
MickKi
2013-12-07 15:20:18 UTC
Created attachment 364816 [details]
dev-libs\:efl-1.8.0_beta2 build log
Created attachment 365846 [details] build.log I confirm this for dev-libs/efl-1.8.2 after working around bug #494912 by setting USE=-wayland. Do you have the splitted efl 1.7 libs installed, when you get this error? Does efl compile fine, when you uninstall them previously? (In reply to Thomas Sachau from comment #3) > Do you have the splitted efl 1.7 libs installed, when you get this error? > > Does efl compile fine, when you uninstall them previously? In my case I have uninstalled all previous enlightenment 1.7 libs and packages. I can check again when I login in that box, but I am pretty sure that there are no older enlightenment packages left. If there is a particular regex stanza you would like me to run to make sure there's nothing left, please post back. -- Regards, Mick the efl ebuild has a list, copying it here: dev-libs/ecore dev-libs/edbus dev-libs/eet dev-libs/eeze dev-libs/efreet dev-libs/eina dev-libs/eio dev-libs/embryo dev-libs/eobj dev-libs/ephysics media-libs/edje media-libs/emotion media-libs/ethumb media-libs/evas So if any of them still is on the system, try to emerge the efl package again after you uninstalled the remaining 1.7 packages. > So if any of them still is on the system, try to emerge the efl package
> again after you uninstalled the remaining 1.7 packages.
My apologies:
I had e_dbus still installed as well as eina. I removed them and installed efl-1.8.3 without problem. I guess this bug can be closed, unless the problem persists for Dennis.
--
Regards,
Mick
(In reply to MickKi from comment #6) > I had e_dbus still installed as well as eina. dev-libs/efl-1.8.3 blocks dev-libs/edbus and not dev-libs/e_dbus (note the underscore). This seems to be a mistake, as there is no such package. (In reply to Thomas Sachau from comment #5) > the efl ebuild has a list, copying it here: After unmerging those (plus e_dbus), dev-libs/efl-1.8.3 compiles fine during a work upgrade (which included E18). (In reply to Dennis Schridde from comment #7) > After unmerging those (plus e_dbus), dev-libs/efl-1.8.3 compiles fine during > a work upgrade (which included E18). during a "world" upgrade Just a thought ... shouldn't the ebuild work with portage to remove any packages that cause this problem? At least it should flag up an enotice of sorts advising the user what packages they would need to remove manually and what they ought to install in their place to upgrade to enlightenment 18. -- Regards, Mick (In reply to Dennis Schridde from comment #7) > dev-libs/efl-1.8.3 blocks dev-libs/edbus and not dev-libs/e_dbus (note the > underscore). This seems to be a mistake, as there is no such package. This issue persists. (In reply to Dennis Schridde from comment #10) > (In reply to Dennis Schridde from comment #7) > > dev-libs/efl-1.8.3 blocks dev-libs/edbus and not dev-libs/e_dbus (note the > > underscore). This seems to be a mistake, as there is no such package. > > This issue persists. It is no bug, it is a feature. ;-) Upstream has a package called "edbus", which likely was and maybe still is in some overlays like niifaq. To avoid file collisions with this package, it is in the blocker list. On the other side, there is the package called "e_dbus", which is a different package and not included in efl-1.8, so there is no replacement and no file collision, so also no blocker against this package. To avoid those compile time issues, i have added hard blockers to efl-1.8.4 (which should be on your local rsync mirror in a few hours), so you have to uninstall those blocking 1.7 libs before you can install efl-1.8.4. *** Bug 499334 has been marked as a duplicate of this bug. *** (In reply to Thomas Sachau from comment #11) > To avoid those compile time issues, i have added hard blockers to efl-1.8.4 > (which should be on your local rsync mirror in a few hours), so you have to > uninstall those blocking 1.7 libs before you can install efl-1.8.4. __[ TLDR ]__ Remove enlightenment itself first or otherwise clean up the preserved-libs if this problem continues __[ Long Form ]___ Having removed all listed blockers, compilation still fails for efl-1.8.4 removing dev-libs/e_dbus-1.7.9 has no impact. I'm suspicious that the PRESERVED_LIBS being held by enlightenment still being installed are to blame. So I forcefully remove enlightenment. <<< !needed sym /usr/lib64/libecore.so.1 <<< !needed obj /usr/lib64/libecore.so.1.7.9 <<< !needed sym /usr/lib64/libecore_con.so.1 <<< !needed obj /usr/lib64/libecore_con.so.1.7.9 <<< !needed sym /usr/lib64/libecore_evas.so.1 <<< !needed obj /usr/lib64/libecore_evas.so.1.7.9 <<< !needed sym /usr/lib64/libecore_file.so.1 <<< !needed obj /usr/lib64/libecore_file.so.1.7.9 <<< !needed sym /usr/lib64/libecore_imf.so.1 <<< !needed obj /usr/lib64/libecore_imf.so.1.7.9 <<< !needed sym /usr/lib64/libecore_imf_evas.so.1 <<< !needed obj /usr/lib64/libecore_imf_evas.so.1.7.9 <<< !needed sym /usr/lib64/libecore_input.so.1 <<< !needed obj /usr/lib64/libecore_input.so.1.7.9 <<< !needed sym /usr/lib64/libecore_input_evas.so.1 <<< !needed obj /usr/lib64/libecore_input_evas.so.1.7.9 <<< !needed sym /usr/lib64/libecore_ipc.so.1 <<< !needed obj /usr/lib64/libecore_ipc.so.1.7.9 <<< !needed sym /usr/lib64/libecore_x.so.1 <<< !needed obj /usr/lib64/libecore_x.so.1.7.9 <<< !needed sym /usr/lib64/libedbus.so.1 <<< !needed obj /usr/lib64/libedbus.so.1.7.9 <<< !needed sym /usr/lib64/libedje.so.1 <<< !needed obj /usr/lib64/libedje.so.1.7.9 <<< !needed sym /usr/lib64/libeet.so.1 <<< !needed obj /usr/lib64/libeet.so.1.7.9 <<< !needed sym /usr/lib64/libeeze.so.1 <<< !needed obj /usr/lib64/libeeze.so.1.7.9 <<< !needed sym /usr/lib64/libefreet.so.1 <<< !needed obj /usr/lib64/libefreet.so.1.7.9 <<< !needed sym /usr/lib64/libefreet_mime.so.1 <<< !needed obj /usr/lib64/libefreet_mime.so.1.7.9 <<< !needed sym /usr/lib64/libefreet_trash.so.1 <<< !needed obj /usr/lib64/libefreet_trash.so.1.7.9 <<< !needed sym /usr/lib64/libeina.so.1 <<< !needed obj /usr/lib64/libeina.so.1.7.9 <<< !needed sym /usr/lib64/libeio.so.1 <<< !needed obj /usr/lib64/libeio.so.1.7.9 <<< !needed sym /usr/lib64/libembryo.so.1 <<< !needed obj /usr/lib64/libembryo.so.1.7.9 <<< !needed sym /usr/lib64/libenotify.so.1 <<< !needed obj /usr/lib64/libenotify.so.1.7.9 <<< !needed sym /usr/lib64/libeukit.so.1 <<< !needed obj /usr/lib64/libeukit.so.1.7.9 <<< !needed sym /usr/lib64/libevas.so.1 <<< !needed obj /usr/lib64/libevas.so.1.7.9 And surprise! elf 1.8.4 compiles again! So I don't think this should be really considered "fixed", as the apparent flaw is compilation being poisoned by system libraries that it shouldn't be. Well, like i wrote in the other duplication bugs, the problem is the @preserved-rebuild feature of portage. This preserves the 1.7 libs also you removed the packages containing them. So the libs are still around, efl-1.8 tries to use them and this results in a compile failure. The only workarounds are: -either remove the blocked packages with FEATURES=preserved-rebuild disabled -or "emerge -aC @preserved-rebuild" to remove the packages which cause the 1.7 libs to stay There is afaik no clean solution on the ebuild level to prevent this, the only possible thing i may to is some ewarn message telling users about the problem |