search

sm0svx / svxlink

Advanced repeater system software with EchoLink support for Linux including a GUI, Qtel - the Qt EchoLink client
http://svxlink.org/
Other
438 stars 173 forks source link

make install not copying newly built module .so libraries #197

Open mmiller7 opened 8 years ago

mmiller7 commented 8 years ago

I preformed an upgrade-install to the latest version of svxlink, when I performed the 'make install' it did not update the old module *.so files located at '/usr/lib/svxlink' directory. This resulted in an error when I loaded the program complaining the core was newer than the modules.

To fix this, I manually located the updated .so in the "build/lib" area (which were created properly) and overwrote the old ones in the /usr/lib/svxlink

This seems like it should have been part of the make-install scripts when it updated everything else.

Here is the error which appears in the logfile that pointed me to the out of date libraries:

Sat Mar 26 14:37:43 2016: SvxLink v1.5.0 Copyright (C) 2003-2015 Tobias Blomberg / SM0SVX Sat Mar 26 14:37:43 2016: Sat Mar 26 14:37:43 2016: SvxLink comes with ABSOLUTELY NO WARRANTY. This is free software, and you are Sat Mar 26 14:37:43 2016: welcome to redistribute it in accordance with the terms and conditions in the Sat Mar 26 14:37:43 2016: GNU GPL (General Public License) version 2 or later. Sat Mar 26 14:37:43 2016: Sat Mar 26 14:37:43 2016: Using configuration file: /etc/svxlink/svxlink.conf Sat Mar 26 14:37:43 2016: --- Using sample rate 48000Hz Sat Mar 26 14:37:43 2016: Sat Mar 26 14:37:43 2016: Starting logic: SimplexLogic Sat Mar 26 14:37:43 2016: Loading RX: Rx1 Sat Mar 26 14:37:43 2016: Loading TX: Tx1 Sat Mar 26 14:37:43 2016: Loading module "ModuleHelp" into logic "SimplexLogic" Sat Mar 26 14:37:43 2016: Found /usr/lib/svxlink/ModuleHelp.so Sat Mar 26 14:37:43 2016: Module Help v1.0.0 starting... Sat Mar 26 14:37:43 2016: * ERROR: This module is compiled for version 1.4.99.23 of SvxLink but the running version of the SvxLink core is 1.5.0. Sat Mar 26 14:37:43 2016: * ERROR: Initialization failed for module ModuleHelp in logic SimplexLogic Sat Mar 26 14:37:43 2016: Loading module "ModuleParrot" into logic "SimplexLogic" Sat Mar 26 14:37:43 2016: * ERROR: Failed to load module ModuleParrot into logic SimplexLogic: /usr/lib/svxlink/ModuleParrot.so: undefined symbol: _ZN5Async5TimerC1Ei Sat Mar 26 14:37:43 2016: Loading module "ModuleEchoLink" into logic "SimplexLogic" Sat Mar 26 14:37:43 2016: Found /usr/lib/svxlink/ModuleEchoLink.so Sat Mar 26 14:37:43 2016: Module EchoLink v1.3.1.99.1 starting... Sat Mar 26 14:37:43 2016: * ERROR: This module is compiled for version 1.4.99.23 of SvxLink but the running version of the SvxLink core is 1.5.0. Sat Mar 26 14:37:43 2016: *\ ERROR: Initialization failed for module ModuleEchoLink in logic SimplexLogic

pe1chl commented 8 years ago

The location of the .so files has changed! It is now depedent on the architecture. E.g. on 64-bit Intel it is: /usr/lib/x86_64-linux-gnu/svxlink/ You should clean out the old installation before installing this new one, or there will be different versions of the same module around. Also fix the config file.

mmiller7 commented 8 years ago

How would I have cleaned out the old installation? I tried "make remove" and "make uninstall" (which has worked on some programs I used in the past) without success, and since it's a makescript I have no idea where it might have put things. I also re-read the README and INSTALL documentation and could not find any reference to how I would go about removing an old install nor upgrading. If I manually rename/delete the .so files, it complains they are missing so that seems to tell me something isn't being set up correctly in the build.

After a fair bit of hunting, I did locate a copy of the .so libraries in /usr/lib/arm-linux-gnueabihf/svxlink/, what does "eabihf" mean at the end of the architecture?

I'm not sure what you mean by "fix the config", I used the ".example" files as a starting point and merged in my changes for callsign/audio-device/etc that are user and platform specific but didn't touch anything else. Are you saying the .example is wrong somehow too?

pe1chl commented 8 years ago

It maybe would have worked when you did "make uninstall" before pulling the new git version. I am not sure about that. I faced this problem a few times before and I wrote a script that removes everything except customized files (the conf file and the files in the /local/ directories) which I run every time before installing a new version. It is also important to run "ldconfig" after installing the new version. "fix the config" in this case means remove the LIBDIR line at the top of the .conf file, or change its value to that new location. (which is the default when it is omitted)

I don't know how to add a file attachment here but I have posted the remove script on the mailing list in the past so it should be in the archive.

mmiller7 commented 8 years ago

Finally got a clean install by doing a find / -name "*svxlink*" and then parsing thru the list of files/folders to clean it up by hand, then merging my backup config files to the new config.

"make uninstall" didn't seem to work and I couldn't find an existing script to perform a clean uninstall...still seems like it ought to have some automated upgrade path between versions.

sm0svx commented 7 years ago

The problem here is that "make install" is not an installer. It's more of a tool for package maintainers to help them build the packages. Installing software from source with a make install is therefore not very robust. That is especially true when file locations or file names changes.

If possible, try to use a prebuilt package. Packages should be available for Debian and Ubuntu but I have not tested them.

There are ways to improve on the situation by installing SvxLink in another location, like /opt/svxlink. Then it will be easy to just remove that whole directory to clean all old versions out. I'll see if I can add some documentation on the Wiki for how to do that.

The previous build system used by SvxLink had a "make install" but since switching to CMake this feature is missing.

sm0svx commented 7 years ago

I need to return to this /opt/svxlink installation location a bit later. It was a bit more involved than I first anticipated. The idea anyway is to put all executables, libraries, plugins and other files that should not be changed in /opt/svxlink. /etc/svxlink is used for configuration and /var is used for variable runtime data as usual. Using this scheme one can just do a "rm -rf /opt/svxlink; make install" and then one would have a clean installation but configuration and variable data will be preserved.