Ticket #3540 (new defect)

Opened 3 years ago

Last modified 3 years ago

Failing tests, Ubuntu 12.04, gcc 4.6.3

Reported by: zaytsev Owned by:
Priority: major Milestone: Future Releases
Component: mc-core Version: master
Keywords: Cc:
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description

Running suite(s): /lib/utilunix
FAIL: utilunix__my_system_fork_child_shell

Running suite(s): /lib/utilunix
FAIL: utilunix__my_system_fork_child

See any recent Travis report:

https://travis-ci.org/MidnightCommander/mc

Change History

comment:1 Changed 3 years ago by and

Maybe a characteristic of travis-ci.org framework?

What about "TRUSTY BETA" environment?
https://docs.travis-ci.com/user/ci-environment/

check-0.9.11 against 52fd328042a426e885da891c8ce8218cda3a1cf7

====================================
   /lib: tests/lib/test-suite.log
====================================

# TOTAL: 8
# PASS:  8
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

comment:2 Changed 3 years ago by zaytsev

Oh, so you've tried on Travis / Trusty and it works?! I will check, and if this is indeed the case, then we can simply switch to Trusty, and declare that this didn't happen :) / was a problem due to specific setup of Travis. Thanks!

comment:3 Changed 3 years ago by and

Tests result log was build on different machine (not travis-ci/Ubuntu environment).

You can try to cross test with "TRUSTY BETA"/Ubuntu 14.04, when successful it is maybe a "STANDARD"/Ubuntu 12.04 issue.

By the way I hit another tests failure which is addressed in #3542

comment:4 Changed 3 years ago by zaytsev

I have tried Trusty beta, and the problem indeed went away. However, I have got a new one:

make  library_independ mc_build_filename name_quote serialize utilunix__my_system_fork_fail utilunix__my_system_fork_child_shell utilunix__my_system_fork_child x_basename
make[4]: Entering directory `/home/travis/build/zyv/mc/build-default/tests/lib'
  CC       library_independ.o
  CCLD     library_independ
  CC       mc_build_filename.o
  CCLD     mc_build_filename
/usr/bin/ld: mc_build_filename.o: undefined reference to symbol 'g_assertion_message_cmpstr'
//lib/x86_64-linux-gnu/libglib-2.0.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status

https://travis-ci.org/zyv/mc/builds/86866877

Did you not run into this one? I wonder whether this could be related to the --as-needed thing? Any ideas on how to fix this one?

comment:5 Changed 3 years ago by and

It is possible to run make check in verbose mode (to see the exact CCLD command)

# make V=0 check
...
  CCLD     mc_build_filename
...

A non-ubuntu verbose example (with successful linking)

# make V=1 check
...
/bin/sh ../../libtool  --tag=CC   --mode=link gcc-4.9.3 -std=gnu99  -fdiagnostics-show-option -Wbad-function-cast -Wcomment -Wdeclaration-after-statement -Wfloat-equal -Wformat -Wformat-security -Wimplicit -Wignored-qualifiers -Wmaybe-uninitialized -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wno-long-long -Wno-unreachable-code -Wparentheses -Wpointer-arith -Wpointer-sign -Wredundant-decls -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wswitch-default -Wtype-limits -Wundef -Wuninitialized -Wunreachable-code -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wwrite-strings  -march=native -O2 -pipe -Wl,-z,muldefs -Wl,-O1 -o mc_build_filename mc_build_filename.o  -lcheck  ../../lib/libmc.la
libtool: link: gcc-4.9.3 -std=gnu99 -fdiagnostics-show-option -Wbad-function-cast -Wcomment -Wdeclaration-after-statement -Wfloat-equal -Wformat -Wformat-security -Wimplicit -Wignored-qualifiers -Wmaybe-uninitialized -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wno-long-long -Wno-unreachable-code -Wparentheses -Wpointer-arith -Wpointer-sign -Wredundant-decls -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wswitch-default -Wtype-limits -Wundef -Wuninitialized -Wunreachable-code -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wwrite-strings -march=native -O2 -pipe -Wl,-z -Wl,muldefs -Wl,-O1 -o .libs/mc_build_filename mc_build_filename.o  -lcheck ../../lib/.libs/libmc.so -lncursesw -lgpm -lext2fs -lcom_err -lssh2 -lgmodule-2.0 -lglib-2.0 -pthread
...

comment:6 Changed 3 years ago by zaytsev

Hmmm, the libraries doesn't seem to get passed on to tests at all:

/bin/bash ../../libtool  --tag=CC   --mode=link gcc -std=gnu99  -fdiagnostics-show-option -Wbad-function-cast -Wcomment -Wdeclaration-after-statement -Wfloat-equal -Wformat -Wformat-security -Wimplicit -Wignored-qualifiers -Wmaybe-uninitialized -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wno-long-long -Wno-unreachable-code -Wparentheses -Wpointer-arith -Wpointer-sign -Wredundant-decls -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wswitch-default -Wtype-limits -Wundef -Wuninitialized -Wunreachable-code -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wwrite-strings -Werror -g3 -O -ggdb -Wno-error=shadow -Wl,-z,muldefs  -o mc_build_filename mc_build_filename.o  -pthread -lcheck_pic -lrt -lm   ../../lib/libmc.la
libtool: link: gcc -std=gnu99 -fdiagnostics-show-option -Wbad-function-cast -Wcomment -Wdeclaration-after-statement -Wfloat-equal -Wformat -Wformat-security -Wimplicit -Wignored-qualifiers -Wmaybe-uninitialized -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wmissing-parameter-type -Wmissing-prototypes -Wnested-externs -Wno-long-long -Wno-unreachable-code -Wparentheses -Wpointer-arith -Wpointer-sign -Wredundant-decls -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wstrict-prototypes -Wswitch -Wswitch-default -Wtype-limits -Wundef -Wuninitialized -Wunreachable-code -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wwrite-strings -Werror -g3 -O -ggdb -Wno-error=shadow -Wl,-z -Wl,muldefs -o .libs/mc_build_filename mc_build_filename.o -pthread  -lcheck_pic -lrt -lm ../../lib/.libs/libmc.so -pthread -Wl,-rpath -Wl,/home/travis/build/zyv/mc/build-default/INSTALL_ROOT/lib

https://travis-ci.org/zyv/mc/builds/86968156

comment:7 Changed 3 years ago by zaytsev

lib/libmc.la:

# Libraries that this one depends upon.

dependency_libs=' -lslang -lgpm -lssh2 -lgcrypt -lgmodule-2.0 -lglib-2.0'

Why they are not added to the linker command is still a mystery to me...

comment:8 Changed 3 years ago by zaytsev

I believe that I now know what's going on here: Debian & Ubuntu helpfully ship a patched version of libtool, which adds dependency_libs only when linking libraries, because it's not necessary to add dependency_libs when linking (ELF) binaries, and thus superfluous according to their argument. The tests, however, not only use glib through libmc.so, but also directly, as in this failing example. Therefore, one needs to link them against glib as well.

I wonder what's a good fix for it then?

One possibility is to explicitly add libraries used to xxx_LDADD for each test. Sounds like a lot of potentially painstaking work? I haven't really looked into it yet.

Another possibility is to just add everything libmc.so is linked against to LIBS by copy & pasting relevant variables, and hope that this would suffice. This one will basically replicate the effect of adding dependency_libs, but... is that the right thing to do?

Any opinions?

comment:9 Changed 3 years ago by ossi

for starters, each object which needs symbols from a particular library needs to link that library explicitly, just as it should explicitly add the lib's include path. that means LDADD everywhere.

the exception where it is ok to rely on transitive dependencies is when the library exposes its dependencies in its own api, thus adding them to its so-called link interface. i actually have no clue whether libtool supports that explicitly. if not, but you want to pretend it does, hacking LIBS is reasonable.

Note: See TracTickets for help on using tickets.