Building efl on x86 error: symbol lookup error: /eolian_gen: undefined symbol: eolian_state_new
Open, Incoming QueuePublic
Actions

Description

Compiling efl for Debian 10 buster, on x86 arch, I found next error

user@ninen:~/efl$ ninja -C build
ninja: Entering directory `build'
[149/3779] Generating eolian_gen_efl_ui_text_selectable.eo with a custom command.
FAILED: src/lib/efl/interfaces/efl_ui_text_selectable.eo.h 
/home/user/efl/build/src/bin/eolian/eolian_gen -S -I /home/user/efl/src/lib/efl/interfaces -I /home/user/efl/src/lib/eo -I /home/user/efl/src/lib -o h:/home/user/efl/build/src/lib/efl/interfaces/efl_ui_text_selectable.eo.h -o c:/home/user/efl/build/src/lib/efl/interfaces/efl_ui_text_selectable.eo.c -o d:/home/user/efl/build/src/lib/efl/interfaces/efl_ui_text_selectable.eo.d -gchd ../src/lib/efl/interfaces/efl_ui_text_selectable.eo
/home/user/efl/build/src/bin/eolian/eolian_gen: symbol lookup error: /home/user/efl/build/src/bin/eolian/eolian_gen: undefined symbol: eolian_state_new
[154/3779] Compiling C object 'src/static_libs/lz4/2310fe2@@lz4@sta/lz4hc.c.o'.
ninja: build stopped: subcommand failed.

I see this error running on efl-1.23.2 and running on master of efl repository

I followed steps from here https://www.enlightenment.org/download to setup my Build Environment

The steps to compile I did

meson . build
ninja -C build

Thanks

necrifede created this task.Nov 9 2019, 2:58 AM

necrifede added a project: efl (efl-1.24).

necrifede updated the task description. (Show Details)Nov 9 2019, 3:05 AM

can you please try a ninja clean before building?

what version are you on? If you are on git, please update after clean first and then try again.

adding @raster because of the lz4 build failure there.

Hello,

it worked now :S, I am suspicious about the environment variables were causing the issue PKG_CONFIG_PATH, LD_LIBRARY_PATH and CFLAGS,

I was able to compile efl and python-ELF, However I am having a different issue compiling enlightenment-0.23.1

user@ninen:~/enlightenment-0.23.1$ ninja -C build
ninja: Entering directory `build'
[176/591] Linking target src/bin/enlightenment_imc.
FAILED: src/bin/enlightenment_imc 
cc  -o src/bin/enlightenment_imc 'src/bin/3a6e061@@enlightenment_imc@exe/e_config_data.c.o' 'src/bin/3a6e061@@enlightenment_imc@exe/e_imc_main.c.o' 'src/bin/3a6e061@@enlightenment_imc@exe/e_intl_data.c.o' -Wl,--no-undefined -Wl,--as-needed -Wl,-O1 -pthread -Wl,--start-group /usr/local/lib/x86_64-linux-gnu/libeina.so /usr/local/lib/x86_64-linux-gnu/libeet.so /usr/local/lib/x86_64-linux-gnu/libemile.so /usr/local/lib/x86_64-linux-gnu/libefl.so /usr/local/lib/x86_64-linux-gnu/libeo.so /usr/local/lib/x86_64-linux-gnu/libecore_file.so -Wl,--end-group  
/usr/bin/ld: //usr/local/lib/libeldbus.so.1: undefined reference to `efl_model_property_changed_notify'
/usr/bin/ld: //usr/local/lib/libecore.so.1: undefined reference to `efl_model_list_slice'
/usr/bin/ld: /usr/local/lib/x86_64-linux-gnu/libecore_file.so: undefined reference to `efl_main_loop_get'
/usr/bin/ld: //usr/local/lib/libecore_con.so.1: undefined reference to `efl_ref_get'
/usr/bin/ld: //usr/local/lib/libecore.so.1: undefined reference to `EINA_ERROR_FUTURE_CANCEL'
collect2: error: ld returned 1 exit status
[181/591] Compiling C object 'src/bin/3a6e061@@enlightenment@exe/e_comp_x.c.o'.
ninja: build stopped: subcommand failed.

Should I close this ticket and create a new one?

-Thanks

you have a classic "2 installs in 2 places" problem.

/usr/local/lib/ and /usr/local/lib/x86_64-linux-gnu/.

remove the one you don't need anymore.... or better remove both then do a clean rebuild and install of efl. :)

