I've been installing "hamlib 1.2.15.3" (sourceforge) on my RaspberryPi under Raspbian and everything
worked great for a while.
When I noticed an unimplemented feature, I downloaded the newest developer version here:
here (something like this, but this link may change every day: http://n0nb.users.sourceforge.net/hamlib-3.0~git-6e44327-20140321.tar.gz)
So I downloaded it and did the usual: untar to a folder, ./configure, make, make install.
After all was done, I launched rotctl and there comes this message: rotctl: symbol lookup error: /usr/local/lib/libhamlib.so.2: undefined symbol: g313_caps
I thought the package wasn't flawless and I tried to install the old version again. But it's still like that. Also I tried ldconfig every now and then.
To be honest: I'm a beginner when it comes to linux, so I don't know what I have done there. Maybe I was doing a major mistake, a normal linux user wouldn't do. Maybe it was wrong to install that package without uninstalling the older version. Also I don't even know how to do that.
Basically there is only one file in the source code, I need to change to the newer version. So, if there is anyone who could tell me, how to make a clean uninstall, I could replace only this file in the source and install again. I think that would do the thing.
Or shall I rather ask the people from the hamlib developer team?
Thank you in advance.
Related
Everytime I try to build and run a program, including the standard 'Hello world!' nothing happens, I get:
==== Program exited with exit code: 0 ====
Time elapsed: 000:00.000 (MM:SS.MS)
Press any key to continue...
At the bottom it says:
'ming32-make' is not recognized as an internal or external command, operable prgram or batch file.
I have Codelite version 16 on Windows 10. I also have MinGW installed to C: and have edited the Environment variables to include C:\MinGW\bin
However, in command prompt gcc --version shows me the gcc version in C:\Users\me> and not C:\MinGW
I don't know if this is relevant or not.
All the other results seem to suggest a compiler not found problem, but this does not seem to be my case. Thanks in advance.
This is what I have installed at the moment. Can I get 'make'from one of the other files?
The Installed files
Looks like you either don't have ming32-make.exe or it can't be found.
Also I notice you still use old MinGW. I would recommend switching to newer MinGW-w64 (which supports both Windows 32-bit and 64-bit).
The standalone build from https://winlibs.com/ does include ming32-make.exe, and since you can just unzip it (no installation needed) you can try it without removing the old MinGW. Just make sure you don't have anything in your PATH variable to avoid running programs from the wrong location.
ming32-make.exe is either not installed or can't be found on your Environment variable PATH.
No, there is no mingw32-make in that bin folder. When I used the Installer originally I only selected: mingw32-gcc-g++-bin although there were other bin files. Where can I get it?
mingw32-make is outdated.
See How to compile makefile using MinGW?
If you are having problems with mingw, I would recommend using MSYS2 or a package manager like Chocolatey.
Just get rid of the previous installation first. Not mandatory but prevents confusion and storage drain due to multiple copies of mingw.
To install MinGw using chocolatey, run cmd as admin and use
choco install mingw
For make
choco install make
What worked for me was also installing mingw32-base-bin from the Installer (see second option in image in the original question).
The installation tutorial I was following did not mention installing this.
I've decided to leave this here as an answer in case someone else runs into a similar problem.
MSYS is a good option for compilers in recent CodeLite or VS-Code installation. https://www.msys2.org/.
Once you downloaded the compiler using the following steps from the installer but still have the problem with the make then follow these steps:
Reopen the MSYS2 terminal from your windows if that is previously installed.
Run the command pacman -S --needed base-devel mingw-w64-x86_64-toolchain
You will be asked to select the option from the list. You should select the option which refers to mingw-w64-x86_64-make.
Once the installation is successfully done, then open CodeLite settings->Buid Settings and check your Make file location. If that is empty or showing an unknown location then click the three dots at the very right of that box. The browse and navigate to location or where you installed the make by pacman. In my case it is C:/msys64/usr/bin/make.exe.
Click Apply and Save.
Now it might be needed to create a fresh workspace and re-run your code.
I am a beginner C programmer, and recently I have run into a problem that I was unable to solve.
I am struggling to install and use a C library. The message error is:
My OS is Mac OS X and im try install the file with ".command" format.
Can someone help me install this library?
Thanks in advance.
More than help installing the library, you need help in understanding what's going on.
Someone gave you a command to run and you ran it, but they were assuming that you were using a different OS, like Ubuntu.
The first message "apt-get not found" is because you're running MacOS, which doesn't have an "apt-get" command.
The second error is because you also don't have wget.
The rest of the messages indicate a poorly written script file, since it blew up twice and still went on to truncate files and do other things.
While you're not going to be able to install apt-get, you might be able to find a compatible version of wget. If not, you can download whatever it was trying to get using your browser, since wget is typically used to automate web HTTP/HTTPS requests.
Without seeing the file, I don't know what the rest if the script was trying to do, but if you read it you should be able to figure out what it was doing, and do it manually.
An easier way to do all this is to install Virtualbox on your mac and run a copy of Ubuntu inside a virtual machine. Then you can run your class assignments without needing to rewrite them all.
I should preface this by stating I'm working with Xcode on macOS Sierra 10.12.6.
I installed GDB with homebrew and it appeared to install fine until I tried to use it. In terminal it kept saying that it was not a valid command. (I'm new to C and was working with my professor. Even he was baffled when I tried to use it after downloading it in front of him). So later I tried to install it by creating the make file and still having problems. I then used homebrew again but to uninstall and reinstall, still having problems.
Now I'm at the point where I can't even run my C files when I use gcc to compile them. I simply get a statement that unable to open file. I've read someone suggest to sudo mv /usr/local /usr/_local and I'm notified that I don't have permission, even after entering in my password.
I've gotten every error when I try to remove all items belonging to gdb. I've gone as far as removing Xcode in hopes that I can do a fresh install of it all.
I'm at the point where I've begun looking into removing my macports entirely.
I'm looking for any advice into how I can try to start off from a clean slate. I need to use gdb on a project that is due and can't get this up and running. Please help talk me from a ledge!
EDIT:
I have used Sublime to create a simple Hello World file and it compiles and runs fine with gcc. So my project file has become corrupted somehow. At least I can calm down a bit. But I would still like to get this gdb issue figured out and install a fresh copy with everything old removed.
I'm working with Xcode on macOS Sierra 10.12.6
I need to use gdb on a project that is due and can't get this up and running
I don't know how to reinstall gdb on macOS, but be aware that gdb is broken on macOS Sierra as of now (at least debugging dynamic libraries), see Bug report.
So if you even get gdb correctly installed you can probably end up with nothing (gdb won't be able to debug what you want).
Try making your file executable using gcc -Wall -g $fileName.c -o $fileName. This will show all the errors that might exists. Secondly, if it doesn't work and you absolutely need to use gdb, using a VM of Linux(recommend Ubuntu if you're new to Linux or Mate) is a good alternative. You then have to just use sudo apt-get install gdb and even install gdb-dashboard git-hub gdb-dashboard if you want to do some serious debugging. That's the quickest fix that I can think of you are in a hurry. Btw good VMs are VirtualBox and Parallel Desktop(if you want to have access to your local files from the VM).
I'm trying to install a geocoder for a website I'm building. I'm using Geocoder because the query limit for the Google Maps API falls short of my needs. I installed all the gems required and have SQLite3. When I'm actually trying to install the geocoder gem (Geocoder::US) I get an error while running the make file.
I'm getting an error I cannot figure out. It mentions the error (in the title) then talks of an non-existent file (sqlite3ext.h). Here is the error:
I know this is vague but I've been working for 10+ hours trying to install this and have found little help online. Any advice on which direction to go would be appreciated.
This is from the project's Readme:
To build Geocoder::US, you will need gcc/g++, make, bash or equivalent,
the standard *NIX ‘unzip’ utility, and the SQLite 3 executable and
development files installed on your system.
It seems that you lack the SQLite3 development headers.
This is relevant:
NOTE: If you do not have /usr/include/sqlite3ext.h installed, then
your sqlite3 binaries are probably not configured to support dynamic
extension loading. If not, you must compile and install SQLite from
source, or rebuild your system packages. This is not believed to be a
problem on Debian/Ubuntu, but is known to be a problem with Red
Hat/CentOS.
Also they do not mention Windows. You should:
Ask them if someone uses it on Windows and if there are instructions for that.
Evaluate the thing on Linux, Debian/Ubuntu especially.
-fPiC is not your problem. As the log states, the compiled code is already position independent. The problem is, that the sqllite3ext.h is not in the compiler include path.
gcc 4.4.4 c89 Fedora 13
I am wondering what is better. To give you a compile of examples: apache runtime portable and log4c.
The apr version in my fedora repository is 1.3.9. The latest stable version on the apr website is 1.4.2.
Questions
Would it be better to download from the website and install, or install using yum?
When you install from yum sometimes it can put things in many directories. When installing from the tarball you can put the includes and libraries where you want.
The log4c the versions are the same, as this is an old project.
I downloaded log4c using yum. I copied all the includes and libraries to my development project directory.
i.e.
project_name/tools/log4c/inc
project_name/tools/log4c/libs
However, I noticed that I had to look for some headers in the /usr/include directory.
Many thanks for any suggestions,
If the version in your distribution's package repository is recent enough, just use that.
Advantages are automatic updates via your distribution, easy and fast installs (including the automatic fetching and installing of dependencies!) and easy removals of packages.
If you install stuff from .tar.gz by yourself, you have to play your own distribution - keep track of security issues and bugs.
Using distribution packages, you have an eye on security problems as well, but a lot work does the distributor for you (like developing patches, repackaging, testing and catching serious stuff). Of course each distributor has a policy how to deal with different classes of issues for different package repositories. But with your own .tar.gz installs you have nothing of this.
It's an age-old question I think. And it's the same on all Linux distributions.
The package is created by someone - that person has an opinion as to where stuff should go. You may not agree - but by using a package you are spared chasing down all the dependencies needed to compile and install the software.
So for full control: roll your own - but be prepared for the possible work
otherwise use the package.
My view:
Use packages until it's impossible to do so (conflicts, compile parameters needed, ..) . I'd much rather spend time getting the software to work for me, than spend time compiling.
I usually use the packages provided by my distribution, if they are of a new enough version. There is two reasons for that:
1) Someone will make sure that I get new packages if security vulnerabilities in the old ones are uncovered.
2) It saves me time.
When I set up a development project, I never create my own include/lib directories unless the project itself is the authorative source for the relevant files I put there.
I use pkg-config to provide the location of necessary libraries and include files to my compiler. pkg-config use some .pc-files as a source of information about where things are supposed to be, and these are maintained by the same people who create the packages for your distribution. Some libraries does not provide this file, but an alternative '-config'-script. I'll provide two examples:
I'm not running Fedora 13, but an example on Ubuntu 10.04 would be;
*) Install liblog4c-dev
*) The command "log4c-config --libs" returns "-L/usr/lib -llog4c" ...
*) The command "log4c-config --cflags" returns "-I/usr/include"
And for an example using pkg-config (I'll use SDL for the example):
*) Install libsdl1.2-dev
*) The command "pkg-config sdl --libs" returns "-lSDL"
*) The command "pkg-config sdl --cflags" returns "-D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL"
... So even if another distribution decides to put things in different paths, there are scripts that are supposed to give you a reliable answer to where things is - so things can be built on most distributions. Autotools (automake, autoconf, and the likes) amd cmake are quite helpful to make sure that you don't have to deal with these problems.
If you want to build something that has to work with the Apache that's included with Fedora, then it's probably best to use the apr version in Fedora. That way you get automatic security updates etc. If you want to develop something new yourself, it might be useful to track upstream instead.
Also, normally the headers that your distro provides should be found by gcc & co. without you needing to copy them, so it doesn't matter where they are stored by yum/rpm.