search

filcuc / nimqml

Qt Qml bindings for the Nim programming language
Other
161 stars 20 forks source link

Opening a program doesn't works #7

Closed sebmenard closed 4 years ago

sebmenard commented 7 years ago

I am playing with Nim and DOtherSide on an unofficially supported Linux distribution (Void Linux) and I tried to package the library. A compiled Nim program doesn't run without the devel version of the package.

DOtherSide packaging

You can check the recipe here: https://github.com/voidlinux/void-packages/blob/e493813188cde0afdda5e43d87446b64ab0e2181/srcpkgs/dotherside/template

The applied patch at compilation here: https://github.com/voidlinux/void-packages/blob/e493813188cde0afdda5e43d87446b64ab0e2181/srcpkgs/dotherside/patches/fix-solib-versions.patch

And the shlibs entry: https://github.com/voidlinux/void-packages/blob/e493813188cde0afdda5e43d87446b64ab0e2181/common/shlibs#L2773

Here are the results of the builders (you can click on stdio in the Steps and Logfiles part of the page to see the log and the errors):

Some fixes have been tried in order to fix the failed builds but no luck at all. Have you an idea on this point?

Devel files

The devel package is necessary in order to run a Nim program which uses nimqml.

$ ./main 
could not load: libDOtherSide.so
compile with -d:nimDebugDlOpen for more information

A Void package maintener, @Gottox, asked me to run ldd and I got the following result with the hello world program:

$ ldd ./main
        linux-vdso.so.1 (0x00007ffda2921000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f4bac6ee000)
        librt.so.1 => /usr/lib/librt.so.1 (0x00007f4bac4e6000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f4bac2e2000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f4babf44000)
        /lib/ld-linux-x86-64.so.2 (0x00007f4bac9ff000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f4babd26000)

He said to me that it is not normal and that:

the program shouldn't open the so file directly but instead objdump -x the so-file while building and using the SONAME field instead

What do you think about this?

filcuc commented 7 years ago

Hello first thank you for the packaging effort.

For the first issue it seems to me that the problem is due to linking the x86 Qt while compiling on Arm but i don't know your build system. When i cross compile with CMake i usually use a CMAKE_TOOLCHAIN_FILE and set CMAKE_FIND_ROOT_PATH_MODE_LIBRARY to ONLY in this way i'm sure that the libraries are searched only in CMAKE_FIND_ROOT_PATH (where the root path points to the ARM root filesystem). Obviously this matter only when cross compiling and not with native compilation. If i were you i will double check this by giving a `file /usr/lib/QtQuick.5.8.0.so' this should tell you if the .so is for ARM or x86.

Regarding the nimqml i don't get what do you mean with 'devel packages is necessary in order to run..'. I'm quite sure that nimqml 0.7.0 should work with DOtherSide > 0.6.X . If this is not the case i will fix it. Regarding ldd you don't see the DOtherSide dependency because the library is loaded at runtime by using dlopen (this is common in Nim) and not linked at compile time. Obviously the dlopen fails if you don't have the DOtherSide.so in your $PATH or LD_LIBRARY_PATH. Basically you should package the DOtherSide.so as libDOtherSide.0.6.2.so and adding the following symbolic links libDOtherSide.so.0.6.so, libDOtherSide.so.

sebmenard commented 7 years ago

nimqml even @#head works correctly with DOtherSide 0.6.2. The fact is that the devel package installs the .so file like you can see in the recipe. I don't even know what the normal package install in fact.

The packaging doesn't seem to be correct, in theory devel files are not .so files but headers files like C ones for development?

Do you have the Arch recipe please?

filcuc commented 7 years ago

The packaging doesn't seem to be correct, in theory devel files are not .so files but headers files like C one for development?

Wait i'm not following you. Are you talking about packaging DOtherSide (the C library) or NimQml (the Nim wrapper around DOtherSide) ? Because IMHO NimQml shouldn't be packaged at all if you work with Nimble (the Nim package manager). That said, i think that NimQml should be treated like .c or .h files (if you want to package it): they should be put in a standard search path where the Nim compiler can found them (you need to check the Nim compiler documentation).

sebmenard commented 7 years ago

I'm speaking about DOtherSide packaging. I was responding to:

Regarding the nimqml i don't get what do you mean with 'devel packages is necessary in order to run..'. I'm quite sure that nimqml 0.7.0 should work with DOtherSide > 0.6.X . If this is not the case i will fix it.

So, yes, nimqml (even the head version) works with DOtherSide 0.6.2 package (only devel version though). I work with Nimble and use it for nimqml. Just that nimqml requires DOtherSide to work, of course.

I am just asking that I think the normal version of the package should install the .so files and the devel version should install the .h files.

Edit: Alright, this have been fixed and was a mistake in the recipe. Now we just need to figure out how to fix the aarch/arm builds.

filcuc commented 7 years ago

@gangsterakato please double check that you're not linking the x86 libraries

Duncaen commented 7 years ago

https://github.com/filcuc/nimqml/blob/0.7.0/src/private/dotherside.nim#L10 it should use the real versioned shared library, not the symlink. @gangsterakato the fix is wrong, unversioned shared libraries are part of the devel packages.

filcuc commented 7 years ago

@Duncaen ok

Duncaen commented 7 years ago

I never used nim, but this is how they do it for their internal wrappers, https://github.com/nim-lang/Nim/blob/devel/lib/wrappers/openssl.nim#L29 as example, they use patterns for the versioned shared object. But to be honest, this doesn't feel correct and the compiler or linker should handle this, like it is done with c/c++, it uses the .so but notices that its a link and then uses the file name of the library it links to.

filcuc commented 7 years ago

@Duncaen what you say implies linking the program at compile time. But this is not case for most wrappers on Nim where the dlopen method is preferred. that said, i will fix the so version on the .nim file by using DOtherSide.so.0.6 for example (so i will use the major number and not libDOtherSide.so.0.6.2) otherwise programs will stop to work every minor release.

filcuc commented 4 years ago

Done a long time ago