For Programmers: Free Programming Magazines  


Home > Archive > Unix Programming > December 2005 > Problem with linking









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Problem with linking
John Smith

2005-12-11, 7:16 pm

I'm having a big problem linking a static library under Linux and Mac OSX:

I have two applications which use a static library that is compiled in C. My
own application is written in C++ and uses g++ for compilation.


When I compile one of the application it becomes an executable that runs
just fine.
The other application is a shared library which on OS X refuse to link and
on Linux just acts weird.

On linux the following happens:

Linking works fine:
g++ -o
temp/Linux/my.so -static-libgcc -shared -Wl,--version-script=linux_exports.t
xt libhasp_linux.a -lpthread temp/Linux/my.o ...

But once the linked file contains undefined symbols:
[root@localhost Linux]# nm my.so | grep -e "hasp"
U hasp_decrypt

U hasp_encrypt

U hasp_free

U hasp_get_sessioninfo

U hasp_login

U hasp_logout

U hasp_read

U hasp_write

What can you do about this and why does it happen?
Is this because the 3rdparty library is not compiled with -fpic switch?
I wonder why the linker does not give any warnings or errors.

On mac os the linker tells something is wrong but I really don't understand
why either:
g++ temp/Darwin/my.o -framework Cocoa -framework IOKit -o
temp/Darwin/my.dylib -static-libgcc
-dynamiclib -exported_symbols_list macosx_exports.txt -install_name my.dylib
libhasp_darwin.a

/usr/bin/libtool: internal link edit command failed

ld: common symbols not allowed with MH_DYLIB output format with
the -multi_module option

.../../shared/libs/hasphl/libhasp_darwin.a(wurzl28.o) definition of common
_parity (size 256)

.../../shared/libs/hasphl/libhasp_darwin.a(wurzl30.o) definition of common
___essigknoedl002 (size 42)

.../../shared/libs/hasphl/libhasp_darwin.a(wurzl31.o) definition of common
___reiberdatschi02 (size 4)



In case someone is interested you can download the libraries from:
ftp://ftp.aladdin.com/pub/hasp/hl/l...HL_Linux.tar.gz
ftp://ftp.aladdin.com/pub/hasp/hl/m...P_HL_MacOSX.zip



Paul Pluzhnikov

2005-12-11, 7:16 pm

"John Smith" <cybh@billigsolv.dk> writes:

> I'm having a big problem linking a static library under Linux and Mac OSX:


I don't know anything about Mac, but on Linux your link line is incorrect:

> g++ -o temp/Linux/my.so -static-libgcc -shared -Wl,--version-script=linux_exports.txt libhasp_linux.a -lpthread temp/Linux/my.o ...


Correct line should be:
g++ -o temp/Linux/my.so -pthread -static-libgcc -shared -Wl,--version-script=linux_exports.txt temp/Linux/my.o ... libhasp_linux.a

Note the reversal of order of my.o (and other objects) and lbhasp_linux.a

> What can you do about this and why does it happen?


To understand why the order matters, read this:
http://webpages.charter.net/ppluzhnikov/linker.html

> Is this because the 3rdparty library is not compiled with -fpic switch?


No.

> I wonder why the linker does not give any warnings or errors.


Because there is nothing wrong as far as linker is concerned.
It is perfectly normal for a library to have undefined references.

If you want to ensure that your library doesn't, add -Wl,-z,defs
to your link line.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
John Smith

2005-12-11, 7:16 pm

Thank you for the quick and precise answer.

It's one of those problems one can spend long time on if you don't know the
exact answer. I would never have guessed it.

You suggestion works fine though and I got it working under Mac OS X too.

Thanks!


Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2010 codecomments.com