zlib dependency missing on ubuntu masterbranch build

Bug #1779539 reported by knoedelgespenst
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Low
RJ Skerry-Ryan

Bug Description

I tried to compile mixxx on ubuntu 16.04 but it fails due to a missing dependency on zlib in depends.py:

scons: Building targets ...
[LD] lin64_build/mixxx
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libQt5Network.so: undefined reference to symbol 'inflate'
scons: building terminated because of errors.
//lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
scons: *** [lin64_build/mixxx] Error 1

My build command is: scons stdlib=libc++ hss1394=0 mad=0 faad=0 ffmpeg=1 shoutcast=0 opus=0 vamp=0 coreaudio=0 hid=0 verbose=0 qt5=1 -j4

After adding a zlib dependendy via

class zLib(Dependence):
    def configure(self, build, conf):
        libs = ['z']
        if not conf.CheckLib(libs):
            raise Exception(
                "zlib not found")

and adding it to the "depends" of MixxxCore, its compiling.
Anyone else got that issue?

Tags: build
Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hm, interesting. Ubuntu 16.04 uses libstdc++ by default with gcc -- are you using clang? If so, what version?

Changed in mixxx:
status: New → Incomplete
assignee: nobody → RJ Skerry-Ryan (rryan)
importance: Undecided → Low
tags: added: build
Revision history for this message
knoedelgespenst (knoedelgespenst) wrote :

I am using g++ as toolchain.

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Ah, nevermind. The "stdlib" option is ignored (it used to control macOS only).

* Is this vanilla Ubuntu 16.04 or Kubuntu/Xubuntu/Mint/etc.?

Building with:
scons stdlib=libc++ hss1394=0 mad=0 faad=0 ffmpeg=1 shoutcast=0 opus=0 vamp=0 coreaudio=0 hid=0 verbose=0 qt5=1 -j4
on Ubuntu 16.04.3 works for me.

What's confusing is, libQt5Network.so should be dynamically linked to libz.so, and so missing zlib symbols doesn't make much sense. Can you post the output from your system for each bullet below:

* Can you post the full build log from scons and your config.log file?
* What version of libQt5Network and libz do you have? Here's what I have:
$ dpkg --list zlib1g
ii zlib1g:amd64 1:1.2.8.dfsg-2ubuntu4.1
$ dpkg --list libqt5network
ii libqt5network5:amd64 5.5.1+dfsg-16ubuntu7.5
* Please past the output of this command:
$ ldd /usr/lib/x86_64-linux-gnu/libQt5Network.so
        linux-vdso.so.1 => (0x00007ffdb3ffc000)
        libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f6368810000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f63685f3000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f63683d9000)
        libproxy.so.1 => /usr/lib/x86_64-linux-gnu/libproxy.so.1 (0x00007f63681b8000)
        libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6367e36000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6367a6c000)
        libicui18n.so.55 => /usr/lib/x86_64-linux-gnu/libicui18n.so.55 (0x00007f636760a000)
        libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f6367276000)
        libpcre16.so.3 => /usr/lib/x86_64-linux-gnu/libpcre16.so.3 (0x00007f6367010000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6366e0c000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f6366afb000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f63668f3000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f63665ea000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f63663d4000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6368ce6000)
        libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f636491d000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f63646ad000)

And if you could, please post:
$ objdump -T /lib/x86_64-linux-gnu/libz.so.1 | grep inflate
$ objdump -T /usr/lib/x86_64-linux-gnu/libQt5Network.so | grep inflate

Revision history for this message
knoedelgespenst (knoedelgespenst) wrote :
Download full text (59.9 KiB)

* Can you post the full build log from scons and your config.log file?
19:16:52 **** Incremental Build of configuration Default for project mixxxLibRedisgnMaster ****
scons stdlib=libc++ hss1394=0 vamp=1 mad=0 faad=0 ffmpeg=1 shoutcast=0 opus=0 coreaudio=0 hid=0 verbose=0 qt5=1 -j4
scons: Reading SConscript files ...
INFO:root:Target Platform: linux
INFO:root:Target Machine: x86_64
INFO:root:Build: debug
INFO:root:Toolchain: gnu
INFO:root:Crosscompile: NO
INFO:root:Qt path: /usr/lib/x86_64-linux-gnu/qt5
Checking whether the C++ compiler works... (cached) yes
Configuring MixxxCore
Checking for pkg-config (at least version 0.15.0)... (cached) yes
Checking for C library X11... (cached) yes
Configuring SoundTouch
Checking for soundtouch (2.0.0 or higher)... (cached) no
Configuring ReplayGain
Configuring Ebur128Mit
Checking for C library ebur128... (cached) no
Checking for C library libebur128... (cached) no
Checking for C header file sys/queue.h... (cached) yes
Configuring PortAudio
Checking for C library portaudio... (cached) yes
Configuring PortMIDI
Checking for C library porttime... (cached) yes
Checking for C library portmidi... (cached) yes
Checking for C header file portmidi.h... (cached) yes
Configuring Qt
Checking for Qt5Core (5.0 or higher)... (cached) yes
Configuring TestHeaders
Configuring FidLib
Configuring SndFile
Checking for C library sndfile... (cached) yes
Checking whether SFC_SET_COMPRESSION_LEVEL is declared... (cached) no
Configuring FLAC
Checking for C header file FLAC/stream_decoder.h... (cached) yes
Checking for C library libFLAC... (cached) yes
Configuring OggVorbis
Checking for C library libvorbisfile... (cached) yes
Checking for C library libvorbis... (cached) yes
Checking for C library libogg... (cached) yes
Checking for C library libvorbisenc... (cached) yes
Configuring OpenGL
Checking for C library GL... (cached) yes
Checking for C library GLU... (cached) yes
Configuring TagLib
Checking for C library tag... (cached) yes
Configuring ProtoBuf
Checking for C library libprotobuf-lite... (cached) yes
Configuring Chromaprint
Checking for C library chromaprint... (cached) yes
Configuring RubberBand
Checking for C library rubberband... (cached) yes
Configuring SecurityFramework
Configuring CoreServices
Configuring IOKit
Configuring QtScriptByteArray
Configuring Reverb
Configuring FpClassify
Configuring PortAudioRingBuffer
Configuring Mad
Configuring CoreAudio
Configuring MediaFoundation
Configuring HSS1394
Configuring HID
Configuring Bulk
Checking for C library libusb-1.0... (cached) yes
Checking for C header file libusb-1.0/libusb.h... (cached) yes
Configuring MacAppStoreException
Configuring VinylControl
Configuring LiveBroadcasting
Configuring Opus
Configuring Profiling
Configuring BuildTime
Configuring QDebug
Configuring Verbose
Configuring Optimize
Configuring FAAD
Configuring WavPack
Configuring ModPlug
Configuring TestSuite
Configuring Vamp
Checking for C library vamp-hostsdk... (cached) yes
Checking for vamp-plugin-sdk (2.7.1 or higher)... (cached) no
Checking for C library dl... (cached) yes
Checking for C header file fftw3.h... (cached) yes
Checking for C library fftw3... (cached) yes
Configuring ColorDiagnostic...

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Thanks! Everything looks fine, so I'm still confused.

