v0.0.34 make error about satdump HOT 13 CLOSED

@ZbychuButItWasTaken also observed this same issue on Debian 10 yesterday. I was able to reproduce it on quite a few systems, seems to happen with older GCC versions but I haven't isolated the issue more than that.

I'd guess I can edit the README to mention your workaround @sdrgeek, but I believe it would at this point be wiser to open an issue on https://github.com/nanomsg/nng, as this is definitely not supposed to happen.

from satdump.

Hmm... That is weird.

How did you install libnng? Maybe you need to build from source.

from satdump.

Thanks for the reply! I installed libnng by copy/pasting the steps from the install instructions:

# If libnng-dev is not available, you will have to build it from source
git clone https://github.com/nanomsg/nng.git
cd nng
mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make -j4
sudo make install

... and it installed with no errors

Downloading the updated v0.0.34 now.

from satdump.

UPDATE:

I now have a successful compile of v0.0.34.

The error recommended "recompile with -fPIC" and I thought that applied to SatDump. However, what corrected the issue for me to was go back & rebuild nng with that flag.

So, after deleting the /build folder under the 'nng' folder, I edited the following lines in nng/CMakeLists.txt as follows: (note '-fPIC' at the end of each line)

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${NNG_WARN_FLAGS} ${NNG_COVERAGE_C_FLAGS} ${NNG_SANITIZER_FLAGS} -fPIC")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${NNG_WARN_FLAGS} ${NNG_COVERAGE_C_FLAGS} ${NNG_SANITIZER_FLAGS} -fPIC")

... and then completed the build of nng per the instructions. I then deleted the /build folder under SatDump & followed the instructions to compile that. This time it completed normally.

from satdump.

I believe this is mostly due to your older system, but good that you got it working!

I should probably add this in the setup guide, in case someone else ends up in an identical case.

from satdump.

Yes, Ubuntu 18.04 is not the latest, but I would not be surprised if there are not still a lot of people using it.

Thanks so much for the support!

from satdump.

Definitely! But I can't do much about distributions shipping packages that won't behave as they should. Will drop this in the readme for sure.

You're welcome!

from satdump.

Note that this issue doesn't only happen on older systems or this specific version (also on 0.0.36):

Debian 10 with Linux 4.19.0-17-amd64 #1 SMP Debian 4.19.194-3 (2021-07-18) x86_64 GNU/Linux

The error message is similar but not the same:

/usr/bin/ld: /usr/local/lib/libnng.a(posix_debug.c.o): relocation R_X86_64_PC32 against symbol `stdout@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libnng.a(posix_thread.c.o): relocation R_X86_64_PC32 against symbol `nni_mxattr' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libnng.a(posix_resolv_gai.c.o): relocation R_X86_64_PC32 against symbol `resolv_worker' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libnng.a(inproc.c.o): relocation R_X86_64_PC32 against symbol `nni_inproc_tran' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libnng.a(posix_ipcdial.c.o): relocation R_X86_64_PC32 against symbol `ipc_dialer_dial' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libnng.a(posix_ipclisten.c.o): relocation R_X86_64_PC32 against symbol `ipc_listener_listen' can not be used when making a shared object; recompile with -fPIC

I'm trying to rebuild using the options @K4KDR suggested and edit this post according to the outcome.
@Aang23 please consider mentioning this issue in the README.

EDIT: it worked. I used this command while compiling nng:
cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS="${CMAKE_C_FLAGS} ${NNG_WARN_FLAGS} ${NNG_COVERAGE_C_FLAGS} ${NNG_SANITIZER_FLAGS} -fPIC" -DCMAKE_CXX_FLAGS="${CMAKE_CXX_FLAGS} ${NNG_WARN_FLAGS} ${NNG_COVERAGE_C_FLAGS} ${NNG_SANITIZER_FLAGS} -fPIC" ..
No editing of cmake files that can break your automatic update flow needed ;-)

from satdump.

The problem is you're building a shared module, with a static version of NNG. That's unusual. You can use the CMake POSITION_INDEPENDENT_CODE property if you need this, but why are you using static mode given that you're already building a shared object?

from satdump.

The problem is you're building a shared module, with a static version of NNG. That's unusual. You can use the CMake POSITION_INDEPENDENT_CODE property if you need this, but why are you using static mode given that you're already building a shared object?

Thanks for your reply. I looked deeper into the issue and it appears it's just a mistake on my side, I did not initially notice NNG was building as static by default.
I have no reason to link it statically, apart from potentially when building .deb or similar packages. I'd say the easiest way around is to edit the README with build instructions to include -DBUILD_SHARED_LIBS=ON by default.

Though, why does NNG default to static by default?

from satdump.

Fair question. I think that's probably the CMake default but I'm not sure. I used to tell people to link it statically in their project if they can since managing external dependencies can be such a pain. But CMake is also a pain.

from satdump.

Rebuilt SatDump. Everything worked flawlessly. @Aang23 I think you can close this issue now.

from satdump.

Fair question. I think that's probably the CMake default but I'm not sure. I used to tell people to link it statically in their project if they can since managing external dependencies can be such a pain. But CMake is also a pain.

Looked it up, seems like it is the default. Linking statically does make sense for something like NNG, but as shown in this instance can be a bit more annoying when it has to link against a .so.

Rebuilt SatDump. Everything worked flawlessly. @Aang23 I think you can close this issue now.

I have checked on my side as well, everything goes fine so I'm closing this.

from satdump.