I have set up a radius-server on a raspberry-pi. Now I want to test it according to article 6.2.1 in http://networkradius.com/doc/FreeRADIUS-Implementation-Ch6.pdf
Unfortunately building the "eapol_test" file as described in the document doesnt work for me. When executing
make eapol_test
in the newly created folder it runs for a minute or so and then exits, saying
/usr/bin/ld: cannot find -lnl
collect2: ld returned 1 exit status
Makefile:1625: recipe for target 'eapol_test' failed
Using a newer version of wpa_supplicant doesnt solve it.
I dont know much about the make command, or how to make it find "-lnl" (whatever this might be) and I couldn't find a solution to this problem either.
Does anyone know how to fix this? Thank you in advance
In case someone stumbles upon this (like I did from a Google result), following solves this issue (Debian Jessie / wpa_supplicant-2.5 from source):
Install libnl-3-dev and symlink libnl-3.so to libnl.so
# apt-get install libnl-3-dev
# ln -s /lib/x86_64-linux-gnu/libnl-3.so /lib/x86_64-linux-gnu/libnl.so
# make clean
# make eapol_test
Related
I have some older utilities that are only sometimes needed and it came time to use a particular one and I found it didn't work. I know that some of the other utilities in the same package were working, but rather than worry about why this one was unique, I figured it just needed a recompile on the most recent Fedora and so I ran make.
I then learned that it couldn't find cc1. So the first thing I did was: dnf update gcc
This upgraded some 11 packages but didn't cure the cc1 problem, so I did which gcc to find where that is, then made a soft link to the cc1 program in the same directory. The compile then proceeded until a / the final linking, which should be:
gcc -o run${BINTYPE} run.o hashc.o
'run' here is the utility name. But the compile returns:
gcc: fatal error: ‘-fuse-linker-plugin’, but liblto_plugin.so not found
compilation terminated.
I then did a web search and found a few stack-overflow entries, such as this one, (and a handful of non-stack-overflow pages, too) but none matched or provided a working solution.
I then found where liblto_plugin.so actually is:
/usr/lib64/bfd-plugins/liblto_plugin.so
...and checked LD_LIBRARY_PATH - the location wasn't in there, so I added it as the first entry (/usr/lib64/bfd-plugins/). That didn't work - same error.
And, I also tried going to where this distribution of Fedora seems to want to find it - which is /usr/libexec/gcc/x86_64-redhat-linux/ - and then making a soft link there, too, but that didn't work either.
OK, this should be simple, but I'm stumped!
It might be worth noting that from what I understand, this plugin is about optimizing dynamic linking at runtime, and that's simply not involved for this utility. All this program does is validate an environment before running to ensure it doesn't even try to launch unless certain conditions are met, so static linking should work fine. So maybe a workaround is to simply provide a flag that says skip the plug-ins? I'd rather "fix it correctly," but I'll settle for it doing what I need to do right now.
UPDATE
As suggested by Knud Larsen in comments, I did a re-installation of gcc and nothing changed. And, it appears the ‘-fuse-linker-plugin’ isn't even rquired these days, Great! But, there's no flag calling for its use, so it seems to be automatic; how do I turn this thing off?!
I also meet this question when install something with cargo.
note: cc: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not found
compilation terminated.
Finally, I found the reason. I created the hard link cc of gcc by mistake. It should have been a soft link. It will be fine after changing it.
I'm cross-compiling ecasound, which goes well up to the point that all binaries get compiled, but fails during (at the end of?) the installation phase.
The thing is, I don't see any error message or anything, so I'm left guessing here:
ecasound: installs files in /home/buildroot/buildroot-2018.02-rc2/output/target//home/buildroot/buildroot-2018.02-rc2/output
make[1]: *** [/home/buildroot/buildroot-2018.02-rc2/output/build/ecasound-2.9.1/.stamp_target_installed] Error 1
make: *** [_all] Error 2
Full output: https://pastebin.com/ca6FJebB (hope this contains enough details)
Presumably the ecasound 'make install' returns (silently?) with an error. We don't have an ecasound package in upstream Buildroot, so it is hard to know what you are doing, but the install location (../output/target/home/buildroot/..) certainly looks wrong.
It did work after first doing a complete build, followed by ecasound seperately, indicating it was missing dependencies. Turned out the missing piece here was: BR2_PACKAGE_PYTHON_CURSES.
In case anyone wants to build ecasound for buildroot, a working package is available in my github account.. Not sure if it's clean code/by the book, but it works..
The problem is your install path somehow duplicated itself
/home/buildroot/.../target//home/buildroot/...
I have seen this several times too, and havent really found a way to fix it except to make clean & make again
I am working on a project with the Beaglebone Black and ran into an issue. As part of my project, I would like to use OpenBTS to communicate over the GSM network. However, because the Beaglebone is ARM based, the Transceiver52M that ships with OpenBTS is unusable. Therefore, I need to install an ARM friendly transceiver. The transceiver that I think will do best is Osmo-Trx.
I followed the instructions on their website:
http://openbsc.osmocom.org/trac/wiki/OsmoTRX
However, when it came to making the project, got an error and am really stuck. When I do the command "make" after "./configure --with-neon", I get the error:
make: ***No rule to make target '/Makefile.common', needed by 'Makefile.in'. Stop.
Would anyone be able to help me fix this. I've search around and can't find any applicable answers. I would really appreciate it. Thank you so much in advance!
P.S. All the source code for the OsmoTRX can be found at: https://github.com/osmocom/osmo-trx
A missing Makefile is often caused by a missed/failed step in the autotools process.
My suspcion is that you either forgot to run autoreconf -i or it wasn't successfull. Try
cd osmo-trx
git clean -xdf ##Attention: clean slate afterwards!
autoreconf -i ##make sure it reports success
./configure --with-neon ## make sure it reports success
make ## make sure it reports success
sudo make install
So, I feel like my xcode/gcc/however they are supposed to work together has been broken for a while. Trying to download various technologies (most recently redis) has always ended in sadness. When I tried to make the redis I get
-bash-3.2$ make
cd src && make all
LINK redis-server
/bin/sh: gcc-4.6: command not found
make[1]: *** [redis-server] Error 127
make: *** [all] Error 2
This is the kind of error I've been gettng forever. For reference, I'm running Mac 10.7.5, my latest xcode is 4.6 and my latest gcc is 4.2. Any ideas on how I can make this work? I'd rather not upgrade my Mac OS if possible. Thanks!
I honestly don't know if this is the right way to fix this, but this issue became so problematic for me that I was willing to try anything. I noticed that I definitely had a
/usr/bin/gcc
file. And I notice that my system couldn't find the /gcc-4.6.
So.... I just did one of these numbers
sudo cp /usr/bin/gcc /usr/bin/gcc-4.6
and voila. It works now. Now I can do it all, including essential tasks like compiling any C code. So, hopefully this helps someone out.
I'm trying to build a package from source. The ./configure and make steps work out, but sudo make install or sudo checkinstall results in an error:
As we can see drbd is listed twice in the /usr/bin/install -c line.
The problem is I don't really know how to go about this. As expected, this list of files (ha resource agents) is not present in any of the Makefiles or install-sh, but generated somehow on the go.
Any ideas of where to look for or how to remove duplicate entry from this list? Thank you.
Actually I was mistaken and the above list was present in one of Makefile.am files. Here is the post that helped me out:
This issue is caused because for those earlier versions we incorrectly
had those specified files listed twice in the Makefile.am and with the
newer Automake versions this causes the errors you received.
p.s. Sorry, it was a haste to ask the question. Let this thread be for reference in that case.