Home > Archive > Unix Programming > December 2004 > linking problem stumping me
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 |
linking problem stumping me
|
|
| kaatzd@hotmail.com 2004-12-15, 3:59 pm |
| Any help would be greatly appreciated.
The problem I'm trying to understand is this:
My program is using several shared libraries that I compiled with g++.
On compilation of the program, I get link errors that indicate a
function in one library is not being found, by code that is in another
library. Errors like this:
libdctblLX.so: undefined reference to `FileExists(char*, unsigned
long*, unsigned long*)
FileExists is a function in my libfiles_gpLX.so library, and is
prototyped like this:
long FileExists (char *, unsigned long *, unsigned long *);
Now, if I do "nm libdctblLX.so" and "nm libfiles_gpLX.so" I get
the following listings for FileExists, respectively:
U _Z10FileExistsPcPmS0_
and
00001d68 T FileExists
Now, it seems likely to me that I have a problem with name mangling
in the calling library, and no mangling occuring in the source lib.
But, both libraries source entirely consists of .c and .h files.
I would expect no name mangling whatsoever.
The target program, however, is a mix of .cpp and .c source files.
Why would mangling be occurring in the calling lib?
BTW, I also have a similar problem with some functions that are in
the program source, defined in a .c file, and called from another .c
file. In this case nm shows the functions with slightly different
mangled names.
TIA,
Dave
| |
| Billy Patton 2004-12-15, 8:57 pm |
| On Wed, 15 Dec 2004, kaatzd@hotmail.com wrote:
> Any help would be greatly appreciated.
>
> The problem I'm trying to understand is this:
> My program is using several shared libraries that I compiled with g++.
> On compilation of the program, I get link errors that indicate a
> function in one library is not being found, by code that is in another
> library. Errors like this:
> libdctblLX.so: undefined reference to `FileExists(char*, unsigned
> long*, unsigned long*)
>
> FileExists is a function in my libfiles_gpLX.so library, and is
> prototyped like this:
> long FileExists (char *, unsigned long *, unsigned long *);
>
> Now, if I do "nm libdctblLX.so" and "nm libfiles_gpLX.so" I get
> the following listings for FileExists, respectively:
> U _Z10FileExistsPcPmS0_
> and
> 00001d68 T FileExists
>
> Now, it seems likely to me that I have a problem with name mangling
> in the calling library, and no mangling occuring in the source lib.
>
> But, both libraries source entirely consists of .c and .h files.
> I would expect no name mangling whatsoever.
> The target program, however, is a mix of .cpp and .c source files.
>
> Why would mangling be occurring in the calling lib?
>
> BTW, I also have a similar problem with some functions that are in
> the program source, defined in a .c file, and called from another .c
> file. In this case nm shows the functions with slightly different
> mangled names.
>
> TIA,
> Dave
>
>
liba1.so - has function b
liba1.so - calls function b
g++ -o x -la1 -la2
Order specific libraries with gcc
___ _ ____ ___ __ __
/ _ )(_) / /_ __ / _ \___ _/ /_/ /____ ___
/ _ / / / / // / / ___/ _ `/ __/ __/ _ \/ _ \
/____/_/_/_/\_, / /_/ \_,_/\__/\__/\___/_//_/
/___/
Texas Instruments ASIC Circuit Design Methodology Group
Dallas, Texas, 214-480-4455, b-patton@ti.com
| |
| kaatzd@hotmail.com 2004-12-15, 8:57 pm |
| OK, it looks like there is a typo in your response - both examples
listed as liba1.
My original make file lists defining library, then calling library. I
tried switching, with no change in errors.
Also, the linking lib listing order doesn't explain the problem I'm
having with the function defined in one .c file, called from another,
both are source for the final program file.
Dave
| |
| kaatzd@hotmail.com 2004-12-15, 8:57 pm |
| I solved the problem of linking in the source files of the program
itself. It was a problem with prototype and extern naming the
prototypes were declared in the c files themselves, instead of in one h
file; and they differed.
The lib linking problem remains.
Dave
| |
| James Antill 2004-12-15, 8:57 pm |
| On Wed, 15 Dec 2004 10:07:37 -0800, kaatzd@hotmail.com wrote:
> On compilation of the program, I get link errors that indicate a
> function in one library is not being found, by code that is in another
> library. Errors like this:
> libdctblLX.so: undefined reference to `FileExists(char*, unsigned
> long*, unsigned long*)
>
> FileExists is a function in my libfiles_gpLX.so library, and is
> prototyped like this:
> long FileExists (char *, unsigned long *, unsigned long *);
>
> Now, if I do "nm libdctblLX.so" and "nm libfiles_gpLX.so" I get
> the following listings for FileExists, respectively:
> U _Z10FileExistsPcPmS0_
This is a C++ name, the header file needs...
#ifdef __cplusplus
extern "C"
{
#endif
/* C function prototypes */
#ifdef __cplusplus
}
#endif
....or possibly, to really be compile as C and not C++.
--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
| |
| Paul Pluzhnikov 2004-12-16, 3:57 am |
| "kaatzd@hotmail.com" <kaatzd@hotmail.com> writes:
> Now, if I do "nm libdctblLX.so" and "nm libfiles_gpLX.so" I get
> the following listings for FileExists, respectively:
> U _Z10FileExistsPcPmS0_
> and
> 00001d68 T FileExists
>
> Now, it seems likely to me that I have a problem with name mangling
> in the calling library, and no mangling occuring in the source lib.
Right.
> But, both libraries source entirely consists of .c and .h files.
> I would expect no name mangling whatsoever.
Wrong.
In the libfiles_gpLX.so, the .c file is compiled with gcc,
so no name mangling happens.
In the libdctblLX.so, the file that uses FileExists() is apparently
compiled with 'g++', and so name mangling occurs.
If you want to stop that, do this in your header file:
#ifdef __cplusplus
extern "C"
#endif
long FileExists (char *, unsigned long *, unsigned long *);
Now name mangling will not happen, regardless of:
- whether 'gcc' or 'g++' is used to compile the source, and
- whether the .c or .cpp includes the header.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| kaatzd@hotmail.com 2004-12-16, 8:57 pm |
|
Paul Pluzhnikov wrote:
> "kaatzd@hotmail.com" <kaatzd@hotmail.com> writes:
>
>
> Right.
>
>
> Wrong.
>
> In the libfiles_gpLX.so, the .c file is compiled with gcc,
> so no name mangling happens.
>
> In the libdctblLX.so, the file that uses FileExists() is apparently
> compiled with 'g++', and so name mangling occurs.
>
Well, both libs were compiled with g++. I was able to fix this by
judicious use of extern "C" bracketing. It was my understanding that
any .c extension would automatically be compiled as C code, even if
calling g++ to compile it. Indeed, at first I was looking for a
compilation switch to force compilation as "C" code, and could not find
such a switch.
> If you want to stop that, do this in your header file:
>
> #ifdef __cplusplus
> extern "C"
> #endif
> long FileExists (char *, unsigned long *, unsigned long *);
>
Thank you for your help,
Dave
| |
| kaatzd@hotmail.com 2004-12-16, 8:57 pm |
|
Paul Pluzhnikov wrote:
> "kaatzd@hotmail.com" <kaatzd@hotmail.com> writes:
>
>
> Right.
>
>
> Wrong.
>
> In the libfiles_gpLX.so, the .c file is compiled with gcc,
> so no name mangling happens.
>
> In the libdctblLX.so, the file that uses FileExists() is apparently
> compiled with 'g++', and so name mangling occurs.
>
Well, both libs were compiled with g++. I was able to fix this by
judicious use of extern "C" bracketing. It was my understanding that
any .c extension would automatically be compiled as C code, even if
calling g++ to compile it. Indeed, at first I was looking for a
compilation switch to force compilation as "C" code, and could not find
such a switch.
> If you want to stop that, do this in your header file:
>
> #ifdef __cplusplus
> extern "C"
> #endif
> long FileExists (char *, unsigned long *, unsigned long *);
>
Thank you for your help,
Dave
| |
| Paul Pluzhnikov 2004-12-16, 8:57 pm |
| "kaatzd@hotmail.com" <kaatzd@hotmail.com> writes:
> Well, both libs were compiled with g++.
You are hiding something: if both files are .c, and both were
compiled with 'g++' without explicit language selection, then both
should have been mangled.
> It was my understanding that
> any .c extension would automatically be compiled as C code, even if
> calling g++ to compile it.
That is incorrect. Some compilers do that (e.g. IBM xlC), but
most don't. If you want to compile C code, invoke C compiler,
and if you want to compile C++, invoke C++ compiler. What could be
simpler then that?
> Indeed, at first I was looking for a
> compilation switch to force compilation as "C" code, and could not find
> such a switch.
There is such a switch: '-x c'
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
|
|
|
|
|