Tilix: Fedora COPR builds are broken

Created on 7 Mar 2017  Â·  24Comments  Â·  Source: gnunn1/tilix

It seems the Fedora COPR builds are broken since 1.5.1, with 1.5.0 only built for Fedora 24, 25 and 26.

More information at https://copr.fedorainfracloud.org/coprs/heikoada/terminix/builds/

Most helpful comment

This should be fixed now with new release, I'm stilling using LDC but with libphobos and libdruntime statically linked to avoid older versions of these libraries on Fedora and other distributions.

All 24 comments

I don't handle the packaging, did you send an e-mail to the package maintainer?

And looking at the build file, this looks like the problem is because of the newly added localized man pages.

Ah, fair enough. Let me close issue then.

I would like to reopen the issue - the maintainer wrote me, that it is not possible to build 1.5.2 version of Terminix for Fedora 25 because it requires newer ldc-runtime than Fedora ships. However this is serious issue since latest build for Fedora 25 is 1.5.0 which is crashing (#803, #806). Older builds are not preserved in COPR. Is it possible to lower the requirements so it would be possible to build Terminix on Fedora 25? Current only option is to use precompiled release binary, which not nice.

I've dropped a note to the maintainer. I think the COPR is just using my binaries so I'm not sure what the issue is, hopefully the Fedora package maintainer can elaborate.

@gnunn1 What about keeping .0 releases as LTS ? so they can get hot fixes without updating requirements versions or any new feature

@bil-elmoussaoui Unfortunately I think that would be too much effort to maintain for the resources available (i.e. me).

The COPR maintainer replied to me and I can confirm the issue, it's because I switched to LDC for building the binaries and by default it links against the libphobos shared library instead of linking against it statically. Unfortunately, this isn't something that can be changed at compiled time, LDC must be built to support static packages. You can see the LDC bug report here:

https://github.com/ldc-developers/ldc/issues/1282

As a result, I'll switch back to building releases with DMD as I'm not interested in doing custom builds of LDC.

Thanks a lot for your work!

@gnunn1 Huh? Just build with a recent LDC (>= 1.1) and ship libphobos and libdruntime with your binaries. That's an easy thing!
Also, thanks to @kalev, the latest LDC is available in Fedora: https://admin.fedoraproject.org/pkgdb/package/rpms/ldc/

@ximion Fedora's version of LDC is too old (https://apps.fedoraproject.org/packages/ldc), they are talking about upgrading to 1.1 but it's only available in Fedora 26 and Rawhide as far as I know.

I might be missing something here, but I'm not keen on shipping libphobos in the binaries as it just duplicates the version already available in up-yo-date distros. Also, where would these libraries get installed, into /lib and if so wouldn't that potentially conflict with LDC packages on distros that do have up-to-date LDC available?

I used to always build the binaries with DMD until around 1.5.0 so this is just going back to the status quo. If LDC had the option for static linking as a runtime option I would simply go that route.

@gnunn1 At least on Debian, statically-linking everything with LDC works quite well:

$ ldc2 test.d -oftest
$ ldd test
        linux-vdso.so.1 (0x00007fff5613e000)
        libphobos2-ldc.so.71 => /usr/lib/x86_64-linux-gnu/libphobos2-ldc.so.71 (0x00007fa310cf1000)
        libdruntime-ldc.so.71 => /usr/lib/x86_64-linux-gnu/libdruntime-ldc.so.71 (0x00007fa3109f3000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fa3107eb000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa3105e7000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa3103ca000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa3100c4000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa30fd26000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa30fb0c000)
        /lib64/ld-linux-x86-64.so.2 (0x0000559fd35f5000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa30f8f5000)

$ ldc2 -static test.d -oftest
$ ldd test
        not a dynamic executable

Static Phobos and DRuntime libraries are available and installed with the phobos -dev packages.

On Arch I get:

ldc2 -static test.d -oftest
/usr/bin/ld: cannot find -llphobos2
/usr/bin/ld: cannot find -lldruntime
collect2: error: ld returned 1 exit status

Not sure why the linker is trying to find phobos2 instead of libphobos2, sometimes I really prefer dealing with Java. :)

It is trying to find libphobos2 ;-) The standard Linux/UNIX library names lib.so and lib.a get shortened to -l as a linker flag.

That message means you don't actually have the static libraries available.
For Tilix, the Automake stuff can't do the job since it is calling ldmd2 which doesn't know about -static, and dub fails with weird linking issues, so I think I'd need to try the Meson build files next in order to build a static binary.

That message means you don't actually have the static libraries available.

Which is not surprising given Arch usually does not install static libraries at all.

Yeah that looks to be the issue, there's no LDC static library version on Arch as far as I can tell. Basically there's no -devel package for libphobos for LDC like there is for DMD which supplies the static library version.

find . -name "*phobos*"
./share/licenses/liblphobos
./share/licenses/libphobos-devel
./share/licenses/libphobos-devel/LICENSE-phobos
./share/licenses/libphobos
find: ‘./share/polkit-1/rules.d’: Permission denied
./lib/liblphobos2-debug.so
./lib/libphobos2.so.0.72
./lib/libphobos2.so.0.73
./lib/libphobos2.so
./lib/libphobos2.a
./lib/libphobos2-ldc.so.70
./lib/libphobos2-ldc-debug.so.71
./lib/libphobos2-ldc.so.71
./lib/libphobos2.so.0.71
./lib/libphobos2-ldc-debug.so.70
./lib/liblphobos2.so

I made this work with Meson, but it's kind of wacky, since Meson uses the dynamic versions of GtkD, so I am creating a weird hybrid at time.

What you normally do in these cases is ship your shared libraries in a private lib dir (e.g. /usr/lib/tilix) and place your executable there as well, then add a tiny shell script to /usr/bin containing something like:

#!/bin/sh
export LD_LIBRARY_PATH=/usr/lib/tilix
/usr/lib/tilix/tilix $@

And be done with it.

Or I can just go back to using DMD and be done with it...

Depends. LDC creates much faster code compared to DMD, which is a strong reason at least for me to compile with LDC.
If that's not a priority, either compiler is fine (DMD has its fast compile speed going for it).

This should be fixed now with new release, I'm stilling using LDC but with libphobos and libdruntime statically linked to avoid older versions of these libraries on Fedora and other distributions.

I just kicked off the process for getting tilix into Fedora proper by the way, https://bugzilla.redhat.com/show_bug.cgi?id=1434003

@kalev There is a issue on Tilix that is (ab)used to notify package maintainers about changes interesting to them: https://github.com/gnunn1/tilix/issues/25
Maybe you want to subscribe there (despite the large amount of comments, it nowadays is low-volume)

Subscribed now, thanks @ximion

Was this page helpful?
0 / 5 - 0 ratings

Related issues

alex285 picture alex285  Â·  3Comments

honze-net picture honze-net  Â·  3Comments

yodatak picture yodatak  Â·  4Comments

vaijab picture vaijab  Â·  3Comments

iax7 picture iax7  Â·  4Comments