Hello Im trying to install GnuCOBOL
in part of configuration I got that message
configure: error: no acceptable ld found in $PATH
if someone can help plz, thank u.
Moving a comment to an answer, for completeness.
You'll need to use Cygwin setup.exe to install binutils, make, gcc, gmp, libgmp-devel, ncurses, libncurses-devel, libdb, libdb-devel, possibly others in the development package group.
Related
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
Trying to install fftw to use GADGET2, and after running the following command:
./configure --enable-mpi --enable-type-prefix --enable-float
I get the message:
checking for mpicc... mpicc
checking for MPI_Init... no
checking for MPI_Init in -lmpi... no
checking for MPI_Init in -lmpich... no
configure: error: couldn't find mpi library for --enable-mpi
Now I have installed openMPI already, so it seems to be the case that it just can't find it. There was a similar question posted a while ago with different mpi software. I think the problem is that my openMPI and other compilers might be in different folders? This brings me to a more general question (I have tried googling this but can't find anything that explains it well):
If I extract a tar and use ./configure without any prefix, where will the program install to? And is this is an issue that my openMPI has for some reason installed to a different place?
Thanks!
edit: found a solution for this from this question, where just running
sudo ldconfig
seemed to fix it and now it compiles fine.
I ran up into this glitch today, I am cross compiling many libraries for my linux system, and all except this zlib-1.2.8 works well.
My configure command is:
CFLAGS=-I/home/user/openwrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2/include/
LDFLAGS=-L/home/user/openwrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2/lib/
./configure --build=x86_64-unknown-linux-gnu --host=powerpc-openwrt-linux-uclibcspe
--prefix=/home/user/openwrt/openwrt/staging_dir/target-powerpc_8540_uClibc-0.9.33.2
The --build=x86_64-unknown-linux-gnu worked for all libraries, except this one.
THe error:
unknown option: --build=x86_64-unknown-linux-gnu
./configuer aborting
What is wrong? Please suggest.
It's because the configure script is not the usual one, but written especially for zlib, so the usual assumptions don't apply.
What you need for the --build=x86_64-unknown-linux-gnu is --arches="-arch x86_64"
I don't think that you can cross-compile with the resulting Makefile without some tweaks (to CFLAGS probably).
I have a program that is configured with a configure.ac file that crashes with some generic errors if libtool is not installed (unix).
How would I add a "check" for libtool that will provide a description, eg "libtool is not installed so the install failed" or something like that? I've never delved into this type of code before so have no idea
Thanks
use PKG_CHECK_MODULES to ensure libtool is installed.
Here is the documentation for the macro: https://autotools.io/pkgconfig/pkg_check_modules.html
I am trying to compile the openlase library from www.marcansoft.com and have been running into problems with CMake. CMake is returning an error stating that it cannot find Curses, and after a lot of looking I am still stumped as to what the issue is. I have checked that I have the various ncurses packages installed but still the error persists. Im not very familiar with CMake but I was able to resolve other dependency issues that arose before this one. The following is the output in terminal.
tom#SILVER:~/dev/openlase$ cmake ./
-- Found JACK
CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE):
Could NOT find Curses (missing: CURSES_LIBRARY CURSES_INCLUDE_PATH)
Call Stack (most recent call first):
/usr/share/cmake-2.8/Modules/FindCurses.cmake:159 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
examples/27c3_slides/CMakeLists.txt:3 (find_package)
-- Configuring incomplete, errors occurred!
Any help would be greatly appreciated.
Tom
Here is what fixed my problems on Ubuntu 12.04 x86_64 (64 bit) (Thanks syslogic )
For whatever reason (1:00 am maybe?) setting CURSES_USE_NCURSES TRUE didn't seem to work. So I went with a hack job.
Verified it's installed:
$ sudo apt-get install libncurses5-dev
You will see something to the effect: libncurses5-dev is already the newest version.
So find the library and include.
$ locate libncurses.so
Note location, mine: /usr/lib/x86_64-linux-gnu/libncurses.so
$ locate curses.h
Note location again, mine:
/usr/include
In: <cmake source dir>/Modules/FindCurses.cmake
add at the top, right after the comments
set( CMAKE_INCLUDE_PATH "/usr/include")
set( CMAKE_LIBRARY_PATH "/usr/lib/x86_64-linux-gnu/libncurses.so")
then rinse repeat the build process
./bootstrap
make
sudo make install
ccmake should now be installed.
Your pal,
Another way to fix it is to add these 2 lines to FindCurses.cmake (on top):
set(CURSES_LIBRARY "/opt/lib/libncurses.so")
set(CURSES_INCLUDE_PATH "/opt/include")
Temporarily set CURSES_USE_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
Do you have the corresponding -dev package installed too? On Ubuntu (and probably anything derived from Debian) it is libncurses5-dev. Other systems may use -devel or similar tags.
The compiler is looking for the library headers, and those aren't provided by the standard package. (The headers aren't needed at runtime, only when compiling software, so they make it easy to remove extra useless stuff for systems that aren't going to be doing any software compiling.)
The openlase wiki was not displaying all of the needed packages. Check there wiki pages on github for updated instructions. For curses the missing package was libncurses5-dev sudo apt-get install libncurses5-dev
Temporarily set CURSES_NEED_NCURSES to TRUE to force the use of NCURSES, rather than letting CMake try to find CURSES.
set(CURSES_NEED_NCURSES TRUE)
CURSES_USE_NCURSES is used by FindCurses.cmake internally, so setting that won't help.