LNK ERROR:Using 'dlopen' in statically linked apps requires at runtime the shared lib

[tvnaidu]

I am getting this link error, I am using mongoose web server with Linux, any idea?:

mongoose.c:3114: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

mongoose.c:3081: Using 'getpwnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

[RRick]

I assume you are supplying a shared library to the server. This user supplied shared library might need other shared libraries. You have to make sure the server can access all of the shared libraries, including the compiler shared libraries like stdc++, and probably lib c.

The system variable LD_LIBRARY_PATH is the usual way to tell the server where to find all of the shared libraries. You directory add paths to it separated by semi-colons(;). You might have to restart the server.

[tvnaidu]

I need to set LD_LIBRARY_PATH before I run the executable.

Right now I made all static libs instead shared libs, also I am supplying -static flag to create execubale, do I need to remove that -static flag, also I supply path /opt/lib where I kept all static libs.

finally executable creates, but I gets this "dlopen", if I takeout -static flag , then it goes away, these two messages not coming

[RRick]

I need to set LD_LIBRARY_PATH before I run the executable.

Yes, you do. LD_LIBRARY_PATH can also be used with the compiler for linking in shared libraries.

The -static flag says don't use the C/C++ shared libraries. I don't suggest anyone using the static flag for any application. I had similar crash and burns problems when using it.

In your case, some library is using a shared library that dlopen can't find. I suspect its either lib c or stdc++. Put these paths in your LD_LIBRARY_PATH and I suspect the problem will go away.

[tvnaidu]

I just takeout -static flag and I rebuild again, then I did set LD_LIBRARY_PATH and then I run my app, I am getting "segmentation fault",but if I use -static flag back and recompile again, in this case, I gets that "dlopen" warning, but my app runs without any segmentation fault, but still when compile without -static flag earlier, I am passing some static libs with -l optioon, since I made all my libs as static libs instead dynamic libs, except few system libs also I am linking here which are mentioned below, in your previous post, you mentioned -static is not a good option, right now if I use that option only, I can get my app running, otherwise seg. fault coming (in this case, after I set LD_LIB PATH, if I do "ldd my-own-app", then I can see beloe shared libs since I am linking these. but with -static option how big risk it is, if I release my app to customer?

these system shared libs I am linking:
-ldl -ltinyxml -lpthread -lm -lstdc++

[RRick]

With the static flag I had unexplained crash and burn problems with a program. Once we went back to the C++ shared library, these problems went away. That's as far as I went with it. Like you, I go with what works.

You have a couple of choices here. You can hunt down the dlopen problem. Using ldd on your executable should tell you where to look. strace might help too.

You can hunt down the seg fault. This looks like a separate issue from the dlopen and will probably have to be addressed anyway. My guess is that the dlopen problem occurs before the seg fault. The debugger is a good place to check for this problem.

[RRick]

With the static flag I had unexplained crash and burn problems with a program. Once we went back to the C++ shared library, these problems went away. That's as far as I went with it. Like you, I go with what works.

You have a couple of choices here. You can hunt down the dlopen problem. Using ldd on your executable should tell you where to look. strace might help too.

You can hunt down the seg fault. This looks like a separate issue from the dlopen and will probably have to be addressed anyway. My guess is that the dlopen problem occurs before the seg fault. The debugger is a good place to check for this problem.

[tvnaidu]

right now I gets that dlopen message during linking only, with -static flag I am able to build executable on Linux, I am able to run that. but that image was built with static libs.

I just changed all static libs to shared libs, I build again on Linux, I tried to run that, I gets seg. fault as soon as I run, I think the other image built with static libs is much better, I can run, also I can communicate with peer, ultimately I don't want to use static libs, I need to use shared libs, but with shared libs, I gets this issue, I just started with gdb, I did backtrace, it doesn't show anything.

am I missing any standard shared libs, right now I am linking these:
-ldl -lpthread -lm -lstdc++

[tvnaidu]

I have everything works with static libs, I converted all static libs to shared lib (-shared flag), I get segmentation fault. also I set LD_LIBRARY_PATH. It crashes immediately. backtrace shows only one line below. also ldd shows all shared libs.

(gdb) run
Starting program: ~/config/vmal

Program received signal SIGSEGV, Segmentation fault.
0x00000001 in ?? ()
(gdb) backtrace
#0 0x00000001 in ?? ()
(gdb)

[tvnaidu]

Looklike stack is trashing, that is why backtrace not show anything, how can I hold stack?.

[RRick]

Did you turn on the compiler debug flag -g (or -g3) flag? Also, if you have stripped out all symbolic info, you won't get any trace info.

The other problem might be the system you are using. I had problems with cgywin and the debug information. If you are using a "normal" linux distro, this shouldn't be a problem.

[tvnaidu]

Well, I turned -g option for every file, also when I do "ldd final-prog", it shows all shared libs.

[tvnaidu]

when I build my final executable using shared libs, I just replaced static with shared in makefile, also I have .a files availbale for static and .so files available for shared.

I did small test, when I remove one library linking for static, I got many undef symbols, final exe file didn't built, the same test I did for shared, everytime execubale builts no matter whether I have all shared lib linking with -l option or not, looklike final exe file built with shared libs is faked one?. do I need anything else besides -shared instead -static in Makefile?.