I'm working on an application that needs to support SCTP. Upon building a testing tool (Seagull) from source I cannot seem to find what the issue is. What is this flag (-lsctpsocket)? Is it a library? Where do I get it from?
Heres the command that the .mk file runes:
g++ -fPIC -shared /some_files.o -L./ext-1.8.3/lib -lsctplib -lsctpsocket -o /some_path/libtrans_extsctp.so```
Related
I'm creating a game in c++ with the Panda3D framework on Ubuntu. All of the Panda3D shared libraries are in /usr/lib/panda3d and all of the headers are in /usr/include/panda3d. I'm compiling with SCons, but I've tried it with gcc and it's the same, so here are the commands:
g++ -o src/main.o -c -fPIC -O2 -std=gnu++11 -I/usr/include/python2.7 -I/usr/include/panda3d -Iinclude src/main.cpp
g++ -o Test src/main.o -L/usr/lib/panda3d -lp3framework -lpanda -lpandafx -lpandaexpress -lpandabullet -lp3dtoolconfig -lp3dtool -lp3direct -lpthread
And here is the error I get when I run the executable:
./Test: error while loading shared libraries: libp3framework.so.1.11: cannot open shared object file: No such file or directory
There isn't much in the code, just initializing a Panda3D window, so I doubt that's the culprit.
As I said before, the libraries are in /usr/lib/panda3d, I've checked about a million times now and it's driving me crazy. I can't think of a single reason why I would get this error. Any help is appreciated :)
Edit:
I was looking through my files and there's a panda3d.conf file in /etc/ld.so.conf.d with one line: /usr/local/lib/x86_64-linux-gnu/panda3d. Does this have anything to do with it?
Edit #2:
I used the path in the above edit as the library path and got the same results, unfortunately.
I can't think of a single reason why I would get this error.
The reason is very simple: the dynamic loader hasn't been told to look in /usr/lib/panda3d for shared libraries, and so doesn't.
You can run your program with:
LD_DEBUG=files,libs ./Test
and observe which directories the loader is searching.
panda3d.conf ... with one line: /usr/local/lib/x86_64-linux-gnu/panda3d
That is the wrong directory (or at least not the one where your libraries are).
One way to fix this is to correct the above path to /usr/lib/panda3d and run sudo ldconfig.
Another way is to add -Wl,-rpath=/usr/lib/panda3d to your link line.
I try to migrate the old Pro*C program from HP to AIX, after changed some setting, I can make the binary file but fail to execute. Seems I now facing wrong library used (lib32/libclntsh.a).
Here is the error
0509-036 Cannot load program PROGNAME because of the following errors:
0509-150 Dependent module SOMEPATH/lib32/libclntsh.a(shr.o) could not be loaded.
0509-103 The module has an invalid magic number.
I build the program by setting object mode to 64
export OBJECT_MODE=64
Here is the full image when I make the binary
/PATHA/bin/oraxlc -O3 -q64 -DSS_64BIT_SERVER -I. -c MYPROG.c "MYPROG.c", line 2051.25: 1506-342 (W) "/*" detected in comment.
/PATHA/bin/oraxlc -o GLMJLUSB GLMJLUSB.o -L/PATHA/lib/ -lclntsh -lld -lm `cat /PATHA/lib/sysliblist` -lm -lc_r -lpthreads +DD64
/PATHB/bin/.orig/xlc: 1501-228 (W) input file +DD64 not found
Is there any way I can specify not to use the problem library, and use the 64bit version instead?
I don't know much about Pro*C and AIX, so any help is welcome. Thanks.
(Not really an answer yet, expect many edits).
Do you have a Makefile? If not, create one:
.SUFFIXES: .pc
PROC = ${ORACLE_HOME}/bin/proc
PROCFLAGS = code=ansi lines=yes
.pc.c:
${PROC} ${PROCFLAGS} $<
Keep improving it, until you can successfully precompile your *.pc files into *.c files.
Note: it is way easier, if you have GNU!make instead of prehistoric!make
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 :).
I'm trying to add a Swig interface on top of some already existing c++ code and I'm coming up with some errors with the -fPIC flag.
If I compile the already existing code without -fPIC and then create my Swig module using:
swig -python -c++ pyinterface.i
gcc -fPIC $(CFLAGS)-I $(PYTHON_INCLUDE_DIR) -c pyinterface_wrap.cxx
g++ -shared -o _pyinterface.so pyinterface_wrap.o -I $(PYTHON_INCLUDE_DIR) -L $(PYTHON_LIB_DIR) $(LPATH) $(LFLAGS) $(IPATH) $(LIBS)
Then I get a
warning: creating a DT_TEXTREL in object
However the module does seem to load and work in Python.
If I compile the already existing code with -fPIC and then do the same to create my module, when I try and import it into python:
import pyinterface
Then I get the error
ImportError: ./_pyinterface.so: undefined symbol: _Z7InitErfPA20_d
I can't tell why this would be. However, in the compliation of the base c++ files that I am trying to wrap, they do link to some standard libraries such as -llapack.
Could it be that I need to recompile these base libraries, like lapack, with -fPIC. That seems insane.
EDIT:
Actually sorry, I didn't realise, but with the -fPIC flag on I'm getting an error during compile:
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See http://bugs.gentoo.org/ for instructions.
I'll update this question if I figure out whats going on, but it seems like it might be unrelated to anything that the question actually raises.
I might be wrong regarding this reply.
Regarding the warning: creating a DT_TEXTREL in object
Even I was getting the same warning.
In my Makefile; I had done something like this
SRC= ../../some_folder/file.c 1.c 2.c
OBJS= $(SRC:.c=.o)
and while making the shared object, i was using this $(OBJS); whereas the "file.o" would be available at that location.
Make sure the object files that you are trying to access are available at that location.
My warning message vanished when i made the following changes
OBJS=file.o 1.o 2.o
There is a small project C++ (it has win32 code) that I need to build. It already has its Makefile. I was told to use MinGW. I have never used it before. I downloaded and installed the latest MinGW installer.
Then, I opened the MinGW shell and did make. The exe file was created. But when I try to run it I get libgcc_s_dw2-1.dll is missing! Why do I get this error? Shouldn't the exe be self-contained and run anywhere?
UPDATE
Here's more information, from the Makefile:
CC = g++
CCOPTIONS=-DWINDOWS -DFORCEINLINE -DMINGW -DSRTP_SUPPORT -D__EXPORT= -D_WIN32_WINNT=0x0501 -DNOMVS
setup.exe: setup.o common.o
$(CC) -ggdb -g -O0 -o $# setup.o common.o -mno-cygwin -mwindows -lwsock32 -lws2_32 -lwinmm -lgdi32 -lcomctl32 -lmapi32 -lVfw32
Whether or not the exe should be self-contained depends on how you built it. We need to see the commands that were executed, or post the makefile. But that DLL does not seem to be part of the current version of MinGW. Also, please clarify if you are actually doing this under cygwin, or if you added the tag by mistake.
Edit: A bit of googling seems like it has to do with the horrible "official" MinGW installation. Remove it, and download the Twilight Dragon build from http://tdm-gcc.tdragon.net and then rebuild completely. The "official" build is cr*p anyway - I don't know why anyone uses it.
If what you want to do is a stand alone application with MinGW, you should add -static to the linking options.
On a side note, if you're making a Win32 application, add the -mwindows option to the C++ compiler so it doesn't open a console together with your main window.