Using two different third party softwares ... function multiplpy-defined error

[Kaushal Mehta]

Hello,

I am using two third party softwares, cyrus IMAP and UW c-client and
both of them are defining a function fatal with different signature.
Here is the error
"ld: fatal: symbol `fatal' is multiply-defined:
(file SunOS-sparc-5.8/imapd.o type=FUNC; file
/thirdParty/cclient/c-client/libc-client.a(osdep.o) type=FUNC);"

The signatures are
void fatal(const char *s, int code)
and
void fatal (char *string)

Its been used all over the place so changing the name does not sound
like a good idea.

Can you guys help me resolve this?. Thanks. Kaushal.

 

[Mike Wahler]

Hello,

I am using two third party softwares, cyrus IMAP and UW c-client and
both of them are defining a function fatal with different signature.
Here is the error
"ld: fatal: symbol `fatal' is multiply-defined:
(file SunOS-sparc-5.8/imapd.o type=FUNC; file
/thirdParty/cclient/c-client/libc-client.a(osdep.o) type=FUNC);"

The signatures are
void fatal(const char *s, int code)
and
void fatal (char *string)

Its been used all over the place so changing the name does not sound
like a good idea.

You have a name collision. One of them must change, if
you want access to both functions from the same scope(s).

-Mike

 

[Michael Mair]

You have a name collision. One of them must change, if
you want access to both functions from the same scope(s).

The nasty thing is that this often happens with functions which
should not be visible outside of the library. Some genius comes
up with "Oh, let's die with 'fatal'" and -- oh wonder -- it so
happens that someone else has the same idea.
IMO, a library should work with prefixes for functions and variables
with external linkage which should not be visible outside of the
library. The C89 limits are not very helpful in this case, though...

<OT>
@OP: If fatal is _always_ called from inside the libraries,
you can force the libraries to not show this symbol to the
outside. If you use gcc, you can have a look into the gcc.gnu.help
archives of the last two months; AFAIR this problem has been
addressed there.
</OT>

If you have access to the source, you can easily use a good
editor or a combination of find and sed (*) to replace fatal
by cyrus_IMAP_fatal and UW_c_client_fatal, respectively,
and just build the whole thing again.
If you do not have access to the source code, then you have to
ask for a change of the symbol name.


Cheers
Michael
_____________________
<OT>
(*) Example for the bash:

for FILE in `find $MYROOT -type f -exec grep -l fatal {} \;`; do
sed 's/\<fatal/another_fatal/g' $FILE > $FILE.new
mv -f $FILE.new $FILE
done

Set MYROOT to the directory containing the source code.
Make a copy of $MYROOT.
Try the above.
This is not foolproof but should do nicely in most cases.

 

[Lawrence Kirby]

On Wed, 22 Dec 2004 20:58:57 +0100, Michael Mair wrote:

....

If you have access to the source, you can easily use a good
editor or a combination of find and sed (*) to replace fatal
by cyrus_IMAP_fatal and UW_c_client_fatal, respectively,
and just build the whole thing again.

Another possibility could be to redefine the name in one of the
packages using a macro. Most compilers allow you to define macros on the
command line. If you did it that way you wouldn't even have to modify the
source code, just the build script.

Lawrence

 

[Michael Mair]

On Wed, 22 Dec 2004 20:58:57 +0100, Michael Mair wrote:

...




Another possibility could be to redefine the name in one of the
packages using a macro. Most compilers allow you to define macros on the
command line. If you did it that way you wouldn't even have to modify the
source code, just the build script.

.... the obvious... thanks for pointing it out

 

[Kaushal Mehta]

Thanks to everybody for their inputs, I changed makefile and redefined
fatal in cclient and c_client_fatal using the -D option. Thanks again
to everybody.

 

[CBFalconer]

Thanks to everybody for their inputs, I changed makefile and
redefined fatal in cclient and c_client_fatal using the -D
option. Thanks again to everybody.

We have no idea what you are talking about. Suitable context
quotes are needed, and preserving the original subject might help
also. See the sig below for a way to avoid the worst of Googles
usenet posting bugs.