[SOLVED] Problems compiling 32-bit llvm-6.0.1 on Slackware-14.2 multilib

I just bought a very nice new radeon GPU, which unfortunately is not very well supported on Slackware-14.2. So, I endeavoured to compile mesa 18.2 using the slackbuilds from -current. For 64-bit, this went quite well, I upgraded libdrm, installed libedit, upgraded llvm and then compiled mesa. Only one small issue - I had to comment the line saying "rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la" from the libdrm slackbuild, or I'd hit a compile error on some of the mesademos, so, nothing serious (and a huge increase on FPS for 64-bit games!)

But the 32-bit cross-compile appears to be a different story. No issues for libdrm or libedit, but then llvm...

First, I have to symlink /usr/lib to /usr/lib32, or I get issues right away. Then I hit several problems somewhere in "readline.cpp"? The first issue I don't remember, but it went away after I removed the 64-bit version of python-2.7 and installed the 32-bit version instead.

And then I hit this:

[ 19%] Linking CXX shared library ../../../../../../lib/readline.so
cd /tmp/llvm-6.0.1.src/build/tools/lldb/scripts/Python/modules/readline && /usr/bin/cmake -E cmake_link_script CMakeFiles/readline.dir/link.txt --verbose=1
/usr/bin/32/clang++  -fPIC -O2 -march=i686 -mtune=i686 -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -ffunction-sections -fdata-sections -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-strict-aliasing -Wno-deprecated-register -Wno-vla-extension -Wno-macro-redefined -O3 -DNDEBUG  -L/usr/lib -Wl,-z,defs -Wl,-z,nodelete -shared -Wl,-soname,readline.so -o ../../../../../../lib/readline.so CMakeFiles/readline.dir/readline.cpp.o -ledit 
CMakeFiles/readline.dir/readline.cpp.o: In function `initreadline':
/tmp/llvm-6.0.1.src/tools/lldb/scripts/Python/modules/readline/readline.cpp:(.text.initreadline+0x18): undefined reference to `PyOS_ReadlineFunctionPointer'
/tmp/llvm-6.0.1.src/tools/lldb/scripts/Python/modules/readline/readline.cpp:(.text.initreadline+0x4c): undefined reference to `Py_InitModule4'
CMakeFiles/readline.dir/readline.cpp.o: In function `simple_readline(_IO_FILE*, _IO_FILE*, char*)':
/tmp/llvm-6.0.1.src/tools/lldb/scripts/Python/modules/readline/readline.cpp:(.text._ZL15simple_readlineP8_IO_FILES0_Pc+0x5b): undefined reference to `PyMem_Malloc'
/tmp/llvm-6.0.1.src/tools/lldb/scripts/Python/modules/readline/readline.cpp:(.text._ZL15simple_readlineP8_IO_FILES0_Pc+0x89): undefined reference to `PyMem_Malloc'
clang-3.8-32: error: linker command failed with exit code 1 (use -v to see invocation)
tools/lldb/scripts/Python/modules/readline/CMakeFiles/readline.dir/build.make:94: recipe for target 'lib/readline.so' failed
make[2]: *** [lib/readline.so] Error 1

Now, I don't know how to deal with this one. I've checked those references, and they're all in Python.h, which is the first include in readline.cpp. ?!?!?

