Re: multiple definitions of symbol _xxxx
Re: multiple definitions of symbol _xxxx
- Subject: Re: multiple definitions of symbol _xxxx
- From: Steve Checkoway <email@hidden>
- Date: Fri, 9 Feb 2007 05:25:35 -0800
On Feb 9, 2007, at 2:46 AM, Thomas Engelmeier wrote:
On 09.02.2007, at 11:26, Steve Checkoway wrote:
6.7.4.6 says
Any function with internal linkage can be an inline function. For
a function with external linkage, the following restrictions
apply: If a function is declared with an inline function
specifier, then it shall also be defined in the same translation
unit. If all of the file scope declarations for a function in a
translation unit include the inline function specifier without
extern, then the definition in that translation unit is an inline
definition. An inline definition does not provide an external
definition for the function, and does not forbid an external
definition in another translation unit. An inline definition
provides an alternative to an external definition, which a
translator may use to implement any call to the function in the
same translation unit. It is unspecified whether a call to the
function uses the inline definition or the external definition.
The spec doesn't seem to say anything about inline forcing
internal linkage.
Well for me it parses to "inline means translation unit local
linkage. inline can be used in C99 to provide a different
implementation of an existing external function, but in this case
it is implementation specific which function will be used"...
That's not how I read it. I see a function with internal linkage can
be inline, not a function declared with an inline function specifier
has internal linkage. Of course, the example the standard gives
doesn't make anything any clearer.
EXAMPLE The declaration of an inline function with external
linkage can result in either an external definition, or a
definition available for use only within the translation unit. A
file scope declaration with extern creates an external definition.
The following examples show an entire translation unit.
inline double fahr(double t)
{
return (9.0 * t) / 5.0 + 32.0;
}
inline double cels(double t)
{
return (5.0 * (t-32.0)) / 9.0;
}
extern double fahr(double); // creates an external definition
double convert(int is_fahr, double temp)
{
/* A translator may perform inline substitutions */
return is_fahr ? cels(temp) : fahr(temp);
}
Note that the definition of fahr is an external definition because
fahr is also declared with extern, but the definition of cels is an
inline definition. Because cels has external linkage and is
referenced, an external definition has to appear in another
translation unit (see 6.9); the inline definition and the external
definition are distinct and either may be used for the call.
That note makes no sense to me and is doesn't seem to be what gcc
does. If the above example is in g.c and h.c consists of
extern double convert(int, double);
double cels(double t) { return -1.0; }
int main() { return cels(100) != convert(1,100); }
and I compile them as
[dualg5:~/temp] steve$ gcc -Wall -std=c99 -c h.c
[dualg5:~/temp] steve$ gcc -Wall -std=c99 -c g.c
[dualg5:~/temp] steve$ nm h.o g.o
h.o:
00000000 T _cels
U _convert
00000034 T _main
U dyld_stub_binding_helper
g.o:
00000058 T _cels
000000b0 T _convert
00000000 T _fahr
[dualg5:~/temp] steve$ gcc -Wall h.o g.o
/usr/bin/ld: multiple definitions of symbol _cels
h.o definition of _cels in section (__TEXT,__text)
g.o definition of _cels in section (__TEXT,__text)
collect2: ld returned 1 exit status
So following "has to appear in another translation unit" seems to
break with gcc. I can't tell if this is a compiler bug, I'm reading
the standard wrong, or it's a standard bug.
(Which IMO renders the option to provide an alternative function
useless.)
Indeed.
[Note to list moderators: I realize this is getting off topic for
Xcode-users and would be more appropriate for some compilers list. I
even filed a bug asking for the creation of such a list rdar://
4771866, but they just told me that they forwarded the request on to
someone else. I really think a list devoted to compilers that run on
OS X, not just gcc, would be a useful and interesting thing to have.]
--
Steve Checkoway
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden