search

rejeep / evm

Emacs Version Manager
223 stars 34 forks source link

Emacs binaries require xorg libs #103

Closed DamienCassou closed 6 years ago

DamienCassou commented 6 years ago

Is it normal that travis builds require xorg libs? Here is an output from a docker running ubuntu (not related to travis at all):

# evm install emacs-26-pretest-travis --use
Successfully installed emacs-26-pretest-travis
# emacs --version
/tmp/emacs-26-pretest-travis/bin/emacs: error while loading shared libraries: libXaw.so.7: cannot open shared object file: No such file or directory                                                                                                       
# evm install emacs-25.3-travis --use                                                
Successfully installed emacs-25.3-travis
# emacs --version
/tmp/emacs-25.3-travis/bin/emacs: error while loading shared libraries: libXaw.so.7: cannot open shared object file: No such file or directory                                                                                                             
# evm install emacs-25.2-travis --use                                                
Successfully installed emacs-25.2-travis
# emacs --version
/tmp/emacs-25.2-travis/bin/emacs: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
sambrightman commented 6 years ago

I know that at least 25.3 was built using --without-all but perhaps this doesn't cover X for some reason?

gonewest818 commented 6 years ago

so it seems:

root@25e97d593866:/# evm install emacs-25.3-travis --use
Successfully installed emacs-25.3-travis
root@25e97d593866:/# emacs --version
/tmp/emacs-25.3-travis/bin/emacs: error while loading shared libraries: libXaw.so.7: cannot open shared object file: No such file or directory
root@25e97d593866:/# ldd /tmp/emacs-25.3-travis/bin/emacs
    linux-vdso.so.1 =>  (0x00007fff92bf9000)
    libXaw.so.7 => not found
    libXmu.so.6 => not found
    libXt.so.6 => not found
    libSM.so.6 => not found
    libICE.so.6 => not found
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f4e4d0e0000)
    libX11-xcb.so.1 => not found
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f4e4cebe000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4e4ccb6000)
    libXfixes.so.3 => not found
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f4e4ca8d000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4e4c870000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4e4c567000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4e4c19e000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4e4bf9a000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f4e4bd96000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f4e4bb90000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f4e4d41a000)
sambrightman commented 6 years ago

Of course, the Travis binaries are intended for Travis so it's not really a priority to make them work elsewhere. That said, I don't really see a drawback to simplifying the build further and making them more widely usable (or perhaps in the future bringing back the -bin versions for local testing/general use). A slight concern would be anybody depending on auxiliary functions provided in the X components.

I propose re-releasing the 26-pretest version — without further changes (so no GnuTLS support per #101 , no version bump to .91) — and seeing if this works for you. If it does, proceed also with a snapshot. If there are no complaints for a while we can potentially re-release previous releases (also gradually — although I'm leaning against doing this a little). I expect this to work, since my new output is:

travis@9f751859e6dd:~$ ldd /tmp/emacs-26-pretest-travis/bin/emacs
    linux-vdso.so.1 =>  (0x00007fff869da000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f136c48e000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f136c265000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f136c047000)
    libanl.so.1 => /lib/x86_64-linux-gnu/libanl.so.1 (0x00007f136be43000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f136bb3d000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f136b774000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f136c696000)
sambrightman commented 6 years ago

Re-opening this; can mark as fixed when either the Git snapshot or all versions are confirmed working. Please verify.

DamienCassou commented 6 years ago

I have tested build with gitlab ci and the new no-X Emacs 26 with success. Thank you so much.

For our infrastructure, we need all supported EVM binaries to be built without X. I understand that's quite some work and you might not want to go that direction. I can build all/most/some binaries myself and upload them if you want.

sambrightman commented 6 years ago

My concern wouldn't so much be about the work involved but about changing past releases and breaking things. Will think about it a bit - maybe @rejeep has an opinion?

I'll anyway issue a new 26 and snapshot regarding #101, and make no-X11 the default going forward.

rejeep commented 6 years ago

@sambrightman What is it that you would be breaking?

sambrightman commented 6 years ago

In principle, it could break something (I've seen people depend on utility functions in unrelated modules), and its rather counter to reproducible builds. Practically speaking, it seems very unlikely and probably worth it to help out people without X.

gonewest818 commented 6 years ago

I don’t understand how the builds are different (the one that was broken versus the one you swapped in with #104). What changed in the build that required backing out?

@damiencassou does Gitlab CI allow customer to provide a docker image for their tests to run? If so, there’s another (arguably cleaner) way to handle your particular test case, which is to compile and run Emacs in an Ubuntu image like Silex/docker-emacs

sambrightman commented 6 years ago

I don't understand what you don't understand ;)

As described above, --without-all (recommended way to build Travis binaries from README) doesn't disable X support, so existing binaries have/had it. The build added in #104 has some extra build flags to disable X. It seems like a reasonable way forward regardless of this use-case.

gonewest818 commented 6 years ago

I just meant the commit in #104 doesn't document how the build was configured. For instance, if I wanted to update #102 to contain the proper recipe.

sambrightman commented 6 years ago

Yes, it's for testing. There are a couple of other things I want to get out before you need to update #102, and we should discuss that in the ticket when the time comes.

I'm leaning towards just re-issuing all the previous binaries, since the risk of breakage seems quite small.

gonewest818 commented 6 years ago

yup, I'm okay to wait on #102.

DamienCassou commented 6 years ago

@DamienCassou does Gitlab CI allow customer to provide a docker image for their tests to run?

it does

If so, there’s another (arguably cleaner) way to handle your particular test case, which is to compile and run Emacs in an Ubuntu image like Silex/docker-emacs

Thanks for the link. Except for the workdir at the end (which won't exist because gitlab won't mount it), I think we could use this approach and maybe this container.

We are currently using this docker file and this GitLab CI configuration which uses EVM to provide all Emacs versions in the same container. Having only one container with every Emacs version has the advantage of consuming less disk space on the CI runners (I guess).

gonewest818 commented 6 years ago

May I suggest we take that discussion into a ticket in that other project? To keep on-topic here.

On Feb 21, 2018, at 9:14 AM, Damien Cassou notifications@github.com wrote:

@DamienCassou https://github.com/damiencassou does Gitlab CI allow customer to provide a docker image for their tests to run?

it does

If so, there’s another (arguably cleaner) way to handle your particular test case, which is to compile and run Emacs in an Ubuntu image like Silex/docker-emacs

Thanks for the link. Except for the workdir at the end (which won't exist because gitlab won't mount it), I think we could use this approach and maybe this container.

We are currently using this docker file https://hub.docker.com/r/nicolaspetton/emacs-docker and this GitLab CI configuration https://gitlab.petton.fr/mpdel/mpdel/blob/master/.gitlab-ci.yml which uses EVM to provide all Emacs versions in the same container. Having only one container with every Emacs version has the advantage of consuming less disk space on the CI runners (I guess).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rejeep/evm/issues/103#issuecomment-367400444, or mute the thread https://github.com/notifications/unsubscribe-auth/ACWM9pVQb_Upqf7MY8wAhG-FSJAK7rO3ks5tXE8AgaJpZM4SKXvs.

sambrightman commented 6 years ago

Both new snapshots are using this method, and I have a 25.3 ready to re-release soon. If that doesn't see new issues for a few days I'll do the rest.

DamienCassou commented 6 years ago

Please see #107.

sambrightman commented 6 years ago

107 is unrelated to the X library change, as far as I know.

sambrightman commented 6 years ago

Is it still worth re-releasing earlier releases (without GnuTLS, since it isn't necessary) like this, given the conclusion in #107?

DamienCassou commented 6 years ago

Is it still worth re-releasing earlier releases (without GnuTLS, since it isn't necessary) like this, given the conclusion in #107?

not for me. Thanks for asking.

sambrightman commented 6 years ago

Okay, well snapshots are updated and build recommendations for the future. We can revisit if necessary.