So - who has succeeded in crosscompiling llvm-32-bit on a 64bit Slackware? Who has a concrete invocation of CFLAGS / CXXFLAGS / LDFLAGS (I'm a bit out of my depth in that department) that might 'fool' readline.cpp into compiling as it should?

I know a different solution would be to install a chroot 32-bit slackware, but I don't know how to do that either, the one 32-bit machine that I still have is an aging old laptop with an aging old Slackware version... And in any case, I just want to know how to fix this.

Originally Posted by PJBrs who has succeeded in crosscompiling llvm-32-bit on a 64bit Slackware?

Why would anybody even try to do that when there's already an official native-built 32 bit llvm-6.0.1 for 14.2?

http://slackware.uk/slackware/slackw..._slack14.2.txz

Ah, because I missed that update! That's nice.

On to compiling mesa- still running into problems. Now have compiled 32-bit python3, 32-bit Mako, but mesa fails, right at this bug here:

https://bugs.freedesktop.org/show_bug.cgi?id=100259

Hope I'll be able to deal with that one too...

PJBrs --

Maybe check out Alien Bob's Multilib: https://docs.slackware.com/slackware:multilib ?

Unless of course you're doing all that for your own enjoyment and education ...

HTH.

-- kjh

I'm doing all this to better enjoy my GPU, which entails cross-compiling mesa 18.2, which I don't enjoy so much yet. I don't know of anyone having a prebuilt 32-bit mesa-18.2 built on 14.2, so I guess that's up to myself.

With regard to education, I did check AlienBOB's multilib pages. As far as I can tell, crosscompiling, if everything goes right, requires (obviously) a multilib system, sourcing /etc/profile.d/32dev.sh, being able to execute a slackbuild for an i?86 ARCH, converting the package to compat-32 and installing it. That's not an issue for me, done that quite a few times. Indeed, to just have mesa's configure script complete, I needed to compile libdrm, and in order to let mesa make complete, I needed to compile and install 32-bit python3 and Mako. That all worked without issue, so I think that I have the cross-compiling basics for Slackware under my belt.

The problems start with the more 'advanced' compiling abilities. I have some experience getting configure options right, in a few cases I can fix some source code, but in this case - linking - I'm out of my depth. In this specific case, I get an error the same as (or very similar to; don't have my building machine at hand here):

drivers/dri2/.libs/platform_drm.o: In function `get_back_bo':
platform_drm.c:(.text+0x1d4): undefined reference to `gbm_bo_create_with_modifiers'
collect2: error: ld returned 1 exit status
libtool:   error: error: relink 'libEGL.la' with the above command before installing it

So - configure completes successfully, and make does too. This error only pops up at "make install". As far as I understand compiling, this means that these reference names are in the headers included in the mesa sources, so they also should be present in libraries installed in my system. So, for furthering my eduction, and for indeed compiling all this, I need to better understand the linking process...

The only way I could get 32bit LLVM compiled is to use a 32-bit Slackware install in a VM. Remember to install llvm first then build Mesa after if you go down that path.

Also you need to build libclc and mako as well to use the newer Mesa.

Well, the llvm problem was solved by Patrick Volkerding himself I downloaded the 32-bit package for llvm-6.0.1 from patches, ran it through convertpkg-compat32 and installed it. And for 32-bit mesa, I disabled the libclc-options (at least, on 32-bit), so no issue there for configuring and compiling mesa. It's only the linking at install time that fails.

Going to try build mesa again tonight, I've studied this bug report here: https://bugs.freedesktop.org/show_bug.cgi?id=100259 for quite a while now, and I think that I should have removed all installed versions of libgbm first, or maybe first remove the existing 32-bit mesa copy. Something like that, at least (and perhaps, something similar was going in with the llvm build).

(Of course, moving those libraries out of the way really is not a solution, it's a workaround, so I would like it even better if I can find out which flags to use in order for the compile to just succeed. That would really be educational.)

Well, stuff appears to have solved itself, and, unfortunately, I don't know why. The last thing I did yesterday, on a whim, was to install pkgconf from SBo and rerun the slackbuild, to no avail. So after that, I removed pkgconf. Today, I booted my pc again and went to the /tmp/mesa-18.2.0.src to (accidentally) run

 ARCH=i686 make install

and reproduce the error (yes, I stupidly forgot to add the DESTDIR stuff). And lo and behold - install seems to run fine, so I kill the process before it clobbers the rest of the system and do

ARCH=i686 make install DESTDIR=/tmp/package-mesa/
cd /tmp/package-mesa/
/sbin/makepkg -l y -c n /tmp/mesa-18.2.0-i686-1.txz
convertpkg-compat32 -i /tmp/mesa-18.2.0-i686-1.txz -d /tmp/
upgradepkg /tmp/mesa-compat32-18.2.0-x86_64-1compat32.txz

...and done (apart from the demos). Next thing, I try the full slackbuild to restart the entire build, and configure immediately throughs some error about PKG_CONFIG_ things. So, again on a whim, I reinstall pkg-config, thinking that I have clobbered something by installing and removing pkgconf. And now the slackbuild completes without issue... Why? Perhaps because a libgbm with all necessary symbols now already was in place in /usr/lib? I'll never know.

Anyways, I'll mark this thread as solved. Unfortunately I learnt nothing, because I solved this through sheer luck. I'm leaving this message as an "example". Feel free to elucidate these ramblings by making sense of them with knowledge