Programming

I've tried to figure out what the linker is smoking in AIX to no avail...so I'm trying to find a little information to see why it's being inconsistent.

I have the following code in a shared library, it doesn't do anything useful, it's just there to exercise functions in a few system libraries:

Code:

#include <curses.h>
#include <math.h>
#include <pthread.h>

static pthread_mutex_t g_mx = PTHREAD_MUTEX_INITIALIZER;

static void *testT(void *arg)
{
	pthread_mutex_lock(&g_mx);
	printf("Hello from thread...\n");
	pthread_mutex_unlock(&g_mx);
}

void shlibfn()
{
	double	r;
	pthread_t	tid;
	
	pthread_mutex_lock(&g_mx);

	pthread_create(&tid, NULL, testT, NULL);
	
	r = sin(0.0);
	
	initscr();
	endwin();

	pthread_mutex_unlock(&g_mx);
}

It is built as follows:

Code:

cc shlibsrc.c -G -o libsh.so

Now, I have a very simple main application:

Code:

void main()
{
	extern void shlibfn();
	
	shlibfn();
}

Built as follows:

Code:

cc main.c -lpthread -lcurses -lm -L. -brtl -lsh -o main

I expect that ldd would say that main needs pthread, curses, and the math library in addition to sh at this point, but it doesn't. What ldd says is:

Code:

main needs:
	/usr/lib/libpthread.a(shr_xpg5.o)
	./libsh.so
	/usr/lib/libc.a(shr.o)
	/usr/lib/librtl.a(shr.o)
	/usr/lib/libpthreads.a(shr_comm.o)
	/unix
	/usr/lib/libcrypt.a(shr.o)

Ok...fine, but when I run it, even though I asked it to link main to curses, it did not. Therefore, I get a run time error from rtld that the symbols (initsrc and endwin) aren't found and libsh.o needs them.

Interesting...so, for grins I modify main to use something from curses:

Code:

#include <curses.h>

void main()
{
	extern void shlibfn();
	
	shlibfn();
	endwin();
}

Build it the same way, and now ldd picks up the curses library requirement on main. It also runs now. That's pretty...interesting...but I suppose the linker is being smarter than me...or is it.

Let's go back to the first main, without the call to endwin. We'll link him a few ways, here's the results:

Build 1:

Code:

>cc mainsrc.c -L. -brtl -lsh -o main
>ldd main
main needs:
         ./libsh.so
         /usr/lib/libc.a(shr.o)
         /usr/lib/librtl.a(shr.o)
         /unix
         /usr/lib/libcrypt.a(shr.o)

Build 2:

Code:

>cc mainsrc.c -lpthread -L. -brtl -lsh -o main
>ldd main
main needs:
         /usr/lib/libpthread.a(shr_xpg5.o)
         ./libsh.so
         /usr/lib/libc.a(shr.o)
         /usr/lib/librtl.a(shr.o)
         /usr/lib/libpthreads.a(shr_comm.o)
         /unix
         /usr/lib/libcrypt.a(shr.o)
>./main
exec(): 0509-036 Cannot load program ./main because of the following errors:
rtld: 0712-001 Symbol sin was referenced
      from module ./libsh.so(), but a runtime definition
      of the symbol was not found.
rtld: 0712-001 Symbol initscr was referenced
      from module ./libsh.so(), but a runtime definition
      of the symbol was not found.
rtld: 0712-001 Symbol endwin was referenced
      from module ./libsh.so(), but a runtime definition
      of the symbol was not found.

Interesting, I change nothing in the main source, I don't use anything from pthreads in main, but the linker does put a dependency on pthreads when I ask it to during the second build. As expected it doesn't run.

Now we'll go back to the second version of main where it uses something from curses and build him a few ways:

Build 1:

Code:

>cc mainsrc.c -lpthread -L. -brtl -lsh -o main
ld: 0711-317 ERROR: Undefined symbol: .endwin
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.

Expected, I'm trying to use endwin...let's link him; build 2:

Code:

>cc mainsrc.c -lpthread -lcurses -L. -brtl -lsh -o main
>ldd main
main needs:
         /usr/lib/libpthread.a(shr_xpg5.o)
         /usr/lib/libcurses.a(shr42.o)
         ./libsh.so
         /usr/lib/libc.a(shr.o)
         /usr/lib/librtl.a(shr.o)
         /usr/lib/libpthreads.a(shr_comm.o)
         /unix
         /usr/lib/libcrypt.a(shr.o)
>./main
exec(): 0509-036 Cannot load program ./main because of the following errors:
rtld: 0712-001 Symbol sin was referenced
      from module ./libsh.so(), but a runtime definition
      of the symbol was not found.

Ok...getting closer, since we use endwin, it decides it is needed and, as such, pulls it in. But, I still didn't link math, so there's no sin and it won't run. That's all well and good, but I don't use anything from math in mainsrc.c, so if you follow the same logic that was needed to get curses to link, you'd think I'd need to use something...but, build 3:

