I need to import readline.h library to Windows. I have already tried to import folder with libraries here:
C:\Qt\Tools\mingw492_32\i686-w64-mingw32\include
It is a library with history.h, chardefs.h, keymaps.h, readline.h, etc..
But when i try to compile program like this:
if ((line= readline("my_prompt$ ")) == NULL)
exit(0);
add_history(line);
I recieve this message:
error: undefined reference to `add_history'
error: undefined reference to `impl__readline'
I really need it to run that library on my machine. Thanks you very much for helping!
You need to add the library path to your .pro file (not your Makefile - this will be rewritten everytime you change anything in your project configuration):
LIBS += -lreadline
Related
I'm new to using wolfSSL. I am trying to compile a set of codes using gcc.
gcc -o main main.c -lwolfssl
I encounter an error of main.c:(.text+0x47b): undefined reference to 'wolfSSL_get_peer_certificate'
collect2: error: ld returned 1 exit status upon entering the statement.
A snippet of the code shows the error location:
fprintf(stderr, "ERROR: failed to connect to wolfSSL\n");
return -1;
}
ret = certverify(CERT_FILE,verifyCert);
WOLFSSL_X509* webCert = wolfSSL_get_peer_certificate(ssl);
I have tried modifying the WOLFSSL_X509* webCert = wolfSSL_get_peer_certificate(ssl); command but it seems to be correct.
I am not too sure why this error is occuring. Can someone please help me with this?
I am using Kali Linux 2019.4 to compile this set of codes.
#wolfSSL_new,
It sounds like the application is failing to link the library so while the right headers are in place to locate the function definitions the final step to link the function is what is failing. Where is libwolfssl.so or libwolfssl.a located on your system? Is it in /usr/local/lib/libwolfssl.so or /usr/local/lib/libwolfssl.a?
(.a is a static library, .so is a shared object library it can be either or)
Once you located where it is try this build command instead (For the sake of an example I am going to assume it is in /usr/local/lib):
gcc main.c -o main -I/usr/local/include -L/usr/local/lib -lwolfssl
Let me know if that resolves the linker error you are seeing.
[UPDATE]
This was resolved by adding the configure setting --enable-opensslextra
[END UPDATE]
Regards,
K
System spec: Ubuntu 16.04, QtCreator 3.5.1 based on Qt5.5.1
In a C project I'm using dlopen and friends to load a shared library. The library uses some machinery from the main application.
Now, if I compile manually from terminal, everything works just fine. When I use QtCreator to build the project, calls from the library to the main application fail with the following error:
/Programming/C/emme_1/emme_1: symbol lookup error: /Programming/C/emme_1/modtest/test.so: undefined symbol: pop. Here pop is a function in the main application which is named emme_1. Please note that the error happens only if the library's function calls another function inside the main application. If the library's function is empty and is called from the application, it works.
This is my very simple .pro file:
QMAKE_CFLAGS += -DTRACE_ASM
QMAKE_CFLAGS += -rdynamic
QMAKE_CFLAGS += -ldl
LIBS += /usr/lib/x86_64-linux-gnu/libdl.so
I believe it contains all it's needed for the requested functionality, but maybe I'm missing something.
I believe it contains all it's needed for the requested functionality, but maybe I'm missing something.
You must be missing something since the setup doesn't work.
Note that -rdynamic and -ldl are linker flags, not compile flags. You'll want to move them to QMAKE_LFLAGS.
You can look at the final link command, and verify that -rdynamic is not in it. Once you manage to get it there, things will work again.
I'm trying to use glfw 2.7.8 with the Digital Mars D compiler version 2.0.
I followed the instructions from the example makefile on copying the .lib files to dm/lib folder, but I have not had success.
An example compile looks like this.
dmd main.d
The source of the file is:
import std.string;
import glfw;
int main()
{
glfwInit();
return 0;
}
The output I get is
main.d(2): Error: module glfw is in file 'glfw.d' which cannot be read
import path[0] = /usr/share/dmd/src/phobos
import path[1] = /usr/share/dmd/src/druntime/import
I have tried on both Windows 7 and Mac OSX 10.8.2, but I have not had success. Should I compile glfw.d as a lib and then drop it into my main directory?
I have also had _symbol not found messsages when I try to drop the .lib into the main directory and use the -L compiler flags linking to glfw.lib.
Any examples or help would be much appreciated.
you need to add -Ipath/to/glfw-x.x.x/support/d/imports to the compiler directive
you can also add the lib folder (with the def files) with the -L switch so the linker can map the symbols properly to the ones exposed in the dll
You need to pass glfw.d to the compiler:
dmd main.d glfw.d
assuming it is in the same directory as main.d.
(I'm on Windows.)
I try to build pysox. Therefore I built libsox (part of SoX). It is said, that pysox needs "libsox.so and libsox.a in your link path." When building libsox I got "libsox.a", "libsox-1.dll", "libsox.dll.a", "libsox.la", "libsox.lai" and many other strange files. When I placed "libsox.a" in my link path, the previously shown error disappeared. But now the build script has an error when it calls mingw32-gcc which says:
C:\Programme\MinGW\bin\mingw32-gcc.exe -shared -s build\temp.win32-2.7\Release\pysox\sox.o build\temp.win32-2.7\Release\pysox\sox.def -LC:\Programme\Python\libs -LC:\Programme\Python\PCbuild -lsox -lpython27 -lmsvcr90 -o build\lib.win32-2.7\pysox\sox.pyd
build\temp.win32-2.7\Release\pysox\sox.o:sox.c:(.text+0x3a96): undefined reference to `sox_get_encodings_info'
build\temp.win32-2.7\Release\pysox\sox.o:sox.c:(.text+0x5035): undefined reference to `sox_get_encodings_info'
build\temp.win32-2.7\Release\pysox\sox.o:sox.c:(.text+0x795d): undefined reference to `bcopy'
build\temp.win32-2.7\Release\pysox\sox.o:sox.c:(.text+0xa8b3): undefined reference to `bcopy'
collect2: ld returned 1 exit status
error: command 'mingw32-gcc' failed with exit status 1
The following attempts didn't work:
Placing "libsox-1.dll" in link path
Renaming it to "libsox.dll"
Renaming it to "libsox.so"
Placing all files generated along with "libsox.a" in link path
Do I really need an "so" file on Windows (how do I get it)? Or what has to be changed?
MinGW uses a static interface library for each dynamic link library (DLL). The libsox.dll.a library is the one you need at link time, i.e. that needs to be copied into the link path. libsox-1.dll is required in the PATH at runtime, but not needed at link time.
You don't need a .so file on Windows platforms. It seems that some symbols are missing from the static library libsox.a, or that a library is missing from the link line. Windows platforms do not allow unresolved symbols in DLLs, contrary to UNIX-like .so platforms. You might have to give the library containing sox_get_encodings_info and friends explicitly on the command line, remembering precedence on the linker line.
I'm trying to get SCons to make a shared library. One of the items going into the .so is a .a static lib.
I have a line like:
env_2.SharedLibrary('libstuff.so', \
Split("""stuff.cxx mylib/libMine.a""")
And upon running it, I get this error:
scons: *** Source file: mylib/libMine.a \
is static and is not compatible with shared target: libstuff.so
However, I know that a shared library can be made from the .a via a command like:
g++ -m32 -shared -o libstuff.so stuff.o mylib/libMine.a
Any ideas on getting this to work or any workarounds would be greatly appreciated.
Related question: How do I get scons to put an additional string -shared on the LINK command line for the Program() call? If I could do this, I think it would meet my needs.
Try to set env['STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME']=1 in your SConstruct.
This problem is not specific to scons. To build a shared library, you'll need objects that are compiled with position independent code (-fPIC). Your best bet is to make the shared library out of the source files compiled with the right options.
In SCons, you can define a list of targets that's used to build both libMine.a and libShared.so.
Update: for your second question, the SharedLibrary builder might do what you need:
SharedLibrary('foo', ['f1.c', 'f2.c', 'f3.c'])
If not, LINKFLAGS sets the flags passed to a link command.
I've the same problem under cygwin. I passed '-fPIC' options to gcc when building the objects and got the following warning:
warning: -fPIC ignored for target (all code is position independent)
I also passed '-shared' to the link command. And I finally got the error
"***.lib is static and is not compatible with shared target: myso.dll"
It seems scons doesn't allow to create so directly from obj or lib files, and one can either create the so from a list of sources files (using SharedLibrary()) or source file + 'LIBS' option like dummytaurus says. I'm curious about that.
env_2.SharedLibrary('libstuff.so', Split("""stuff.cxx"""), LIBS='libMine.a', LIBPATH='mylib')
This should work.
The problem is in the function SharedFlagChecker (Default.py), which checks only for an internal "shared" flag. The SCons documentation leads you to believe that it keeps the distinction between shared objects and static objects via the suffix (SHOBJSUFFIX), but not so. The fix is easy. In the file scons-local.../SCons/Default.py find the SharedFlagCheckerand edit:
def SharedFlagChecker(source, target, env):
same = env.subst('$STATIC_AND_SHARED_OBJECTS_ARE_THE_SAME')
if same == '0' or same == '' or same == 'False':
for src in source:
try:
shared = src.attributes.shared
except AttributeError:
# Replace this line: shared = None
shared = env.Dictionary()['SHOBJSUFFIX'] == src.suffix
if not shared:
raise SCons.Errors.UserError("Source file: ...")
Now objects made via the SharedObject builder will be linkable in a shared library.
The solution to resolve this issue have been used a 'SharedObject' as the following:
ASN1CObjectFile = envCProcesses.SharedObject(target = "OTCMsg.os",
source = "OTCMsg.c",
CFLAGS = envCProcesses["CFLAGS"] + ["-Wno-unused"])
and:
OTCLibSharedLibrary = envCProcesses.SharedLibrary(env["OTC_LIBPATH"] + "/libOTCLib" + env["SHLIBSUFFIX"],
ASN1CObjectFile +
[ASN1AllocatorSource,
"OTCLib.c"],
LIBPREFIX = "")
Best regards,