I have installed one of them 1.20.7 to have terminology working months ago, the second installation is the one compiled 1.23.2.

I am not able to uninstall the 1.20.7 version using apt nor dpkg - I am in debian 10 (buster upgraded from 9 stretch) -

Do you know a way to uninstall this efl version?

In the worst case I would do it manually :(

user@ninen:/usr/local/lib$ ls -l
total 55068
drwxr-sr-x 26 root staff     4096 Apr 13  2018 cmake
drwxr-sr-x  3 root staff     4096 Apr 13  2018 ecore
drwxr-sr-x  3 root staff     4096 Apr 13  2018 ecore_con
drwxr-sr-x  3 root staff     4096 Apr 13  2018 ecore_evas
drwxr-sr-x  3 root staff     4096 Apr 13  2018 ecore_imf
drwxr-sr-x  4 root staff     4096 Apr 13  2018 edje
drwxr-sr-x  3 root staff     4096 Apr 13  2018 eeze
drwxr-sr-x  3 root staff     4096 Apr 13  2018 efreet
drwxr-sr-x  3 root staff     4096 Apr 13  2018 elementary
drwxr-sr-x  3 root staff     4096 Apr 13  2018 emotion
drwxr-sr-x  3 root staff     4096 Apr 13  2018 ethumb
drwxr-sr-x  3 root staff     4096 Apr 13  2018 ethumb_client
drwxr-sr-x  5 root staff     4096 Apr 13  2018 evas
drwxr-xr-x  5 root root      4096 Oct 18  2018 heroku
-rw-r--r--  1 root staff     1200 Apr 13  2018 libecore_audio.la
lrwxrwxrwx  1 root staff       24 Apr 13  2018 libecore_audio.so -> libecore_audio.so.1.20.7
lrwxrwxrwx  1 root staff       24 Apr 13  2018 libecore_audio.so.1 -> libecore_audio.so.1.20.7
-rwxr-xr-x  1 root staff   336056 Apr 13  2018 libecore_audio.so.1.20.7
-rw-r--r--  1 root staff     1122 Apr 13  2018 libecore_avahi.la
lrwxrwxrwx  1 root staff       24 Apr 13  2018 libecore_avahi.so -> libecore_avahi.so.1.20.7
lrwxrwxrwx  1 root staff       24 Apr 13  2018 libecore_avahi.so.1 -> libecore_avahi.so.1.20.7
-rwxr-xr-x  1 root staff    21840 Apr 13  2018 libecore_avahi.so.1.20.7
-rw-r--r--  1 root staff     1225 Apr 13  2018 libecore_con.la
lrwxrwxrwx  1 root staff       22 Apr 13  2018 libecore_con.so -> libecore_con.so.1.20.7
lrwxrwxrwx  1 root staff       22 Apr 13  2018 libecore_con.so.1 -> libecore_con.so.1.20.7
-rwxr-xr-x  1 root staff  2615664 Apr 13  2018 libecore_con.so.1.20.7
-rw-r--r--  1 root staff     1585 Apr 13  2018 libecore_evas.la
lrwxrwxrwx  1 root staff       23 Apr 13  2018 libecore_evas.so -> libecore_evas.so.1.20.7
lrwxrwxrwx  1 root staff       23 Apr 13  2018 libecore_evas.so.1 -> libecore_evas.so.1.20.7
-rwxr-xr-x  1 root staff   732808 Apr 13  2018 libecore_evas.so.1.20.7
-rw-r--r--  1 root staff     1262 Apr 13  2018 libecore_file.la
lrwxrwxrwx  1 root staff       23 Apr 13  2018 libecore_file.so -> libecore_file.so.1.20.7

*** many more ***

-rw-r--r--  1 root staff     1864 Apr 13  2018 libethumb.la
lrwxrwxrwx  1 root staff       19 Apr 13  2018 libethumb.so -> libethumb.so.1.20.7
lrwxrwxrwx  1 root staff       19 Apr 13  2018 libethumb.so.1 -> libethumb.so.1.20.7
-rwxr-xr-x  1 root staff   153944 Apr 13  2018 libethumb.so.1.20.7
-rw-r--r--  1 root staff     1307 Apr 13  2018 libevas.la
lrwxrwxrwx  1 root staff       17 Apr 13  2018 libevas.so -> libevas.so.1.20.7
lrwxrwxrwx  1 root staff       17 Apr 13  2018 libevas.so.1 -> libevas.so.1.20.7
-rwxr-xr-x  1 root staff 14045720 Apr 13  2018 libevas.so.1.20.7
drwxrwsr-x  3 root staff     4096 Nov 10 08:46 ocaml
drwxr-sr-x  2 root staff     4096 Apr 13  2018 pkgconfig
drwxrwsr-x  4 root staff     4096 Nov  9 07:46 python2.7
drwxrwsr-x  3 root staff     4096 Jun 21  2017 python3.5
drwxrwsr-x  3 root staff     4096 Nov  9 08:12 python3.7
drwxrwsr-x  3 root staff     4096 Nov  5  2018 R
drwxr-sr-x 16 root staff     4096 Nov 16 15:50 x86_64-linux-gnu

if you had the old built tree around a "make uninstall" would do it. but i guess you don't... so yes - you'll have to manually uninstall it. delete all the ecore, edje, evas, etc. etc. dirs and libecore* etc. etc. libs that come from the efl install.

I am not sure why people are seeing this (you are not the first one), there is not a single call within the efl-build that is loading old e* libraries from the system to compile based on that. And the -I / -L flags are added as first by meson, only the user CFLAGS go higher in the priority, have you set custom CFLAGS that are including the libraries from these directories? (Or is your compiler not honoring the ordering of flags like (for example) mine) ?

I did not set the CFLAGS, should I set them?

When I setup them I got next error:

user@ninen:~/enlightenment-0.23.1$ rm -rf build
user@ninen:~/enlightenment-0.23.1$ export CFLAGS="-l /usr/local/lib"
user@ninen:~/enlightenment-0.23.1$ meson . build
The Meson build system
Version: 0.49.2
Source dir: /home/user/enlightenment-0.23.1
Build dir: /home/user/enlightenment-0.23.1/build
Build type: native build
Project name: enlightenment
Project version: 0.23.1
Appending CFLAGS from environment: '-l /usr/local/lib'
Native C compiler: cc (gcc 8.3.0 "cc (Debian 8.3.0-6) 8.3.0")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Compiler for C supports arguments -Wall: YES
Compiler for C supports arguments -W: YES
Compiler for C supports arguments -Wpointer-arith: YES
Compiler for C supports arguments -Wshadow: YES
Compiler for C supports arguments -Wno-missing-field-initializers -Wmissing-field-initializers: YES
Compiler for C supports arguments -Wfloat-equal: YES
Compiler for C supports arguments -Wuninitialized: YES
Compiler for C supports arguments -Wundef: YES
Compiler for C supports arguments -Wcast-align: YES
Compiler for C supports arguments -Wformat=2: YES
Compiler for C supports arguments -Wno-format-y2k -Wformat-y2k: YES
Library intl found: NO
Header <features.h> has symbol "__UCLIBC__" : NO
Header <features.h> has symbol "__dietlibc__" : NO
Checking for function "setenv" : NO
Checking for function "unsetenv" : NO
Checking for function "clearenv" : NO
Has header "features.h" : YES
Has header "sys/ptrace.h" : YES
Has header "arpa/inet.h" : YES
Has header "netinet/in.h" : YES
Has header "execinfo.h" : YES
Has header "fnmatch.h" : YES
Checking for function "fnmatch" : NO
Found pkg-config: /usr/bin/pkg-config (0.29)
Found CMake: NO
Dependency fnmatch found: NO (tried pkgconfig)

meson.build:182:2: ERROR:  Dependency "fnmatch" not found, tried pkgconfig

A full log can be found at /home/user/enlightenment-0.23.1/build/meson-logs/meson-log.txt

No no, you should not, I just wondered if you did before ... (but you you didn't, which is correct).

This does happen - the RUNTIME linker (ld.so) will search and if it finds the libs in a system dir it seems to prefer those to the ones in the tree. this happened under autofoo and still happens with meson it seems. i know they SHOULD be using an rpath which SHOULD make the in-tree libs preferred ... but that seems broken when running eolian_gen and edje_cc as part of the build... :(

if you have multiple efl's in system libs then this problem happens too regardless of efl's build - runtime it depends on which dir happens to be looked in first (or which is cached in ld.so.cache etc.). it's a bad thing unless you're careful with lib paths and know what you are doing to ensure the right efl gets linked in each time...

Building efl on x86 error: symbol lookup error: /eolian_gen: undefined symbol: eolian_state_newOpen, Incoming QueuePublicActions

Description

Building efl on x86 error: symbol lookup error: /eolian_gen: undefined symbol: eolian_state_new
Open, Incoming QueuePublic
Actions