Compiling on Windows and Mac with Autotool - c++

I have a problem trying to use autotools for a simple contrived project, the task is simple, use Objective-C on Mac OSX, and C++ on Windows (mingw) - with some C glue in the middle.
The project is structured like so (minus all the automatically generated files):
./aclocal.m4
./configure
./configure.ac
./Makefile.am
./src/darwin/greet.m
./src/greet.h
./src/main.cpp
./src/Makefile.am
./src/mingw32/greet.cpp
The contents of the key files are here on github in a gist. (didn't want to spam here)
I'm using the following command between changes:
$ autoreconf -vis && ./configure && make
The error I receive is full output (here in another gist):
....
Making all in src
g++ -g -O2 -o greetings main.o
Undefined symbols:
"greet()", referenced from:
_main in main.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [greetings] Error 1
make: *** [all-recursive] Error 1
I'm very new to autotools, and have come a long way with the help of a couple of good people on IRC, but I think I'm making a conceptual mistake here, really hope there's a simple mistake I am making.
It was my understanding from the docs that EXTRA_progname_SOURCES should contain all possible files, and that the conditionals which are setup should work to select the correct ones.
Alarmingly, I don't think my makefiles are being remade, because even when I change the line in src/Makefile.am to include the sources explicitly for my platform (which is Max OS X Darwin, most of the time) -- the output remains completely the same.

I see that you're referring to greet.mm in the gist, but greet.m in the question. Automake does not appear to natively support Objective-C++ code. For Objective-C code, you need to have AC_PROG_OBJC in your configure.ac. If you really meant Objective-C++ code, you'll need to do this via a suffix rule.

g++ -g -O2 -o greetings main.o
This line tries to build greetings executable from main.o. If greet() function is defined in some other file, for example, greet.cpp, it should be:
++ -g -O2 -o greetings main.o greet.o
Possibly, this line from Makefile.am
greetings_SOURCES = main.cpp greet.h
should be something like this:
greetings_SOURCES = main.cpp greet.cpp
In Makefile.am you have:
if OS_DARWIN
greetings_SOURCES += darwin/greet.mm
endif
if OS_MINGW32
greetings_SOURCES += mingw32/greet.cpp
endif
This is the place which is not executed properly. You need to check it.

Related

How can I build on ubuntu something that was meant for FreeBSD?

I'm trying to build this: https://github.com/hselasky/hpsat_generate
this is their makefile:
PROG_CXX=hpsat_generate
PREFIX?=/usr/local
MAN=
SRCS= hpsat_generate.cpp
BINDIR?=${PREFIX}/bin
.if defined(HAVE_DEBUG)
CFLAGS+= -g -O0
.endif
CFLAGS+= -I${PREFIX}/include
LDFLAGS+= -L${PREFIX}/lib -lgmp -lgmpxx
.include <bsd.prog.mk>
using just make . results in
Makefile:7: *** missing separator. Stop.
so after some searching I found that I need to use FreeBSD make, so I tried:
bmake . hpsat_generate
which complains that mergesort is not declared, which is a FreeBSD function so I can only assume it doesn't really includes it.
I tried finding a way to make it run but I'm out of ideas..
The Makefile requires some changes for Linux (and NetBSD). The bsd.prog.mk implementation that comes with bmake on Linux is slightly off, and requires a workaround to link the program correctly, also, on Linux you need libbsd:
These issues are fixed by PR #1.
Instead of running the makefile just execute this:
g++ -o sat sat.cpp -lgmp -lgmpxx -l:libbsd.a
you may need to install the gmp and libbsd libraries

Quick Rundown on C++ libraries?

I am trying to troubleshoot a problem I have in using the library matplot++. I need someone to teach me how to fish here instead of giving me a fish, because I'm struggling to google search the right terms to solve my problem.
My folder structure is as follows
-music_vis
|-libs
|-3rd party
|-matplot
|-matplot.h
|-other_folders_for_matplot
|-wavs
|build.sh
|main.cpp
|thread_pool.hpp
build.sh is as follows right now:
g++ -Wall -lmatplot -I /$(pwd)/libs -g -o music_vis_cpp ./music_vis_main.cpp -lstdc++fs -std=c++17 -pthread
Everything 100% works in this shell script except for something within this section:
-lmatplot -I /$(pwd)/libs
For which I get the following error:
/usr/bin/ld: cannot find -lmatplot
collect2: error: ld returned 1 exit status
Is g++ spuriously looking in my /usr/bin/ for files? Shouldn't it be looking in $(pwd)/libs?
From what I have researched, I am also supposed to have .so files, but everything under the matplot folder is .cpp or .h files. Does this mean I installed the library incorrectly into my /lib/ folder? I cloned from github and simply copied into my /lib/ folder. Without the -lmatplot flag I get the following error:
Any thoughts, resources, guidance or guidelines on how to troubleshoot these problems in the future? Thanks friends.
I followed the instructions on the repo, but piggybacking off of Compiler not finding jpeg and png libraries , I added the following flag to the cmake. This created object files for me.
-DBUILD_SHARED_LIBS=ON
I was able to build a .so file by following the build instructions included in the matplot++ .md file, but supplying an extra flag -DBUILD_SHARED_LIBS=ON
From there, under the build folder, I found a .so file somewhere in the folder tree, moved that to my /lib/ directory, and ran the following shell script:
#!/bin/bash
g++ -I /$(pwd)/libs -L /$(pwd)/libs -Wall -g -o music_vis_cpp ./music_vis_main.cpp -lstdc++fs -std=c++17 -pthread -lmatplot
And this finally built my program. However it doesn't run because shared object file doesn't exist or something.
Edit: More steps to make the program run;
Create a folder on your filesystem you want to put your .so files into and then...
export LD_LIBRARY_PATH=/home/harrison/Documents/computer/cpp_packages/shared_object_lib/
I need to run this export line every time I restart my computer, so I just add it to my build script.
So the .so file is in two places, one necessary at build time and the other necessary at run time. My binaries can be run anywhere on my computer with this method.

Compiling an external library on Linux

Good Day Everyone,
N.B - This problem has been solved - I have provided my own solution in the answer section however the solution provided by Jonathan is much shorter. Nevertheless, this was the following question I originally posted:
I am basically trying to compile a serial library (for UART communication) on Linux however I am not really sure how to correctly compile (I have mentioned what I have done so far below), any suggestions would be highly valuable. I am using the serialib library - which is composed of 2 main files (serialib.h and serialib.cpp) , you may directly view the source code of these files here (scroll all the way to the bottom and view the files in new tabs): http://serialib.free.fr/html/classserialib.html
I transferred these files (serialib.h and serialib.cpp) to my BeagleBone Black micro-controller which is running Debian (Wheezy) , g++/gcc (Debian 4.6.3-14) 4.6.3. I wrote my own program (uart.cpp is my file name) to access the functions provided by this library, this is what I wrote:
#include <iostream>
#include "serialib.h"
#ifdef __linux__
#define DEVICE_PORT "/dev/ttyO1"
#endif
int main()
{
serialib LS;
return 0;
}
So as you can see I am trying to access the 'seriallib' class. serialib.h, serialib.cpp and uart.cpp are all in the home directory. I also manually added the iostream library in serialib.cpp as I did not see it being declared in the original source code.
Now I am really unsure of how to compile such external libraries but so far I tried the following steps:
g++ -c -Wall -Werror -fPIC serialib.c to convert to PIC which gives the following error:
distcc[3142] (dcc_parse_hosts) Warning: /home/debian/.distcc/zeroconf/hosts contained no hosts; can't distribute work
distcc[3142] (dcc_zeroconf_add_hosts) CRITICAL! failed to parse host file.
distcc[3142] (dcc_build_somewhere) Warning: failed to distribute, running locally instead
g++ serialib.cpp -L /home/debian/serialib.h which gives the following error:
/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o: In function _start':
(.text+0x30): undefined reference tomain'
collect2: ld returned 1 exit status
distcc[3210] ERROR: compile serialib.cpp on localhost failed
As of now I am still finding out how to compile this and if I manage to work this out then I'll post my solution here too. Once again any suggestion will be highly valuable. Thank you all :) .
g++ -c -Wall -Werror -fPIC serialib.c to convert to PIC which gives the following error:
The "error" is not an error, it's a warning, telling you that your distcc setup is broken, but that it compiled locally.
That command doesn't "convert to PIC", it compiles the file serialib.c and produces a compiled object file, serialib.o
g++ serialib.cpp -L /home/debian/serialib.h
This is just nonsense. It tries to build a program from serialib.cpp and use the directory /home/debian/serialib.h (which isn't a directory!) to find libraries.
You don't need to "compile a library" you can just compile both the source files and link them together into a program. Either:
g++ -c serialib.cpp
g++ -c uart.cpp
g++ serialib.o uart.o -o uart
Or all in one command:
g++ serialib.cpp uart.cpp -o uart
You should read An Introduction to GCC to understand the commands, not just enter bogus commands without understanding them.
I have found a solution to this problem, hope this helps for all the future readers with similar problems. I have my own source code uart.cpp (Given in the question) which I want to compile, the external library is serialib that contains two main files (serialib.h and serialib.cpp), you will want to replace the following commands with respect to the files you have
Step 1: Compiling with position independent code
g++ -c -Wall -Werror -fpic serialib.cpp
Step 2: Creating a shared library
g++ -shared -o libserialib.so serialib.o , here the library is libserialib.so.
Step 3: Linking your source code with library
g++ -L /home/debian -lserialib uart.cpp -o uart
g++ -L /home/debian -Wall -o test uart.cpp -lserialib
You may save the library at a different path and you may have a different name of course. Suppose you have a library called libabc.so at the directory /home/user/myDir then the commands will be like:
g++ -L /home/user/myDir -labc your_code.cpp -o your_code
g++ -L /home/user/myDir -Wall -o test your_code.cpp -labc
test is out own program, lserialib is actually looking for libserialib.so and not serialib.o as gcc/g++ assumes all libraries start with lib and end with .so or .a and you can see the same goes for labc as it will look for libabc.so thus it is important to make sure your library name begins with lib and ends with .so or .a
Step 4: Making library available at run time
Here we provide the path where the library is actually stored, I saved it in the directory /home/debian which is why my command looks like:
export LD_LIBRARY_PATH=/home/debian:$LD_LIBRARY_PATH
if your library is saved at /path/to/file then the command will look like:
export LD_LIBRARY_PATH=/path/to/file:$LD_LIBRARY_PATH
This is to help the loader find the shared library and to view this path: echo $LD_LIBRARY_PATH and to unset this: unset LD_LIBRARY_PATH
To execute the program type either ./test or ./uart and in case of any modification to the main source code (uart.cpp in this case) , simply repeat step 3. I found the following link very useful: http://www.cprogramming.com/tutorial/shared-libraries-linux-gcc.html . Thank you to all of you who took time to read this question and especially those who gave me suggestions. If anyone has more or better solutions, feel free to post them here to assist future readers :).

Cross compiling C++ project, Relocations in generic ELF (EM: 3)

I've been working on a c++ project for a while now, but would like to port it over to my arm processor. I already have all of my cross-compile tools (I'm using CodeSourcery) and thought I could just change my makefile to point to that compiler. It compiles fine using the default g++, but When try a make pointing to the cross-compiler I get relocation errors:
/home/oryan/CodeSourcery/bin/../lib/gcc/arm-none-linux-gnueabi/4.5.2/../../../../arm-none-linux-gnueabi/bin/ld: ServerSocket.o: Relocations in generic ELF (EM: 3)
ServerSocket.o: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make: *** [simple_server] Error 1
It seems like I don't have a proper link set up or it's pointing to a wrong location. I'm not that familiar with makefiles and am probably missing something obvious. The makefile I've been using is from http://tldp.org/LDP/LG/issue74/tougher.html with the client side removed:
# Makefile for the socket programming example
#
simple_server_objects = ServerSocket.o Socket.o simple_server_main.o
all : simple_server
simple_server: $(simple_server_objects)
/home/matt/CodeSourcery/bin/arm-none-linux-gnueabi-g++ -o simple_server $(simple_server_objects)
Socket: Socket.cpp
ServerSocket: ServerSocket.cpp
simple_server_main: simple_server_main.cpp
clean:
rm -f *.o simple_server
Right now I am manually compiling each file and it works great, but I'd like to further my understanding here.
Thanks!
The problem is you've set your makefile up to link with the new g++ but you haven't changed the compiler you're using to build the objects in the first place.
The easiest way to fix this is to set environment CXX to the next compiler, i.e.
export CXX=/home/matt/CodeSourcery/bin/arm-none-linux-gnueabi-g++
or just set it for a given make by adding CXX=... to the command line.
You'll need to make clean first but you'll then use the correct compiler for both the compile and link.
You could also specify a new how-to-compile-C++ files rule in your makefile to specify the new compiler but the environment variable is easier:
.cc.o:
/home/.../g++ $(CPPFLAGS) $(CXXFLAGS) -c
The problem is because of these three rules:
Socket: Socket.cpp
ServerSocket: ServerSocket.cpp
simple_server_main: simple_server_main.cpp
First of all, the left-hand side of the rule should be the object file I guess, so should have the .o suffix.
The second problem, and most likely the root of your problem, is that there is no command to compile the source files, which means that make will use the default compiler and not your cross-compiler.

ld can't link with a main executable

On OSX 10.6.4 with i686-apple-darwin10-g++-4.2.1 compiling using TextMate and a Makefile which in the first place has been made für a Linux and I am trying to translate for OSX.
When compiling a c++ project I get the "can't link with a main executable" error:
g++ -Wall -g -I ~/svnX-Repository/axp-Projekte/xrlfupa/trunk/src/ -I ~/svnX-Repository/boost_1_44_0 -I /opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -I /opt/local/var/macports/software/gsl/1.14_0/opt/local/include/ -o xrfLibTest xrfLibTest.o excitFunctions.o xrfFunctions.o filterFunctions.o detectorFunctions.o -L/opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -L/opt/local/var/macports/software/gsl/1.14_0/opt/local/lib/ -lm -lxrlTUB -lboost_serialization -lgsl -lgslcblas # Debug 1
ld: in /usr/local/lib/libxrlTUB.so, can't link with a main executable
collect2: ld returned 1 exit status
make: *** [prog] Error 1
The library that is mentioned (libxrlTUB.so) is in its place (/usr/local/lib/libxrlTUB.so) but, possibly that is where the problem came from, the libxrlTUB.so has been compiled by myself beforehand as well.
The compile process went through, it was generated by swig, though there was a warning:
g++ -arch x86_64 -m32 -g -fpic -I /usr/include/python2.6 -c PyXrl_wrap.cxx
In function 'void SWIG_Python_AddErrorMsg(const char*)':
warning: format not a string literal and no format arguments
which, as far as I could find out, shouldnt be a problem. (Or is it?)
Unfortunately this whole thing is part of a project from the university. Actually I am supposed to write an X-ray-analysis script in python, which would be fine, if... well if I wouldn't be expected to use the librarys that are meant to result from this c++ project.
(Afterwards they should be used via import in python.)
I am not really experienced with c++, neither with compiling on OSX systems. So far I have been bothering with scipting (python, bash, etc). So Maybe I am just missing something simple. Hopefully someone can give me an hint where I can continue reading in order to deal with the above "can't link with a main executable" error...
Thanx in advance,
Liam
The error message is telling you the problem—it is that /usr/local/lib/libxrlTUB.so is not a shared library; it's an executable. You can't link against an executable. Probably whatever build process you used for libxrlTUB.so didn't understand how to build shared libraries on the Mac (it's more suspect because .dylib is the correct extension to use.)
Take a look at Apple's documentation on compiling dynamic libraries. You can use file to make sure your output is of the correct type, for example:
% gcc -c foo.c
% gcc -dynamiclib foo.o -o foo.dylib
% file foo.dylib
foo.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Without -dynamiclib you end up with an executable, which may be the problem you've run into.