Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 704712 - media-gfx/lximage-qt requires libxcb with abi_x86_32, even with ABI_X86="64"
Summary: media-gfx/lximage-qt requires libxcb with abi_x86_32, even with ABI_X86="64"
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: LxQt maintainers
Depends on:
Reported: 2020-01-03 16:32 UTC by jan vereecke
Modified: 2020-09-10 13:15 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description jan vereecke 2020-01-03 16:32:10 UTC
during emerge of lximage-0.14.1-r1 on a system that is built with ABI_X86="64" (so no multilib), the lximage depends on being present in /usr/lib/.
However, on a pure 64 bit system, libxcb is only present in /usr/lib64, so the lximage ebuild fails with
ninja: error: '/usr/lib/', needed by 'src/lximage-qt', missing and no known rule to make it

Reproducible: Always

Steps to Reproduce:
1. set ABI_X86="64" in make.conf
2. remove all mention of abi_x86_32 in package.use (in particular of x11-libs/libxcb)
3. rebuild libxcb and verify that this places in /usr/lib64/ and not in /usr/lib
4. build lximage-0.14.1-r1.
Actual Results:  
* Working in BUILD_DIR: "/var/tmp/portage/portage/media-gfx/lximage-qt-0.14.1-r1/work/lximage-qt-0.14.1_build"
ninja -v -j1 -l1
ninja: error: '/usr/lib/', needed by 'src/lximage-qt', missing and no known rule to make it

Expected Results:  
ninja should look for libxcb in /usr/lib64 for the library file 

the makefile that is created during configuration 'work/lximage-qt-0.14.1_build/' contains a reference to /usr/lib/ (see the forum post for the location of this reference). In case of a pure 64-bit build, this reference should be adapted to /usr/lib64/libxcb

As a workaround, libxcb and its dependencies must be compiled with the abi_x86_32 use flag.
Comment 1 Chiitoo gentoo-dev 2020-01-04 16:48:59 UTC
Does the '/usr/lib/' persist after having built things with 32-bit support?

From a quick look, I do get '/usr/lib64/' here, even after having built 'x11-libs/libxcb' with 'ABI_X86="64"' (was only a quick test though, and I did not build all the dependencies with it).

Also, what are the contents of '/usr/lib64/pkgconfig/xcb.pc'?  (Not sure this will be interesting really, but I am a bit curious.)
Comment 2 jan vereecke 2020-01-06 21:24:50 UTC
As already mentioned: the problem is that lximage-qt requires /lib/libxcb.
with ABI_x86="64", that file does not exist.
As a workaround, I put in package.use 'x11-libs/libxcb abi_x86_32' (leaving ABI_x86 in make.conf unchanged and re-emerged libxcb
=> I now have libxcb both in /usr/lib and /usr/lib64.

If I understand your question correctly, now that there is a file /usr/lib/libxcb you wanted me to emerge again, but with the 'x11-libs/libxcb abi_x86_32' statement in package.use removed again.

As expected, the result of this is a file in /usr/lib64 and one in /usr/lib.

I suspect you may have misinterpreted the actual problem, which is a problem with the emerge of lximage-qt. 
with make.conf containing ABI_x86="64", an emerge shoudl look for all needed libraries in /usr/lib64.
However, the link command for lximage-qt contains
build src/lximage-qt: CXX_EXECUTABLE_LINKER__lximage-qt src/CMakeFiles/lximage-qt.dir/lximage-qt_autogen/mocs_compilation.cpp.o src/CMakeFiles/lximage-qt.dir/lximage-qt.cpp.o src/CMakeFiles/lximage-qt.dir/mainwindow.cpp.o src/CMakeFiles/lximage-qt.dir/preferencesdialog.cpp.o src/CMakeFiles/lximage-qt.dir/application.cpp.o src/CMakeFiles/lximage-qt.dir/imageview.cpp.o src/CMakeFiles/lximage-qt.dir/modelfilter.cpp.o src/CMakeFiles/lximage-qt.dir/loadimagejob.cpp.o src/CMakeFiles/lximage-qt.dir/saveimagejob.cpp.o src/CMakeFiles/lximage-qt.dir/screenshotdialog.cpp.o src/CMakeFiles/lximage-qt.dir/screenshotselectarea.cpp.o src/CMakeFiles/lximage-qt.dir/screenshotselectareagraphicsview.cpp.o src/CMakeFiles/lximage-qt.dir/settings.cpp.o src/CMakeFiles/lximage-qt.dir/graphicsscene.cpp.o src/CMakeFiles/lximage-qt.dir/mrumenu.cpp.o src/CMakeFiles/lximage-qt.dir/upload/imageshackprovider.cpp.o src/CMakeFiles/lximage-qt.dir/upload/imageshackupload.cpp.o src/CMakeFiles/lximage-qt.dir/upload/imgbbprovider.cpp.o src/CMakeFiles/lximage-qt.dir/upload/imgbbupload.cpp.o src/CMakeFiles/lximage-qt.dir/upload/imgurprovider.cpp.o src/CMakeFiles/lximage-qt.dir/upload/imgurupload.cpp.o src/CMakeFiles/lximage-qt.dir/upload/provider.cpp.o src/CMakeFiles/lximage-qt.dir/upload/upload.cpp.o src/CMakeFiles/lximage-qt.dir/upload/uploaddialog.cpp.o src/CMakeFiles/lximage-qt.dir/applicationadaptor.cpp.o src/CMakeFiles/lximage-qt.dir/lximage-qt_autogen/EWIEGA46WW/qrc_resource.cpp.o | /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib/ /usr/lib64/ /usr/lib64/ /usr/lib64/ /usr/lib64/ || src/lximage-qt_autogen

As you can see, all libraries in that link command refer to /usr/lib64, except the one refering to /usr/lib/libxcb.

So something in the ebuild should check for ABI_X86 and if it contains "64", the correct /usr/lib64/libcxb should be linked in.
Comment 3 jan vereecke 2020-01-06 21:25:26 UTC
cat /usr/lib64/pkgconfig/xcb.pc


Name: XCB
Description: X-protocol C Binding
Version: 1.13.1
Requires.private: pthread-stubs xau >= 0.99.2 xdmcp
Libs: -L${libdir} -lxcb
Cflags: -I${includedir}
Comment 4 Chiitoo gentoo-dev 2020-01-06 22:02:07 UTC

What I meant to ask, is if the '' file still contains the reference to '/usr/lib/'.

I don't know if it should work differently for me, even if I'm not running with a pure 64-bit system.  I'd kind of expect to see '/usr/lib/' as well.
Comment 5 Chiitoo gentoo-dev 2020-09-10 13:15:06 UTC
Closing since there hasn't been any updates for a time, and 'media-gfx/lximage-qt-0.14.1-r1' is gone.

Feel free to re-open if this is still being a thing.

Thanks for the report!