AIX linker oddities...what is going on?


 
Thread Tools Search this Thread
Top Forums Programming AIX linker oddities...what is going on?
# 1  
Old 01-26-2011
AIX linker oddities...what is going on?

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!

Last edited by DreamWarrior; 01-26-2011 at 04:34 PM..
# 2  
Old 01-26-2011
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 ;-))
# 3  
Old 01-26-2011
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?
# 4  
Old 01-26-2011
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)
# 5  
Old 01-26-2011
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.
# 6  
Old 01-26-2011
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...
# 7  
Old 01-27-2011
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...
Login or Register to Ask a Question

Previous Thread | Next Thread

9 More Discussions You Might Find Interesting

1. Solaris

Runtime Linker Problems ld.so.1

Hello all, I am releatively new to Solaris and I am the System administrator for my branch at the FAA. This is the first time I can say I have really messed something up thankfully. My issue came up after installing and uninstalling Oracle Secure Backup which i felt I needed to do a clean... (7 Replies)
Discussion started by: jbirkes
7 Replies

2. Solaris

runtime linker errors

Hey guys I have a solaris 10 OS, with a zone configured. In that zone, I am trying to install an Oracle Client. However, when I run the oracle installer, I get the following error: ld.so.1: java: fatal: libexpat.so.0: open failed: No such file or directory ld.so.1: java: fatal:... (2 Replies)
Discussion started by: goodvikings
2 Replies

3. Programming

gcc linker address

Hai, I have two (Pgm1.c and Pgm2.c) simple programs, which is compiled using gcc. Now we have two exe's (Pgm1 and Pgm2). When i executed the nm Pgm1 and nm Pgm2, in the listed symbols the address of main is same for both programs (08048344 T main) at run time also. Doubt: 1) What is this... (3 Replies)
Discussion started by: rajamohan
3 Replies

4. Programming

GCC: Choose my own linker

Hi, I do not use the default linker, and instead us another one and pass this argument -Wl,--dynamic-linker=<path to linker> to gcc when compiling. However, what happens if the linker is not under /lib and /lib64 and I am not able to create a symlink to the linker in /lib or /lib64 due to no... (2 Replies)
Discussion started by: Shompis
2 Replies

5. HP-UX

Hp-ux linker option -c

Hi, The necessary symbols in a shared library can be exported to the application using linker option --version-script in Linux. The same can be done in Hp-ux using linker option +e. This can also be done by listing all the global symbols with +e in a file with linker option ld -c filename in... (0 Replies)
Discussion started by: roopa_v
0 Replies

6. Linux

G++ Linker Error

Hi All, I m new to this group. I m facing one problem during my linking of CPP code at Linux env. after compliation i m getting error "undefined reference to ....." Please anyone help me to resolve this error. Regards, ASR make: Leaving directory /fwk' echo g++ -o server ... (1 Reply)
Discussion started by: ASRRAJ
1 Replies

7. HP-UX

dynamic linker error

Hi All Could anyone help in giving a little background to the following runtime error. /usr/lib/pa20_64/dld.sl: Mmap failed due to errno: 13. Seen when executing a 64-bit ELF executable. Thanks Ed (3 Replies)
Discussion started by: C3000
3 Replies

8. Solaris

ftp oddities

I have recently set up a connection b/t a sun ultra 60 running solaris 8 and a regular old pc running XP. Unfortunately I only know a little bit about networking thanks to Winblows plug and play mentality. Can anyone tell me why my connection from PC to sun is intermittant? The IP is always... (2 Replies)
Discussion started by: Serious_Lee
2 Replies

9. UNIX for Dummies Questions & Answers

Linker (ld)

hai I have installed Linux 7.0 on my system and i have an doubt the linker i ran simple hello.c program with gcc compiler gcc -c hello.c i want linker to produce the output so i put on the command line as ld first.o -lc but it is not running ver properly but there is an... (1 Reply)
Discussion started by: rajashekaran
1 Replies
Login or Register to Ask a Question

Featured Tech Videos