Re: [Bug-gnulib] Symbol collision

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> Simon Josefsson wrote:
>> It occured to me that if some of these functions happen to be included
>> in both libraries, e.g. strdup, won't linking an application to both
>> libraries break?  The same symbol would be defined by both libraries.
>> I'm not sure if some linkers only treat this as a warning, instead of
>> an error, but even this seem to be unwanted.
>
> This is likely to be a problem with non-static *variables* on some
> platforms (like MacOS X or Woe32). With *functions* I think all should
> be fine if the two functions are equivalent.
>
> Someone with access to MacOS X and Woe32 systems should verify this...

Such as, from gnulib/lib/error.c:

/* The calling program should define program_name and set it to the
   name of the executing program.  */
extern char *program_name;

?

This definition was that made me start think about this problem.

This also make it problematic to use error.c in a library (or anything
that uses error.c, such as xalloc, alloca, etc, or anything that uses
xalloc, alloca, etc, and so on).  I.e.: should my library define
program_name?  Probably not, but then the application using my library
will need to define it, which is unfortunate, since one of my
libraries are often used by other libraries, which in turn cannot
define program_name but must require their applications to define it.

I do have access to a cygwin system, does that count as Woe32?