Re: [Mingw-users] mingw gcc-3.2.3: multiple definition of `strcasecmp'

[<dan...@ya...>]

 --- Greg Chicares <chi...@mi...> wrote: > Danny Smith wrote:

----Snip----
> 
> > Should we change all the extern inlines to static inline (my first "knee-jerk")
> 
> That fixes my test case. And it has to be done
> anyway before the semantics change to C99, as
> you point out.
> 
> >  or just protect with
> > #ifndef  __NO_INLINES__
> > (which is predefined by gcc when no optimization)
> 
> That doesn't seem to fix my test case, so maybe
> I'm using it wrong. I tried
>   #ifndef __NO_INLINES__
>   extern __inline__
>   #endif /* __NO_INLINES__ */
>   int __cdecl
>   strcasecmp (const char * __sz1, const char * __sz2)
>     {return _stricmp (__sz1, __sz2);}
> But maybe I'd have to rebuild lib?oldname.a .
> 
I meant like this
#ifndef __NO_INLINES__
extern __inline__  int __cdecl
  strcasecmp (const char * __sz1, const char * __sz2)
    {return _stricmp (__sz1, __sz2);}
#endif /* __NO_INLINES__ */

since the extern (non-inline) decl is there as well

> The real-world problem underlying my test case
> is linking wxWindows, a C++ library that uses
> the inline strcasecmp() and puts it in the
> text segment...
> 
>   $nm --print-file-name [wx-dir]/lib/libwxmsw-ming323.a |grep strcasecmp
>   ../../lib/libwxmsw-ming323.a:string.o:00000000 t .text$strcasecmp
>   ../../lib/libwxmsw-ming323.a:string.o:00000000 T _strcasecmp
> 
> ...with mpatrol, a malloc debugger that uses
> libbfd, which requires libiberty, which I
> suspect brings in strcasecmp from libmoldname
> based on this reformatted section --print-map:
>   /MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../libmoldname.a(string_old.o)
>      /MinGW/bin/../lib/gcc-lib/mingw32/3.2.3/../../../libbfd.a(archures.o)
> (strncasecmp)
> 
> in case that helps. Would these fixes guard
> against that real-world problem, even if I
> use different options for building different
> libraries? I don't know enough about these
> gcc-specific things to answer reliably.

I think so, but I don't have time write now to play with mpatrol'ed wxWindows

> > The other probelm that could arise (even with optimization) is when a function
> > can't be inlined because we need its address -- eg in a callback.
> 
> I could imagine using a pointer to strcasecmp()
> for a sort-function's comparison callback.
> 

That's were the external inline extension is really useful: the function gets inlined
everwhere except where it is used by reference. But it is non-standard. There was some
discussion on gcc lists on how to handle this extension, which is now quite common in gcc
world, when C99 semantics are fully enforced with -std=c99 

> > Related improvement would be to break up string-old.c,  so that each object contains
> > only a single function.
> 
> Should it be in lib?oldname.a at all if we
> want it to be inline always? Would rebuilding
> with 'static inline' or '__NO_INLINES__'
> prevent that?
> 
There is another new GCC extension __attribute__((always_inline)) that would work, but
I'll leave that alone for now.

Danny

http://mobile.yahoo.com.au - Yahoo! Mobile
- Check & compose your email via SMS on your Telstra or Vodafone mobile.