Code:

>cc mainsrc.c -lpthread -lm -lcurses -L. -brtl -lsh -o main
>ldd main
main needs:
         /usr/lib/libpthread.a(shr_xpg5.o)
         /usr/lib/libcurses.a(shr42.o)
         ./libsh.so
         /usr/lib/libc.a(shr.o)
         /usr/lib/librtl.a(shr.o)
         /usr/lib/libpthreads.a(shr_comm.o)
         /unix
         /usr/lib/libcrypt.a(shr.o)
>./main
Hello from thread...

And it works. The funny thing is, there is NO CHANGE to the output of ldd between the two versions. One works, one doesn't....same ldd output, and I didn't need to put anything in main to pick up the math library.

So...this isn't consistent, if fact it's downright mind boggling. I'm wondering if anyone can shed some light on why this is happening.

I also want to note that I can fix all this stupidity by changing the way I link the library. If I link the library to the pthreads, curses, and math library as follows:

Code:

cc shlibsrc.c -G -o libsh.so -lpthread -lm -lcurses

Then I can build mainsrc.c as follows:

Code:

>cc mainsrc.c -L. -brtl -lsh -o main

And it works fine and the ldd output is almost identical (just with the order switched) to the working version above. I realize that this is probably the "best" way to link this stuff together so that the library states its dependencies, but I can't always have control over how the library was built (we don't build them all) and so I'm running into these oddities.

Sorry for the long post...but this AIX linker is driving me nuts!

P.S. None of this stupidity happens in Linux. In Linux, the minute I try to build main linking to sh without any of the required libraries (pthread, math, ncurses) it complains and won't build.

Code:

$ cc mainsrc.c -L. -lsh
./libsh.so: undefined reference to `endwin'
./libsh.so: undefined reference to `initscr'
./libsh.so: undefined reference to `pthread_create'

I link it the way I expect to work in AIX:

Code:

$ cc mainsrc.c -L. -lpthread -lm -lncurses -lsh
$ export LD_LIBRARY_PATH=.
$ ./a.out
Hello from thread...

And it works without a hitch. Seems like Linux's linker has its act a little better together, or it's just AIX's stupid "shared archive" vs. "shared library" crap that's messing with me. I don't know...but that's why I'm posting here...maybe someone familiar with AIX will.

Thanks all!

Have you tried compiling in verbose ? I think in your later compiles, that libm is linking against the static library, not the shared libm, and thats why you dont see it on the ldd.

I'd try using "nm -P" and "dump -H" to try and track down what functions are missing from where.

However, I would expect your:

Code:

cc shlibsrc.c -G -o libsh.so -lpthread -lm -lcurses

to be the correct one...I dont think when you link the mainsrc.o against libsh.so it checks that all the symbols are defined. Therefore I would expect you to have to specifically link shared objects against the libraries they need.

(Sorry If Ive missed stuff in the post - its pretty long, and I obviously work with computers so my attention span is short ;-))

Is there any way to force the compiler to behave like the Linux compiler? There are a few libraries we've had built for us that don't link all their dependencies correctly and, as such, we need to pull strings to get the linker to build the final executable "right" and in working order.... Sometimes we have to go searching around for the library that contains the symbol and link it to the main executable; sometimes that works (like pthreads took) and sometimes it doesn't (like curses didn't). I'd expect when linking mainsrc.c that if I tell the linker to link a library that it will regardless of whether or not code in that library is needed.

So, while you may very well be correct about libm, that doesn't explain pthreads vs. curses. I don't have to use any functions from pthreads to force the linker to give main a dependency to that, while I do have to use a function from curses to get that dependency. What gives there?

Ive always found the AIX linker to be an oddity - different from most of the others...
I believe GNU get around it using "libtool" - If you use that on all your build platforms, it works out what and how to link what you need (and will do stuff like setting the rpath in the shared object - something you may not have thought about)

You know the saying: "Sometimes a programmer has a problem, and he thinks to himself 'I know, I'll solve it with a regular expression!'. Now he has two problems." I think the same of autotools.

I totally agree....but then, who doesnt use regular expressions ?
Cant live with them, cant live without them...

Never used autoconf or automake - have heard nightmares about them, but Ive used libtool and I find for certain crossplatform issues it works well...

Speaking of paths...it seems the linker places the path of the shared library in the executable itself. The documentation says to pass -bnoipath to, supposedly, prevent this. However, using -bnoipath (or -Wl,-bnoipath from cc) doesn't seem to work. The path is still present and shown by ldd. This isn't directly an issue because it does appear the runtime linker uses the LD_LIBRARY_PATH first before consulting the paths in the executable, but I'd prefer it not to have the option. This way, if a developer forgets to properly configure the LD_LIBRARY_PATH they don't pick up a version of the library by default, rather they get an error that the library isn't found.

As for the original problem...I still can't make heads or tails of it. We're just going to have to keep fighting the linker. Ugh...