I need to install CUnit on Windows. I already had a CUnit folder with headers, but it was in Linux, and i don't have the lib for windows. So i downloaded CUnit-2.1.3 and tried to install it following the given steps, using mingw64. But it said that configure is unrecognized. So:
1) I had to install MSYS2, because i didn't found any way to get the needed autotools on Mingw64 alone.
2) i have no idea how to link my MSYS with my Mingw64 build (but honestly i don't really care. I'm just going to install CUnit and then forget MSYS2 and continue with Mingw64)
3) After the MSYS updates, ./configure said No such file or directory
There was a tip here: How to install CUnit on Windows
however the answer didn't work for me. make is giving back a lot of abnormal error. But then i found this topic : Building CUnit on Windows and thought it was my answer. Nearly.
4) Libtoolize was unrecognized, but i only had to find which package it was and install it. Now it says that:
$ libtoolize
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: You should add the contents of the following files to 'aclocal.m4':
libtoolize: '/usr/share/aclocal/ltversion.m4'
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.in,
libtoolize: and rerunning libtoolize and aclocal.
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
I've made all the changes except for the last one, since Makefile.am doesn't ahve any ACLOCAL_AMFLAGS, only a RPM_FLAG.
5) automake is not better:
$ automake --add-missing
bash: $'\302\203automake' : command not found
pacman -S automake
solve dependencies
search for conflicts
Paquets (16) automake1.10-1.10.3-3 automake1.11-1.11.6-3
automake1.12-1.12.6-3 automake1.13-1.13.4-4
automake1.14-1.14.1-3 automake1.15-1.15.1-1
automake1.16-1.16.1-1 automake1.6-1.6.3-2 automake1.7-1.7.9-2
automake1.8-1.8.5-3 automake1.9-1.9.6-2 db-5.3.28-2
gdbm-1.18.1-2 libgdbm-1.18.1-2 perl-5.28.2-1
automake-wrapper-11-1
i installed everything but it still said "command not found"
And i'm stuck here. Of course i'm making that in MSYS2 shell, not in MinGW64. they're still separate and i didn't installed anything in MSYS2 except for the first updates and then what i said here.
Any idea?
EDIT: following HolyBlackCat comment, i installed CUnit through MSYS. However, now when i try to launch the tests (with MinGW64 shell), i get an abnormal program termination with make70642.sh: fork failed: no error[1].
I've try to merge my MinGW64 folder with the one downloaded by MSYS, but didn't get better results.
Do you need to build Cunit from source or is installing an existing binary sufficient? In the latter case, open a Mingw-w64 shell and run the following command:
pacman -S mingw-w64-x86_64-cunit
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.
I have a problem using Paho MQTT client in C.
I downloaded the pre built binaries for my system (Windows 10 64) from their projects page. I unpacked the zip file to a folder in the documents folder, where I also created a .c file with the example at the bottom of the Paho product page. My editor is atom and my compiler is gcc.
When I tried to compile it in Atom, I got this error:
undefined reference to MQTTClient_create'
So I went searching and found plenty of topics, but I still couldn't figure out, how to resolve this issue. From this stackoverflow topic I gather that it's a linker problem and that I need to link the files during compile, so here's what I tried:
gcc MQTT.c -L "C:\Users\Pete\Documents\MQTT on C\Examples\Paho\lib" -l paho-mqtt3c
Which still gives me the same undefined reference error. When I try to link to the dll of the same name, the compiler does not find the file.
Can anyone point me in the right direction, please?
Any help is appreciated!
I'd be interested to know if you have registered the Paho MQTT dll in Windows?
You should have paho-mqtt3c.dll as part of the download.
I don't know if this will work for you, but I have the same issue (undefined reference to MQTTClient_create)...
Copy the dll file into c:/windows/system32
Run CMD Prompt as Administrator and type:
regsvr32 i/ paho-mqtt3c.dll
Worth a try.
The problem was that I was compiling the program with the 32-bit gcc compiler for the 64-bit library. Installing and using MinGW64 worked.
I had the same issue in OS X. This is how I resolved it
I compiled the paho-mqtt library in Linux/EC2 instance.
Installed all the dependencies:
sudo yum install install build-essential gcc make cmake cmake-gui cmake-curses-gui
sudo yum install cmake
sudo yum install doxygen graphviz
cmake -DPAHO_WITH_SSL=TRUE -DPAHO_BUILD_DOCUMENTATION=FALSE -DPAHO_BUILD_STATIC=TRUE -DPAHO_BUILD_SHARED=FALSE -DPAHO_MQTT_C_PATH=../paho.mqtt.c/ -DPAHO_MQTT_C_LIB=../paho.mqtt.c/src/libpaho.mqtt3as-static.a
make
make html
make install
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/ec2-user/paho.mqtt.c/src
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH
sudo ldconfig
gcc test1.c -o test1 -lpaho-mqtt3c
Compiled successfully..
./test1
This solution works for OS X as well. Replace step 2 with
brew install cmake doxygen openssl-devel
hi im not sure what im doing and
basically i tried to get ghc and haskell-platform on to my mac via homebrew
however for reasons that i don't understand, ghc doesn't work hence neither does haskell-platform
according to brew doctor:
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/fuse.pc
its-fatbass:~ jellynom$ brew doctor
Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected .pc files:
/usr/local/lib/pkgconfig/fuse.pc
but according to someone this can be ignore???
also i cannot seem to find the file to delete it (if i should delete it)
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/ghc-7.6.3.mo
######################################################################## 100.0%
==> Pouring ghc-7.6.3.mountain_lion.bottle.1.tar.gz
==> Caveats
This brew is for GHC only; you might also be interested in haskell-platform.
==> Summary
/usr/local/Cellar/ghc/7.6.3: 5286 files, 776M
its-fatbass:~ jellynom$ brew install haskell-platform
==> Downloading http://lambda.haskell.org/platform/download/2013.2.0.0/haskell-pl
Already downloaded: /Library/Caches/Homebrew/haskell-platform-2013.2.0.0.tar.gz
==> ./configure --prefix=/usr/local/Cellar/haskell-platform/2013.2.0.0
configure: error: Your installation of ghc does not appear to work.
It cannot compile a simple program (see config.log for the details).
If you installed ghc from a generic binary tarball then it is worth
checking that you have the 'gmp' C library and header files installed.
(On Debian-based systems this package is called libgmp3-dev.)
READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting
These open issues may also help:
https://github.com/mxcl/homebrew/issues/20956
i don't know how to check for the gmp c library and header files
and the link they recommended is completely over my head too; something about hscolor missing.
Does this mean i have other things i should have installed prior to installing ghc??? (i have nothing else installed via homebrew other than ghc and haskell-platform)
if so, what should i have installed??
While building gcc, I get this error:
In file included from /usr/include/bits/errno.h:25,
from /usr/include/errno.h:36,
from ../.././gcc/tsystem.h:96,
from ../.././gcc/crtstuff.c:68:
/usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
make[2]: *** [crtbegin.o] Error 1
make[2]: Leaving directory `/opt/gcc-4.1.2/host-x86_64-unknown-linux-gnu/gcc'
I am building gcc 4.1 from source. I think I have to install build-essential. However installing that package in ubuntu 12.04 will automatically download and install gcc 4.6 and I don't want that.
Is there any other way?
I think the package you want is linux-libc-dev . I encountered this when building 32-on-64; so I needed linux-libc-dev:i386 .
This worked for me:
ln -s /usr/include/asm-generic /usr/include/asm
This worked for me:
sudo ln -s /usr/include/asm-generic /usr/include/asm
The reason being that what GCC expects to be called /usr/include/asm is renamed to /usr/include/asm-generic in some distros.
This fixed it for me.
sudo apt-get install linux-libc-dev:i386
This solved it for me on Debian 10, even though I was compiling with an LLVM-based compiler:
sudo apt install gcc-multilib
/usr/include/asm/errno.h is part of the linux headers. I can't speak directly to Ubuntu 12.04, but in general you can download the linux sources as a package for your distro and it shouldn't require you to download/install gcc. Failing that, you can manually download the linux headers for the version of your kernel (uname -a) and use an include directive to CFLAGS to specify the directory to look for those.
Edit: sudo apt-get install linux-headers-generic may work for you.
You are missing part of the development packages. I don't know Ubuntu, but you should be able to ask it's package management system to install the package containing /usr/include/asm/errno.h.
Do not copy some file with a similar name from somewhere on your system (or, even worse, from somewhere else). Missing files might mean that some package is damaged; again, ask your package manager to check everything and (re)install missing/broken pieces.
Unless you are running some LTS release, upgrade. Your Ubuntu is some 2 years old, i.e., ancient.
While we are at this, why on this beautiful planet are you building such an ancient compiler? Current GCC is just released 4.9.0, anything before 4.7 is ancient history, not longer supported.
On Ubuntu 16.04 x86_64 you could try this:
ln -s /usr/include/x86_64-linux-gnu/asm /usr/include/asm
This works on my server.
If you want to use errno.h that is in the asm file, simply go to /usr/(ctrl + l, type /usr/) and then search for errno.h and errno-base.h. Once you did find them, copy the code in these two files, and place them in your include folder. And be careful, in "errno.h" the file includes "errno-base.h" as:
#include <asm-generic/errno-base.h>
Either create a directory with the same name above or change the code above to something different which is suitable for you to use.
If you can find:
usr/include/asm-generic/errno.h
by executing:
find /usr/include -name errno.h
then try to execute:
cp --archive /usr/include/asm-generic /usr/include/asm
It may fix that problem.
I had this issue while compiling Asterisk 1.8.24.0 and solved it with:
mkdir /usr/include/asm-generic
cp /usr/include/asm/errno-base.h /usr/include/asm-generic/
Don't know if it is the "right way" but i've read the comments above and that gave me the idea... and it worked :)
When running:
sudo /sbin/ldconfig
the following error appears:
/sbin/ldconfig: /usr/local/lib/ is not a symbolic link
When I run the file command, the below appears:
file /usr/local/lib/
/usr/local/lib/: directory
Inside /usr/local/lib/ there are three libraries that I use. I'll call them here as lib1, lib2 and lib3.
Now, when I do an ldd on my binary it results:
lib1.so => not found
lib2.so => not found
lib3.so => /usr/local/lib/lib3.so (0x00216000)
But all of them are in the same folder as /usr/local/lib/{lib1,lib2,lib3}.so.
Every time I run ldconfig, the same error appears:
/usr/local/lib/ is not a symbolic link
I thought /usr/local/lib should be declared twice in /etc/ld.conf.d/*.conf, but not:
sudo egrep '\/usr\/local' /etc/ld.so.conf.d/*
projectA.conf.old:/usr/local/projectA/lib
local.conf:/usr/local/lib
ld.so.conf only includes /etc/ld.so.conf.d/*.conf, so this *.old isn't processed, and it refers to /usr/local/projectA/lib.
After a time trying I deleted all lib1 and lib2 (at some point I tested it on binary's folder), the same error occurs.
I ran into this issue with the Oracle 11R2 client. Not sure if the Oracle installer did this or someone did it here before I arrived. It was not 64-bit vs 32-bit, all was 64-bit.
The error was that libexpat.so.1 was not a symbolic link.
It turned out that there were two identical files, libexpat.so.1.5.2 and libexpat.so.1. Removing the offending file and making it a symlink to the 1.5.2 version caused the error to go away.
Makes sense that you'd want the well-known name to be a symlink to the current version. If you do this, it's less likely that you'll end up with a stale library.
I simply ran the command below:
export LD_LIBRARY_PATH=/usr/lib/
Now it is working fine.
Solved, at least at the point of the question.
I searched in the web before asking, and there were no conclusive solution, the reason why this error is: lib1.so and lib2.so are not OK, very probably where not compiled for a 64 bit PC, but for a 32 bits machine otherwise lib3.so is a 64 bits lib. At least that is my hypothesis.
VERY unfortunately ldconfig doesn't give a clean error message informing that it could not load the library, it only pumps:
ldconfig: /folder_where_the_wicked_lib_is/ is not a symbolic link
I solved this when I removed the libs not found by ldd over the binary. Now it's easier that I know where lies the problem.
My ld version:
GNU ld version 2.20.51, and I don't know if a most recent version has a better message for its users.
Thanks.
You need to include the path of the libraries inside /etc/ld.so.conf, and rerun ldconfig to upate the list
Other possibility is to include in the env variable LD_LIBRARY_PATH the path to your library, and rerun the executable.
check the symbolic links if they point to a valid library ...
You can add the path directly in /etc/ld.so.conf, without include...
run ldconfig -p to see whether your library is well included in the cache.
I have also faced the same issue,
The solution for it is :
the file for which you are getting the error is probably a duplicated file of the actual file with another version. So just the removal of a particular file on which errors are thrown can resolve the issue.
simple run in shell : sudo apt-get install --reinstall libexpat1
got same problem with libxcb - solved in this way - very fast :)