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
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 am trying to build Linux for my Raspberry Pi 3.
When I do make, I get the below error.
make[2]: /home/rohit/workplace/rp/buildroot/output/host/usr/bin/arm-buildroot-linux-uclibcgnueabihf-gcc: Command not found
A little background will help. I am following this link . To summarize this is what I ran.
make raspberrypi3_defconfig
make linux-menuconfig
make
From the error I get that the cross gcc is not available at the path as it should be. But I am not sure what I am missing.
The complete log of the make is pasted here. The output/host/usr/bin folder also doesn't contain arm-buildroot-linux-uclibcgnueabihf-gcc, though it does contain arm-buildroot-linux-uclibcgnueabi-gcc. I have pasted the contents of the folder here.
Please help.
i was having this problem and after a make clean the problem was solved. I think the error was because different toolchains used in different builds. The manual says that is one of the cases that you have to do a make clean
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
I am now trying to install mingw for a couple of hours, however I keep on getting the following error message:
"install: gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
installing gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
mingw-get-gui: * ERROR * unexpected end of archive reading header record"
and cannot find any solution to my problem. I tried to reinstall 7zip, because I thought it may caused from that. I am trying to install gcc on a 32-bit Windows 7. I would be really happy for any suggestions.
Bye!
Even though this is an old question, I will post an answer, in case other users come across this again.
I encountered the same problem:
at first I did not notice that something went wrong with the installation/upgrade itself, because the graphical update manager showed a line like "everything went successful" ...
if I had bothered to look into the log details, I would have seen the error messesage mingw-get-gui: * ERROR * unexpected end of archive reading header record and immediately known, that something went wrong (its really misleading, to show a dialog saying that a task was completed successfully when there were errors!).
But pertaining to your problem (or at least this was, what caused mine):
Cause
most likely something went wrong, when the mentioned archive file was downloaded. Unfortunately, mingw-get seems to ignore download errors and continues as if nothing went wrong... thus the error message archive header record is invalid, because it is not really an archive file, but a text file containing the HTML error message.
To complicate things further, mingw-get caches these files and when you try to re-install the packages it uses these invalid, cached files.
Solution
One way of fixing this, would be to delete the cached files and then re-install the package.
The cached files should be at
<mingw directory>\var\cache\mingw-get\packages
e.g.
C:\MinGW\var\cache\mingw-get\packages
Side Note: if you "lost" the error message like me, and don't know, for which packages there was an error, you can search the cache directory for files which contain the HTML error message, e.g. a search term like <html> should work; also these files are quite small, but there may also be other valid packages with small file size to this is no unambiguous criterion
If you continue to get error messages * ERROR * unexpected end of archive reading header record with the mingw-get tool you could also try to download the file manually and place it in the folder for the cached packages.
For re-installing the packages you could use the graphical interface of mingw-get (e.g. remove and then install the package) or, for example the command line version
mingw-get --reinstall install <package name>
for mingw packages the <package name> is usually just the prefix of the file name (before the first version number), e.g. for
libiconv-1.14-3-mingw32-dev.tar.lzma
the package name would be libiconv. For msys packages the package name usually has the prefix msys-, e.g. something like msys-libopts
(you should be able to see if it's a mingw or a msys package by looking at the part of the file name that comes after the first version number, e.g. for libiconv-1.14-3-mingw32-dev.tar.lzma: ...3-mingw32-de...)
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.