I came across the below line in the Apache-Axis2 log file.
[Sat Nov 14 12:16:08 2015] [error] ..\..\util\src\class_loader.c(167) Loading shared library ..//lib/axis2_http_sender.dll Failed. DLERROR IS DLL Load Error 126: The specified module could not be found.
On analyzing the class_loader.c file from line#156 to line#167 as given below:
dll_name = axutil_dll_desc_get_name(dll_desc, env);
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "Shared library to be loaded is %s",dll_name);
dl_handler = AXIS2_PLATFORM_LOADLIB(dll_name);
if (!dl_handler)
{
#ifndef WIN32
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "Loading shared library %s Failed. DLERROR IS %s",
dll_name, AXIS2_PLATFORM_LOADLIB_ERROR);
#else
axis2_char_t buff[AXUTIL_WIN32_ERROR_BUFSIZE];
axutil_win32_get_last_error(buff, AXUTIL_WIN32_ERROR_BUFSIZE);
AXIS2_LOG_ERROR(env->log, AXIS2_LOG_SI, "Loading shared library %s Failed. DLERROR IS %s",dll_name, buff);
I guess the problem is in the very first line - dll_name = axutil_dll_desc_get_name(dll_desc, env);. The value stored in dll_name is ..//lib/axis2_http_sender.dll. Though the axis2_http_sender.dll is present
in the lib directory which is relative to the executable, the linker fails to connect to it.
I have never seen file name syntax like below:
..//lib/axis2_http_sender.dll
I tested it in Windows Command line and it worked like :
../lib/axis2_http_sender.dll
What are the implication of using consecutive /s in a C
function like fopen()?
I did try few code samples.
Below is a piece of C code:
FILE *fp;
fopen_s(&fp,"C://tempfile.txt", "w");
fputs("Text content", fp);
fclose(fp);
The above code worked fine for me.
Cracked this one finally.
This CSDN blog post suggested that Axis2C Windows distribution depends on OpenSSL DLLs.
I listed the dll dependencies of axis2_apache_server.exe using the following command.
listdlls axis2_apache_server.exe
and the list showed that the two ssl dlls libeay32 and ssleay32 are required to run it. However, these two dlls were missing from the Axis2 Binary Distribution.
(I don't know why & I think it should have been included. Moreover there is no mention of this in Axis2 documentation.)
The above dlls are available in either Apache2 or OpenSSL installs the I added the path to these dlls to my PATH variable.
I ran the axis2_apache_server.exe and voila !!
Conclusion:Consecutive /s in the file path doesn't affect the linking at all.
Moral: One should check the dll dependencies of an exe file first and make sure that all the dlls are present when he ran into a dll load error.
Hard learned moral though!!
Related
I am using Windows to follow the Kotlin-Native libcurl example here https://kotlinlang.org/docs/tutorials/native/curl.html
Unfortunately, this has been a bigger challenge then I could have imagined. I have been learning how to compile C binaries on windows from source using tools such as CMake and have followed this tutorial to build libcurl on Windows: https://jonnyzzz.com/blog/2018/10/29/kn-libcurl-windows/
After quite a few days of trial and error with the .def file for cinterop on Windows, and using compilerOpts to point to my header file for curl in my built library, I have hit a brick wall.
I can't seem to get Gradle to recognize the dll file. Task ':linkDebugExecutableMingw' keeps failing. I have no idea where I am supposed to put the dll file. I have tried putting it in to the build output folder next to the exe, but it still fails to compile, with this error:
C:\Users\yous\.konan\dependencies\msys2-mingw-w64-x86_64-clang-llvm-lld-compiler_rt-8.0.1\bin\ld: C:\Users\yous\AppData\Local\Temp\konan_temp6326583690522756621\result.o:out:(.rdata$.refptr.knifunptr_sample35_curl_easy_strerror[.refptr.knifunptr_sample35_curl_easy_strerror]+0x0): undefined reference to `knifunptr_sample35_curl_easy_strerror'
And a similar list of header file errors, then the final message is:
e: C:\Users\yabde\.konan\dependencies\msys2-mingw-w64-x86_64-clang-llvm-lld-compiler_rt-8.0.1/bin/clang++ invocation reported errors
This is after I succesfully located the header files. I believe this is an issue with the dll file not being included.
Here is my relevant Gradle build script:
mingwX64("mingw") {
compilations.main {
cinterops {
libcurl {
// Def-file describing the native API.
// The default path is src/nativeInterop/cinterop/<interop-name>.def
defFile project.file("src/nativeInterop/cinterop/libcurl.def")
// Package to place the Kotlin API generated.
packageName 'libcurl'
// Options to be passed to compiler by cinterop tool.
compilerOpts '-Isrc\\nativeInterop\\cinterop\\libcurl-vc-x64-release-dll-ipv6-sspi-winssl\\include -o libcurl'
//linkerOpts '-Isrc\\nativeInterop\\cinterop\\libcurl-vc-x64-release-dll-ipv6-sspi-winssl\\bin'
// Directories for header search (an analogue of the -I<path> compiler option).
//includeDirs.allHeaders("path1", "path2")
// Additional directories to search headers listed in the 'headerFilter' def-file option.
// -headerFilterAdditionalSearchPrefix command line option analogue.
includeDirs.headerFilterOnly("src/nativeInterop/cinterop/libcurl-vc-x86-release-dll-ipv6-sspi-winssl/include")
// A shortcut for includeDirs.allHeaders.
//includeDirs("include/directory", "another/directory")
}
}
}
binaries {
executable {
// Change to specify fully qualified name of your application's entry point:
entryPoint = 'sample.main'
// Specify command-line arguments, if necessary:
//runTask?.args('-Lsrc/nativeInterop/cinterop/libcurl-vc-x86-release-dll-ipv6-sspi-winssl/bin')
runTask?.args('')
}
}
}
I believe this issue may be with linker options to locate the dll, but uncommenting the linkerOpts line does not help.
I think I have given up on Kotlin/Native and will be sticking to C for data-oriented native programming...
EDIT:
Also, note that any text commented out is things that I have attempted
Ok so, this is my def file:
headers = curl/curl.h
headerFilter = curl/*
compilerOpts.linux = -I/usr/include -I/usr/include/x86_64-linux-gnu
linkerOpts.osx = -L/opt/local/lib -L/usr/local/opt/curl/lib -lcurl
linkerOpts.linux = -L/usr/lib/x86_64-linux-gnu -lcurl
linkerOpts.mingw = -Llibcurl-vc-x86-release-dll-ipv6-sspi-winssl/lib
Ok so, this is my project structure:
I followed the same steps (jonyzzz blog). I created a Libcurl static example for Kotlin-Native. Support for gzip and SSL. Compile to standalone exe, no need for dll
https://github.com/carlosrafp/Libcurl-Kotlin-Native-standalone
I built the static libraries supplied on the repository with mingw64 (gzip and libcurl) and msys2/mingw (openssl)
I went through this question several times when looking for a solution for statically linking libcurl with my binary.
In the end, I ended up using WinInet for the HTTP communication on Windows. Linux and macOS binary still rely on ktor clients with libcurl.
See my example of how to use WinInet API with Kotlin MPP: https://github.com/localazy/kotlin-mpp-wininet
For a simple HTTP communication, WinInet API is good enough and the resulting binary is much smaller and in my case, it has no additional dependencies.
I previously made this question and got a light at the end of the tunnel by the response that I got. But now that I found the problem, I don't understand it. I don't have root priv. Whenever I run the program I get segmentation fault and a core file. When I analyse it with dbx I get this
reading symbolic information ...
Segmentation fault in QRspec_newFrame at line 546 in file "" ($t1)
couldn't read "qrspec.c"
How come he can't find qrspec.c if that file was included on the process of generating the lib? (I wasn't involved on that process so I have no idea if it went 100% but I gave the .tar with all the files). Also that file belongs to libqrencode.
Compiling:
xlc_r7 -g qrgen.c -lqrencode -L/usr/local/lib -I/usr/local/include
I'm starting to bealive it can't find the file because there is a .so symbolic link missing on the /usr/local/lib folder. Could that be it? (Only .a , .la and .so.3 in there)
I think my problem is similiar to this one but I can't install the lib again unless that is the real problem.
Machine: Unix AIX powerpc model: IBM,9117-MMB
xlc version: 12.01.0000.0000
I'm guessing you need to tell dbx where to find your source files
From man dbx
-I Directory
(Uppercase i) Includes directory specified by the Directory variable in the list of directories searched for source files. The default is to look for source files in the following directories:
* The directory the source file was located in when it was compiled. This directory is searched only if the compiler placed the source path in the object.
* The current directory.
* The directory where the program is currently located.
I found the problem... The installation of the lib generated problems and caused the symbolic links to exist as a simple file and the library just wasn't there...
This is the missing file "/usr/local/lib/libqrencode.so.3.4.4" which is the code itself... I was looking at the files and didn't notice it because there was a file called libqrencode.so.3.4 but this file was supose to be a symbolic link to libqrencode.so.3.4.4 since libqrencode.so.3.4.4 didn't exist, instead of the symbolic link failing, it created a empty file with that same name...
I'm trying to use the GnuTLS API on a window machine, sadly it will not work. I downloaded the latest precompiled version for Windows gnutls-3.3.9-w32.zip.
Each time I call a GnuTLS function, my program wont work probably. For testing there are only two lines of code:
printf ("hello");
gnutls_global_init();
it will build without errors but it won't print "hello", if I delete the second line it works. So there must be a mistake within the usage of GnuTLS.
I included the libgnutls-28.dll
gcc "-LC:GnuTLS\\gnutls-3.3.9-w32\\bin" -o Test.exe test.o -llibgnutls-28
Do I have to link the libgnutls.dll.a file somehow?
Do I have to link the libgnutls.dll.a file somehow?.
Yes. Linking libraries is required for building. But you said it is building okay... In support of what Marc B was saying, test to see whether your printf is working:
printf ("hello");
getchar(); // to stop execution before calling init
//Check the return of your init function
status = gnutls_global_init();//On success, GNUTLS_E_SUCCESS (zero) is returned,
For testing there are only two lines of code:
Add a few more to check status of your init function:
if(status < 0) //otherwise an error code is returned.
{
//handle error
}
Click gnutls_global_init for man page.
Another thing to check is where you have the .dll located.
Ensure it is visible to the executable at run-time. Put it in either in the .exe. directory, or in the $SYSTEM$ directory, for your system.
One gottcha for people is WoW64. The Windows system directory for 32 bit applications on Windows 7 (or 8) is c:\windows\sysWoW64\ (i.e. not c:\windows\system32). Ironically, the system directory for 64 bit apps is c:\windows\system32\ .
I was originally following this tutorial: http://www.opengl-tutorial.org/miscellaneous/building-your-own-c-application/
just after about half way down, from where it says "Adding a source file in a project"
I created from this my CMakeLists.txt file as so:
cmake_minimum_required (VERSION 2.6)
project (Cube_Project)
find_package(OpenGL REQUIRED)
add_executable(Cube
main.cpp
)
include_directories(
external/glfw-2.7.6/include/
external/glm-0.9.4.0/
external/glew-1.9.0/include/
.
)
set(ALL_LIBS
${OPENGL_LIBRARY}
GLFW_276
GLEW_190
)
target_link_libraries(Cube
${ALL_LIBS}
)
but when I generate the project, I get this error:
ld: library not found for -lGLFW_276
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Any ideas?
I think maybe I'm not using the right names in the set(....) section? My three libs are in a folder called external, which is the top level of the project (i.e. CMakeLists is also here).
I put a zip of the project if anyone wants to take a look at the folder layout of output XCode project structure: http://heather.sh/OpenGL_Project.zip
Thanks,
The library is not in the linker's library search path.
The target_link_libraries command is is very straightforward: It simply passes on all of its arguments to the linker without bothering whether any of those libraries actually exist.
In your case, the GLFW_276 library is missing (and possibly the GLEW_190 as well, since the error occurs before that one is being processed). Make sure the library is actually installed on your system and its filename actually matches the name you use here (eg. libGLFW_276.so).
Once you verify that you have the required file, you need to make sure that the linker is able to find it. If the file is not located in one of the standard directories, use either link_directories to add its location to the search path, or find_library to obtain the full path to the library file, which can then be given to target_link_libraries.
I am working on a project which requires me to download and use this. Inside the downloaded folder, when extracted I am presented with three things:
A folder called "include"
A folder called "src"
A file called "Makefile"
After some research, I found out that I have to navigate to the directory which contains these files, and just type in the command make.
It seemed to install the library in my system. So I tried a sample bit of code which should use the library:
csp_conn_t * conn;
csp_packet_t * packet;
csp_socket_t * socket = csp_socket(0);
csp_bind(socket, PORT_4);
csp_listen(socket, MAX_CONNS_IN_Q);
while(1) {
conn = csp_accept(socket, TIMEOUT_MAX);
packet = csp_read(conn, TIMEOUT_NONE);
printf(ā%S\r\nā, packet->data);
csp_buffer_free(packet);
csp_close(conn);
}
That's all that was given for the sample server end of the code. So I decided to add these to the top:
#include <csp.h>
#include <csp_buffer.h>
#include <csp_config.h>
#include <csp_endian.h>
#include <csp_interface.h>
#include <csp_platorm.h>
Thinking I was on the right track, I tried to compile the code with gcc, but I was given this error:
csptest_server.c:1: fatal error: csp.h: No such file or directory
compilation terminated.
I thought I may not have installed the library correctly after all, but to make sure, I found out I could check by running this command, and getting this result:
find /usr -iname csp.h
/usr/src/linux-headers-2.6.35-28-generic/include/config/snd/sb16/csp.h
/usr/src/linux-headers-2.6.35-22-generic/include/config/snd/sb16/csp.h
So it seems like the csp.h is installed, maybe I am referencing it incorrectly in the header include line? Any insight? Thanks a lot.
The make command is probably only building the library, but not installing it. You could try sudo make install. This is the "common" method, but I recommend you to check the library's documentation, if any.
The sudo command is only necessary if you have no permissions to write the system's include and library directories, which may be your case.
Another possibility (instead of installing the library) is telling GCC the location of the library's source code and generated binaries (by means of the -I and -L options of the gcc command.
That Makefile will not install anything, just translate the source into a binary format.
The csp.h in the Linux kernel has nothing to do with your project, it's just a naming collision, likely to happen with three letter names.
In your case, I would presume you need to add the include directory to the compilation flags for your server, like gcc -I/path/to/csp/include/csp csptest_server.c.
(Next, you'll run into linker errors because you'll also want to specify -L/path/to/csp -lcsp so that the linker can find the binary code to link to.)