I noticed you're on the "jmigual-library-redesign" branch (which also builds for me on Ubuntu 16.04.3), not master. What git commit hash are you building from?

Revision history for this message
knoedelgespenst (knoedelgespenst) wrote :

I am quite new to contributing to FOSS. So i dont know which commit hash your meaning, but this is my contribution, on which i am working on: https://github.com/mixxxdj/mixxx/pull/1764/commits

I am also confused ...

Revision history for this message
knoedelgespenst (knoedelgespenst) wrote :

But i tried to build the master before, where i got that issue. Switching over to the branch, and i had the same problem.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Today I suffer the same issue using the master branch on Ubuntu Trusty. Even after deleting the .sconsign.dblite.

Changed in mixxx:
status: Incomplete → Confirmed
Revision history for this message
Daniel Schürmann (daschuer) wrote :

the faulty commit is https://github.com/mixxxdj/mixxx/commit/5ba6519a7d2ec70228a3958cf1c626b65d2c66c4

With it we have the not working:
g++ -o lin64_build/mixxx -Wl,-rpath,/usr/lib/x86_64-linux-gnu -pthread -Wl,-rpath=/usr/lib/x86_64-linux-gnu

Without it we have the working:
g++ -o lin64_build/mixxx -L/usr/lib/x86_64-linux-gnu -pthread -Wl,-rpath=/usr/lib/x86_64-linux-gnu

Revision history for this message
Daniel Schürmann (daschuer) wrote :

https://stackoverflow.com/questions/8482152/whats-the-difference-between-rpath-and-l

Works as well by the way:
g++ -o lin64_build/mixxx -L/usr/lib/x86_64-linux-gnu -pthread

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Hm, sorry for the breakage... this bug was filed before that commit, so I don't think it caused knoedelgespenst's problem.

I would have assumed /usr/lib/x86_64-linux-gnu was already on the library search path.

Can you paste the output of gcc --print-search-dirs?

For an 18.04 desktop machine, it's:
$ gcc -print-search-dirs
install: /usr/lib/gcc/x86_64-linux-gnu/7/
programs: =/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/
libraries: =/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/7/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/7/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/

/usr/lib/x86_64-linux-gnu/ appears to already be on the search path, so adding it via -L should be redundant. Is it missing for you on Trusty?

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

We need to set a custom rpath on macOS if we want self-compiled Qt installations to work, but I'm not sure why we need it on Linux.

I tracked down the original commit which added the rpath for Linux here:
https://github.com/mixxxdj/mixxx/commit/3db884b72c7731cde31c4658059a2dc2a68e41fa

And the commit that removed it:
https://github.com/mixxxdj/mixxx/commit/55482fd99566f4a41099115d9c4984a1952c0000

Which I re-added, since the comments about rpath were still intact and macOS does indeed need this:
https://github.com/mixxxdj/mixxx/commit/5ba6519a7d2ec70228a3958cf1c626b65d2c66c4

Sounds like we should make it specific to macOS. But I'm still not sure I understand the zlib issue you are seeing Daniel.

Revision history for this message
Daniel Schürmann (daschuer) wrote :

> gcc --print-search-dirs
install: /usr/lib/gcc/x86_64-linux-gnu/4.8/
programs: =/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/bin/
libraries: =/usr/lib/gcc/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/4.8/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/:/lib/x86_64-linux-gnu/4.8/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/4.8/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../x86_64-linux-gnu/lib/:/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../:/lib/:/usr/lib/

Yes, /usr/lib/x86_64-linux-gnu/ is there. Maybe it is a kind of bug with zlib? If I search the web,I found other people complaining about zlib link issues.
https://stackoverflow.com/questions/19901934/strange-linking-error-dso-missing-from-command-line/20206371#20206371

Revision history for this message
Daniel Schürmann (daschuer) wrote :

Here is a proposal for a band-aid https://github.com/mixxxdj/mixxx/pull/1832

Changed in mixxx:
status: Confirmed → Fix Committed
milestone: none → 2.3.0
Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9362

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.