Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #138329 > unrolled thread

Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9

Back to article view | Back to comp.lang.c

Contents

  Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-27 14:38 -0800
    Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Ian Collins <ian-news@hotmail.com> - 2018-11-28 15:37 +1300
      Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-27 19:53 -0800
        Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Ian Collins <ian-news@hotmail.com> - 2018-11-28 17:42 +1300
          Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-27 22:06 -0800
            Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Ian Collins <ian-news@hotmail.com> - 2018-11-28 20:45 +1300
              Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-28 10:30 -0800
                Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 jameskuyper@alumni.caltech.edu - 2018-11-28 11:01 -0800
                  Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-29 01:35 -0800
                    Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-11-29 08:15 -0500
                      Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-30 12:48 -0800
                        Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-30 14:49 -0800
                          Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Keith Thompson <kst-u@mib.org> - 2018-11-30 14:56 -0800
                            Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-30 15:46 -0800
                            Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 David Brown <david.brown@hesbynett.no> - 2018-12-01 17:51 +0100
                              Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Richard Damon <Richard@Damon-Family.org> - 2018-12-01 13:37 -0500
                                Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 David Brown <david.brown@hesbynett.no> - 2018-12-02 12:49 +0100
                                  Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Richard Damon <Richard@Damon-Family.org> - 2018-12-02 08:16 -0500
                                    Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 David Brown <david.brown@hesbynett.no> - 2018-12-02 14:45 +0100
                        Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-12-04 08:51 -0800
                          Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 scott@slp53.sl.home (Scott Lurndal) - 2018-12-04 17:16 +0000
                            Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 William Ahern <william@25thandClement.com> - 2018-12-04 12:26 -0800
                            Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-12-05 07:08 -0800
                              Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 William Ahern <william@25thandClement.com> - 2018-12-05 13:39 -0800
                                Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-12-05 20:25 -0800
                              Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-06 07:01 -0800
                    Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-29 10:26 -0800
                      Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-30 12:59 -0800
                        Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-01 07:23 -0800
                          Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-02 03:56 -0800
                            Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-12-02 08:10 -0800
                              Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-03 14:00 -0800
                Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Nick Bowler <nbowler@draconx.ca> - 2018-11-28 19:42 +0000
                Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-29 10:09 -0800
            Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 jameskuyper@alumni.caltech.edu - 2018-11-28 05:55 -0800
              Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-28 10:36 -0800
    Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Bart <bc@freeuk.com> - 2018-11-28 13:13 +0000
      Re: Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9 Geoff <geoff@invalid.invalid> - 2018-11-30 13:39 -0800

Page 1 of 2  [1] 2  Next page →

#138329 — Multiple Includes Causing Multiple Definitions? (GCC 6.3.0) on Debian 9

First, this isn't a C question but I know there are a lot of
GCC-knowledgeable people in this group so I'm seeking tribal
knowledge.

This project used to compile without error on a previous version of
Debian but now is failing to link on a newer version. The makefile and
project code have not changed.

Link failure messages are of the type:
...
performance.o: In function `atoi':
performance.c:(.text+0x360): multiple definition of `atoi'
g_ai.o:g_ai.c:(.text+0x360): first defined here
performance.o: In function `atol':
performance.c:(.text+0x380): multiple definition of `atol'
g_ai.o:g_ai.c:(.text+0x380): first defined here
performance.o: In function `atoll':
performance.c:(.text+0x390): multiple definition of `atoll'
g_ai.o:g_ai.c:(.text+0x390): first defined here
...

All the errors appear to concern multiple definitions of
implementation and library symbols/functions.

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
6.3.0-18+deb9u1' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

[toc] | [next] | [standalone]

#138335

On 28/11/2018 11:38, Geoff wrote:
> First, this isn't a C question but I know there are a lot of
> GCC-knowledgeable people in this group so I'm seeking tribal
> knowledge.
> 
> This project used to compile without error on a previous version of
> Debian but now is failing to link on a newer version. The makefile and
> project code have not changed.
> 
> Link failure messages are of the type:
> ....
> performance.o: In function `atoi':
> performance.c:(.text+0x360): multiple definition of `atoi'
> g_ai.o:g_ai.c:(.text+0x360): first defined here
> performance.o: In function `atol':
> performance.c:(.text+0x380): multiple definition of `atol'
> g_ai.o:g_ai.c:(.text+0x380): first defined here
> performance.o: In function `atoll':
> performance.c:(.text+0x390): multiple definition of `atoll'
> g_ai.o:g_ai.c:(.text+0x390): first defined here
> ....
> 
> All the errors appear to concern multiple definitions of
> implementation and library symbols/functions.

Have you checked the obvious such as including the the correct standard 
headers?

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#138338

On Wed, 28 Nov 2018 15:37:30 +1300, Ian Collins <ian-news@hotmail.com>
wrote:

>On 28/11/2018 11:38, Geoff wrote:
>> First, this isn't a C question but I know there are a lot of
>> GCC-knowledgeable people in this group so I'm seeking tribal
>> knowledge.
>> 
>> This project used to compile without error on a previous version of
>> Debian but now is failing to link on a newer version. The makefile and
>> project code have not changed.
>> 
>> Link failure messages are of the type:
>> ....
>> performance.o: In function `atoi':
>> performance.c:(.text+0x360): multiple definition of `atoi'
>> g_ai.o:g_ai.c:(.text+0x360): first defined here
>> performance.o: In function `atol':
>> performance.c:(.text+0x380): multiple definition of `atol'
>> g_ai.o:g_ai.c:(.text+0x380): first defined here
>> performance.o: In function `atoll':
>> performance.c:(.text+0x390): multiple definition of `atoll'
>> g_ai.o:g_ai.c:(.text+0x390): first defined here
>> ....
>> 
>> All the errors appear to concern multiple definitions of
>> implementation and library symbols/functions.
>
>Have you checked the obvious such as including the the correct standard 
>headers?

Define "correct standard headers".

Some of the standard headers included in the project's main header
are:

#include <assert.h>
#include <float.h>
#include <limits.h>
#include <math.h>
#include <stdio.h>
#include <stdarg.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
#include <ctype.h>
#include <errno.h>

[toc] | [prev] | [next] | [standalone]

#138339

On 28/11/2018 16:53, Geoff wrote:
> On Wed, 28 Nov 2018 15:37:30 +1300, Ian Collins <ian-news@hotmail.com>
> wrote:
> 
>> On 28/11/2018 11:38, Geoff wrote:
>>> First, this isn't a C question but I know there are a lot of
>>> GCC-knowledgeable people in this group so I'm seeking tribal
>>> knowledge.
>>>
>>> This project used to compile without error on a previous version of
>>> Debian but now is failing to link on a newer version. The makefile and
>>> project code have not changed.
>>>
>>> Link failure messages are of the type:
>>> ....
>>> performance.o: In function `atoi':
>>> performance.c:(.text+0x360): multiple definition of `atoi'
>>> g_ai.o:g_ai.c:(.text+0x360): first defined here
>>> performance.o: In function `atol':
>>> performance.c:(.text+0x380): multiple definition of `atol'
>>> g_ai.o:g_ai.c:(.text+0x380): first defined here
>>> performance.o: In function `atoll':
>>> performance.c:(.text+0x390): multiple definition of `atoll'
>>> g_ai.o:g_ai.c:(.text+0x390): first defined here
>>> ....
>>>
>>> All the errors appear to concern multiple definitions of
>>> implementation and library symbols/functions.
>>
>> Have you checked the obvious such as including the the correct standard
>> headers?
> 
> Define "correct standard headers".
> 
> Some of the standard headers included in the project's main header
> are:
> 
> #include <assert.h>
> #include <float.h>
> #include <limits.h>
> #include <math.h>
> #include <stdio.h>
> #include <stdarg.h>
> #include <string.h>
> #include <stdlib.h>

Fine, you have <stdlib.h>.  The question is, what's in performance.c? 
Is there another atoi?

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#138340

On Wed, 28 Nov 2018 17:42:29 +1300, Ian Collins <ian-news@hotmail.com>
wrote:

>On 28/11/2018 16:53, Geoff wrote:
>> On Wed, 28 Nov 2018 15:37:30 +1300, Ian Collins <ian-news@hotmail.com>
>> wrote:
>> 
>>> On 28/11/2018 11:38, Geoff wrote:
>>>> First, this isn't a C question but I know there are a lot of
>>>> GCC-knowledgeable people in this group so I'm seeking tribal
>>>> knowledge.
>>>>
>>>> This project used to compile without error on a previous version of
>>>> Debian but now is failing to link on a newer version. The makefile and
>>>> project code have not changed.
>>>>
>>>> Link failure messages are of the type:
>>>> ....
>>>> performance.o: In function `atoi':
>>>> performance.c:(.text+0x360): multiple definition of `atoi'
>>>> g_ai.o:g_ai.c:(.text+0x360): first defined here
>>>> performance.o: In function `atol':
>>>> performance.c:(.text+0x380): multiple definition of `atol'
>>>> g_ai.o:g_ai.c:(.text+0x380): first defined here
>>>> performance.o: In function `atoll':
>>>> performance.c:(.text+0x390): multiple definition of `atoll'
>>>> g_ai.o:g_ai.c:(.text+0x390): first defined here
>>>> ....
>>>>
>>>> All the errors appear to concern multiple definitions of
>>>> implementation and library symbols/functions.
>>>
>>> Have you checked the obvious such as including the the correct standard
>>> headers?
>> 
>> Define "correct standard headers".
>> 
>> Some of the standard headers included in the project's main header
>> are:
>> 
>> #include <assert.h>
>> #include <float.h>
>> #include <limits.h>
>> #include <math.h>
>> #include <stdio.h>
>> #include <stdarg.h>
>> #include <string.h>
>> #include <stdlib.h>
>
>Fine, you have <stdlib.h>.  The question is, what's in performance.c? 
>Is there another atoi?

None that I can see...
It devolves to a printf call in Linux.

// **********************************************
//        Windows high performance counter
// **********************************************

// this version outputs to the debugger window
// instead of to the console log.

#include "g_local.h"
#include "performance.h"

#ifdef _WIN32
#ifdef _DEBUG

#define WIN32_LEAN_AND_MEAN

#include <windows.h>
#include <stdio.h>

LARGE_INTEGER start;
double totalTime = 0;

void _START_PERFORMANCE_TIMER (void)
{
	QueryPerformanceCounter (&start);
}

void _STOP_PERFORMANCE_TIMER (char* str)
{
	double res;
	LARGE_INTEGER stop;
	__int64 diff;
	LARGE_INTEGER freq;
	char string[64];

	QueryPerformanceCounter (&stop);
	QueryPerformanceFrequency (&freq);
	diff = stop.QuadPart - start.QuadPart;
	res = ((double)((double)diff / (double)freq.QuadPart));
	sprintf(string, "%s executed in %.6f secs.\n", str, res);
	OutputDebugString(string);
	//	Com_Printf (string);
	totalTime += res;
}
#endif
#endif

#ifdef _DEBUG
#define DEBUG
#endif

/* Use this function to trace execution or whatever.
 This improves upon OutputDebugString a bit
 to allow var_args instead of static text.
 Outputs to the debugger and allows
 us to write: DbgPrintf("%s was called.\n", __func__);
 Use Quake 2's gi.dprintf to output to the Quake 2 console.
 In Linux, this function becomes a call to gi.dprintf but
 it outputs only if developer cvar is set.
 */
void DbgPrintf (char *msg, ...)
{
	va_list	argptr;
	char	text[1024];

	va_start (argptr, msg);
	vsnprintf (text, sizeof(text), msg, argptr);
	va_end (argptr);
#ifdef _WIN32
#ifdef DEBUG
	OutputDebugString(text);
#endif /* _DEBUG */
#else // Not WIN32
	  	if(developer->value)
		gi.dprintf(text);
#endif /* _WIN32 */
}

[toc] | [prev] | [next] | [standalone]

#138342

On 28/11/2018 19:06, Geoff wrote:
> On Wed, 28 Nov 2018 17:42:29 +1300, Ian Collins <ian-news@hotmail.com>
> wrote:
> 
>> On 28/11/2018 16:53, Geoff wrote:
>>> On Wed, 28 Nov 2018 15:37:30 +1300, Ian Collins <ian-news@hotmail.com>
>>> wrote:
>>>
>>>> On 28/11/2018 11:38, Geoff wrote:
>>>>> First, this isn't a C question but I know there are a lot of
>>>>> GCC-knowledgeable people in this group so I'm seeking tribal
>>>>> knowledge.
>>>>>
>>>>> This project used to compile without error on a previous version of
>>>>> Debian but now is failing to link on a newer version. The makefile and
>>>>> project code have not changed.
>>>>>
>>>>> Link failure messages are of the type:
>>>>> ....
>>>>> performance.o: In function `atoi':
>>>>> performance.c:(.text+0x360): multiple definition of `atoi'
>>>>> g_ai.o:g_ai.c:(.text+0x360): first defined here
>>>>> performance.o: In function `atol':
>>>>> performance.c:(.text+0x380): multiple definition of `atol'
>>>>> g_ai.o:g_ai.c:(.text+0x380): first defined here
>>>>> performance.o: In function `atoll':
>>>>> performance.c:(.text+0x390): multiple definition of `atoll'
>>>>> g_ai.o:g_ai.c:(.text+0x390): first defined here
>>>>> ....
>>>>>
>>>>> All the errors appear to concern multiple definitions of
>>>>> implementation and library symbols/functions.
>>>>
>>>> Have you checked the obvious such as including the the correct standard
>>>> headers?
>>>
>>> Define "correct standard headers".
>>>
>>> Some of the standard headers included in the project's main header
>>> are:
>>>
>>> #include <assert.h>
>>> #include <float.h>
>>> #include <limits.h>
>>> #include <math.h>
>>> #include <stdio.h>
>>> #include <stdarg.h>
>>> #include <string.h>
>>> #include <stdlib.h>
>>
>> Fine, you have <stdlib.h>.  The question is, what's in performance.c?
>> Is there another atoi?
>
> None that I can see...
> It devolves to a printf call in Linux
OK, I assume there's a g_ai.c somewhere, could there be another 
definition there?  Do both files include <stdlib.h>?

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#138374

On Wed, 28 Nov 2018 20:45:10 +1300, Ian Collins <ian-news@hotmail.com>
wrote:

>On 28/11/2018 19:06, Geoff wrote:
>> On Wed, 28 Nov 2018 17:42:29 +1300, Ian Collins <ian-news@hotmail.com>
>> wrote:
>> 
>>> On 28/11/2018 16:53, Geoff wrote:
>>>> On Wed, 28 Nov 2018 15:37:30 +1300, Ian Collins <ian-news@hotmail.com>
>>>> wrote:
>>>>
>>>>> On 28/11/2018 11:38, Geoff wrote:
>>>>>> First, this isn't a C question but I know there are a lot of
>>>>>> GCC-knowledgeable people in this group so I'm seeking tribal
>>>>>> knowledge.
>>>>>>
>>>>>> This project used to compile without error on a previous version of
>>>>>> Debian but now is failing to link on a newer version. The makefile and
>>>>>> project code have not changed.
>>>>>>
>>>>>> Link failure messages are of the type:
>>>>>> ....
>>>>>> performance.o: In function `atoi':
>>>>>> performance.c:(.text+0x360): multiple definition of `atoi'
>>>>>> g_ai.o:g_ai.c:(.text+0x360): first defined here
>>>>>> performance.o: In function `atol':
>>>>>> performance.c:(.text+0x380): multiple definition of `atol'
>>>>>> g_ai.o:g_ai.c:(.text+0x380): first defined here
>>>>>> performance.o: In function `atoll':
>>>>>> performance.c:(.text+0x390): multiple definition of `atoll'
>>>>>> g_ai.o:g_ai.c:(.text+0x390): first defined here
>>>>>> ....
>>>>>>
>>>>>> All the errors appear to concern multiple definitions of
>>>>>> implementation and library symbols/functions.
>>>>>
>>>>> Have you checked the obvious such as including the the correct standard
>>>>> headers?
>>>>
>>>> Define "correct standard headers".
>>>>
>>>> Some of the standard headers included in the project's main header
>>>> are:
>>>>
>>>> #include <assert.h>
>>>> #include <float.h>
>>>> #include <limits.h>
>>>> #include <math.h>
>>>> #include <stdio.h>
>>>> #include <stdarg.h>
>>>> #include <string.h>
>>>> #include <stdlib.h>
>>>
>>> Fine, you have <stdlib.h>.  The question is, what's in performance.c?
>>> Is there another atoi?
>>
>> None that I can see...
>> It devolves to a printf call in Linux
>OK, I assume there's a g_ai.c somewhere, could there be another 
>definition there?  Do both files include <stdlib.h>?

No element of the project /defines/ these functions, which is why I'm
mystified as to why the code is suddenly broken with an upgrade of the
OS & compiler. All the .c files include a master header that includes
the standard headers you see listed above. It's quite possible a
standard header might be included more than once but it was my
understanding they were all required to be idempotent for that
translation unit. Nevertheless, I will review and remove any redundant
includes.

There are macro guards installed in all the project headers so no .c
file can include any project header more than once. The makefile and
all project code has not changed since compiling and linking correctly
on the old OS. g_ai.c is the first module compiled but atoi is not
called or defined within g_ai.c.

Here is the beginning of the link:
g_chase.o: In function `__signbitf':
g_chase.c:(.text+0x0): multiple definition of `__signbitf'
g_ai.o:g_ai.c:(.text+0x0): first defined here
g_chase.o: In function `__signbit':
g_chase.c:(.text+0x10): multiple definition of `__signbit'
g_ai.o:g_ai.c:(.text+0x10): first defined here
g_chase.o: In function `__signbitl':
g_chase.c:(.text+0x20): multiple definition of `__signbitl'
g_ai.o:g_ai.c:(.text+0x20): first defined here
g_chase.o: In function `vprintf':
g_chase.c:(.text+0x40): multiple definition of `vprintf'
g_ai.o:g_ai.c:(.text+0x40): first defined here
g_chase.o: In function `getchar':
g_chase.c:(.text+0x60): multiple definition of `getchar'
g_ai.o:g_ai.c:(.text+0x60): first defined here
 

It appears to me as though pulling in one of the standard headers is
causing linking of numerous library functions into each of the
component modules, even when using the -o and -c switches for that
module. This is supposed to be a dll project.

The multiply defined functions are not confined to only the elements
touched by performance.c so it is not the root cause. I have another
project of the same type that includes a functionally identical
performance.c/performance.h module and that project links correctly on
the same system. I chose the section of the error output near the end
of the stream so that's why performance.c is the focus but it is not
the cause. It starts early on in the link and this is only one
example, in retrospect, it's probably not a good choice. I can post
the complete dump if you feel it might be useful.

All the modules compile without errors but -Wall and -pedantic are not
set due to numerous unused variables within many functions that have
not been cleaned up. This is on the to-do list.

Interestingly, I have solved the linking problem by setting -std=gnu89
instead of -std=gnu99. Now, what's different (besides 10 years) about
the nature of the compiler with those switches? Why did it work on the
old Debian 6 and not on Debian 9? This single change made it work.

[toc] | [prev] | [next] | [standalone]

#138376

On Wednesday, November 28, 2018 at 1:30:56 PM UTC-5, Geoff wrote:
> On Wed, 28 Nov 2018 20:45:10 +1300, Ian Collins <ian-news@hotmail.com>
> wrote:
...
> >OK, I assume there's a g_ai.c somewhere, could there be another 
> >definition there?  Do both files include <stdlib.h>?
> 
> No element of the project /defines/ these functions, which is why I'm
> mystified as to why the code is suddenly broken with an upgrade of the
> OS & compiler. All the .c files include a master header that includes
> the standard headers you see listed above. It's quite possible a
> standard header might be included more than once but it was my
> understanding they were all required to be idempotent for that
> translation unit. Nevertheless, I will review and remove any redundant
> includes.
> 
> There are macro guards installed in all the project headers so no .c
> file can include any project header more than once. The makefile and
> all project code has not changed since compiling and linking correctly
> on the old OS. g_ai.c is the first module compiled but atoi is not
> called or defined within g_ai.c.
...
> Interestingly, I have solved the linking problem by setting -std=gnu89
> instead of -std=gnu99. Now, what's different (besides 10 years) about
> the nature of the compiler with those switches?

Rebuild any one of the modules which provokes this message, using
-std=gnu99 -E, and using -o to name the output file. Look in the output
file and see if it contains anything that looks, syntactically at least,
like a definition of one of the relevant functions, rather than a
declaration.
Note that, since you're compiling as GnuC, rather than C, it would be
more appropriate to ask this question in a Gnu-oriented forum. GnuC
differs from C in many ways, and you'll get better answers if you ask
people who are more familiar with those differences than I am.

[toc] | [prev] | [next] | [standalone]

#138388

On Wed, 28 Nov 2018 11:01:46 -0800 (PST),
jameskuyper@alumni.caltech.edu wrote:

>On Wednesday, November 28, 2018 at 1:30:56 PM UTC-5, Geoff wrote:
>> On Wed, 28 Nov 2018 20:45:10 +1300, Ian Collins <ian-news@hotmail.com>
>> wrote:
>...
>> >OK, I assume there's a g_ai.c somewhere, could there be another 
>> >definition there?  Do both files include <stdlib.h>?
>> 
>> No element of the project /defines/ these functions, which is why I'm
>> mystified as to why the code is suddenly broken with an upgrade of the
>> OS & compiler. All the .c files include a master header that includes
>> the standard headers you see listed above. It's quite possible a
>> standard header might be included more than once but it was my
>> understanding they were all required to be idempotent for that
>> translation unit. Nevertheless, I will review and remove any redundant
>> includes.
>> 
>> There are macro guards installed in all the project headers so no .c
>> file can include any project header more than once. The makefile and
>> all project code has not changed since compiling and linking correctly
>> on the old OS. g_ai.c is the first module compiled but atoi is not
>> called or defined within g_ai.c.
>...
>> Interestingly, I have solved the linking problem by setting -std=gnu89
>> instead of -std=gnu99. Now, what's different (besides 10 years) about
>> the nature of the compiler with those switches?
>
>Rebuild any one of the modules which provokes this message, using
>-std=gnu99 -E, and using -o to name the output file. Look in the output
>file and see if it contains anything that looks, syntactically at least,
>like a definition of one of the relevant functions, rather than a
>declaration.
>Note that, since you're compiling as GnuC, rather than C, it would be
>more appropriate to ask this question in a Gnu-oriented forum. GnuC
>differs from C in many ways, and you'll get better answers if you ask
>people who are more familiar with those differences than I am.

The -E switch disclosed the nature of the problem. 
The implementation is inlining the functions in conflict. Example:

extern __inline int
 atoi (const char *__nptr)
{
  return (int) strtol (__nptr, (char **) ((void *)0), 10);
}

etc...

[toc] | [prev] | [next] | [standalone]

#138393

On 11/29/18 04:35, Geoff wrote:
> On Wed, 28 Nov 2018 11:01:46 -0800 (PST),
> jameskuyper@alumni.caltech.edu wrote:
> 
>> On Wednesday, November 28, 2018 at 1:30:56 PM UTC-5, Geoff wrote:
>>> On Wed, 28 Nov 2018 20:45:10 +1300, Ian Collins <ian-news@hotmail.com>
>>> wrote:
>> ...
>>>> OK, I assume there's a g_ai.c somewhere, could there be another 
>>>> definition there?  Do both files include <stdlib.h>?
>>>
>>> No element of the project /defines/ these functions, which is why I'm
>>> mystified as to why the code is suddenly broken with an upgrade of the
>>> OS & compiler. All the .c files include a master header that includes
>>> the standard headers you see listed above. It's quite possible a
>>> standard header might be included more than once but it was my
>>> understanding they were all required to be idempotent for that
>>> translation unit. Nevertheless, I will review and remove any redundant
>>> includes.
>>>
>>> There are macro guards installed in all the project headers so no .c
>>> file can include any project header more than once. The makefile and
>>> all project code has not changed since compiling and linking correctly
>>> on the old OS. g_ai.c is the first module compiled but atoi is not
>>> called or defined within g_ai.c.
>> ...
>>> Interestingly, I have solved the linking problem by setting -std=gnu89
>>> instead of -std=gnu99. Now, what's different (besides 10 years) about
>>> the nature of the compiler with those switches?
>>
>> Rebuild any one of the modules which provokes this message, using
>> -std=gnu99 -E, and using -o to name the output file. Look in the output
>> file and see if it contains anything that looks, syntactically at least,
>> like a definition of one of the relevant functions, rather than a
>> declaration.
>> Note that, since you're compiling as GnuC, rather than C, it would be
>> more appropriate to ask this question in a Gnu-oriented forum. GnuC
>> differs from C in many ways, and you'll get better answers if you ask
>> people who are more familiar with those differences than I am.
> 
> The -E switch disclosed the nature of the problem. 
> The implementation is inlining the functions in conflict. Example:
> 
> extern __inline int
>  atoi (const char *__nptr)
> {
>   return (int) strtol (__nptr, (char **) ((void *)0), 10);
> }

User code containing such a definition would have undefined behavior by
reason of defining a reserved identifier, so a C compiler is free to
reject such code. However, a standard header, which is part of the
implementation, could contain such code - but it can combine with a C
compiler to form a conforming implementation of C only if the C compiler
does not reject such code, when it is #included from a standard header.
I suspect that the underlying problem is that you're using an
implementation of the C standard library that isn't compatible with the
gcc -std=gnu99, but is compatible with gcc -std=gnu89.

[toc] | [prev] | [next] | [standalone]

#138446

On Thu, 29 Nov 2018 08:15:20 -0500, James Kuyper
<jameskuyper@alumni.caltech.edu> wrote:

>On 11/29/18 04:35, Geoff wrote:
>> On Wed, 28 Nov 2018 11:01:46 -0800 (PST),
>> jameskuyper@alumni.caltech.edu wrote:
>> 
>>> On Wednesday, November 28, 2018 at 1:30:56 PM UTC-5, Geoff wrote:
>>>> On Wed, 28 Nov 2018 20:45:10 +1300, Ian Collins <ian-news@hotmail.com>
>>>> wrote:
>>> ...
>>>>> OK, I assume there's a g_ai.c somewhere, could there be another 
>>>>> definition there?  Do both files include <stdlib.h>?
>>>>
>>>> No element of the project /defines/ these functions, which is why I'm
>>>> mystified as to why the code is suddenly broken with an upgrade of the
>>>> OS & compiler. All the .c files include a master header that includes
>>>> the standard headers you see listed above. It's quite possible a
>>>> standard header might be included more than once but it was my
>>>> understanding they were all required to be idempotent for that
>>>> translation unit. Nevertheless, I will review and remove any redundant
>>>> includes.
>>>>
>>>> There are macro guards installed in all the project headers so no .c
>>>> file can include any project header more than once. The makefile and
>>>> all project code has not changed since compiling and linking correctly
>>>> on the old OS. g_ai.c is the first module compiled but atoi is not
>>>> called or defined within g_ai.c.
>>> ...
>>>> Interestingly, I have solved the linking problem by setting -std=gnu89
>>>> instead of -std=gnu99. Now, what's different (besides 10 years) about
>>>> the nature of the compiler with those switches?
>>>
>>> Rebuild any one of the modules which provokes this message, using
>>> -std=gnu99 -E, and using -o to name the output file. Look in the output
>>> file and see if it contains anything that looks, syntactically at least,
>>> like a definition of one of the relevant functions, rather than a
>>> declaration.
>>> Note that, since you're compiling as GnuC, rather than C, it would be
>>> more appropriate to ask this question in a Gnu-oriented forum. GnuC
>>> differs from C in many ways, and you'll get better answers if you ask
>>> people who are more familiar with those differences than I am.
>> 
>> The -E switch disclosed the nature of the problem. 
>> The implementation is inlining the functions in conflict. Example:
>> 
>> extern __inline int
>>  atoi (const char *__nptr)
>> {
>>   return (int) strtol (__nptr, (char **) ((void *)0), 10);
>> }
>
>User code containing such a definition would have undefined behavior by
>reason of defining a reserved identifier, so a C compiler is free to
>reject such code. However, a standard header, which is part of the
>implementation, could contain such code - but it can combine with a C
>compiler to form a conforming implementation of C only if the C compiler
>does not reject such code, when it is #included from a standard header.
>I suspect that the underlying problem is that you're using an
>implementation of the C standard library that isn't compatible with the
>gcc -std=gnu99, but is compatible with gcc -std=gnu89.


-O0 turns it off, as expected. -fno-inline as well. Any optimization
level 1 or above causes it. 

What's especially interesting is I have six other projects all
implemented with essentially the same makefile recipes and all
unchanged since instantiation on the older OS more than 5 years ago
and this project is the only one that is broken. The other projects
build without problems. This, and the other projects all compile
correctly on Ubuntu, CentOS, Windows 10 and MacOS with their tools.

Setting -I/usr/include doesn't help. 
 
Setting -std=c89 or c99 is equally broken, inlining still occurs. The
library functions are inlined as before.  It's broken compiling for
i386 and x86_64. Only setting -std=gnu89 or turning off optimizations
prevents the inlining.

I'm convinced my code is evoking this behavior from the tool set and I
will have to go through a complete review of the structure of the
project to find it.

If I can produce a simple project that reproduces this result I'll
post it.

Thanks for all the help.

I don't hack configurations but here's a dump for anyone who might be
interested.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++
--prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin
--enable-default-pie --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

[toc] | [prev] | [next] | [standalone]

#138452

On Fri, 30 Nov 2018 12:48:19 -0800, Geoff <geoff@invalid.invalid>
wrote:

>If I can produce a simple project that reproduces this result I'll
>post it.
>
>Thanks for all the help.

I found the error. One of the project headers, invoked by all the
modules had this at the very top:

#define __attribute__ (x)

This will probably hose over just about any implementation and I'm
surprised this problem didn't show up a long time ago. It sneaked into
the code somewhere between 2010 and 2013. I blame Obama. :-)

[toc] | [prev] | [next] | [standalone]

#138453

Geoff <geoff@invalid.invalid> writes:
> On Fri, 30 Nov 2018 12:48:19 -0800, Geoff <geoff@invalid.invalid>
> wrote:
>
>>If I can produce a simple project that reproduces this result I'll
>>post it.
>>
>>Thanks for all the help.
>
> I found the error. One of the project headers, invoked by all the
> modules had this at the very top:
>
> #define __attribute__ (x)
>
> This will probably hose over just about any implementation and I'm
> surprised this problem didn't show up a long time ago. It sneaked into
> the code somewhere between 2010 and 2013. I blame Obama. :-)

I suspect it was actually

#define __attribute__(x)

without the space.  Normally __attribute__ (a common non-standard
extension) takes a doubly parenthesized argument, such as __attribute__
((packed))

The latter macro definition would remove all uses of __attribute__
(which would of course break any code that depends on it).

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#138455

On Fri, 30 Nov 2018 14:56:05 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>I suspect it was actually
>
>#define __attribute__(x)

You are correct. I typed it incorrectly in the post.

[toc] | [prev] | [next] | [standalone]

#138466

On 30/11/2018 23:56, Keith Thompson wrote:
> Geoff <geoff@invalid.invalid> writes:
>> On Fri, 30 Nov 2018 12:48:19 -0800, Geoff <geoff@invalid.invalid>
>> wrote:
>>
>>> If I can produce a simple project that reproduces this result I'll
>>> post it.
>>>
>>> Thanks for all the help.
>>
>> I found the error. One of the project headers, invoked by all the
>> modules had this at the very top:
>>
>> #define __attribute__ (x)
>>
>> This will probably hose over just about any implementation and I'm
>> surprised this problem didn't show up a long time ago. It sneaked into
>> the code somewhere between 2010 and 2013. I blame Obama. :-)
> 
> I suspect it was actually
> 
> #define __attribute__(x)
> 
> without the space.  Normally __attribute__ (a common non-standard
> extension) takes a doubly parenthesized argument, such as __attribute__
> ((packed))
> 
> The latter macro definition would remove all uses of __attribute__
> (which would of course break any code that depends on it).
> 

Most, but not all, uses of __attribute__ are not necessary for correct 
code.  They improve optimisation, or error checking (such as checking 
formats in printf-like functions, or marking parameters as non-null). 
So often this define is with conditional compilation - if the compiler 
is gcc (or a mostly compatible alternative, like clang), you get more 
efficient code or better checking during development, and for other 
compilers you get code without this extension.

[toc] | [prev] | [next] | [standalone]

#138472

On 12/1/18 11:51 AM, David Brown wrote:
> On 30/11/2018 23:56, Keith Thompson wrote:
>> Geoff <geoff@invalid.invalid> writes:
>>> On Fri, 30 Nov 2018 12:48:19 -0800, Geoff <geoff@invalid.invalid>
>>> wrote:
>>>
>>>> If I can produce a simple project that reproduces this result I'll
>>>> post it.
>>>>
>>>> Thanks for all the help.
>>>
>>> I found the error. One of the project headers, invoked by all the
>>> modules had this at the very top:
>>>
>>> #define __attribute__ (x)
>>>
>>> This will probably hose over just about any implementation and I'm
>>> surprised this problem didn't show up a long time ago. It sneaked into
>>> the code somewhere between 2010 and 2013. I blame Obama. :-)
>>
>> I suspect it was actually
>>
>> #define __attribute__(x)
>>
>> without the space.  Normally __attribute__ (a common non-standard
>> extension) takes a doubly parenthesized argument, such as __attribute__
>> ((packed))
>>
>> The latter macro definition would remove all uses of __attribute__
>> (which would of course break any code that depends on it).
>>
> 
> Most, but not all, uses of __attribute__ are not necessary for correct
> code.  They improve optimisation, or error checking (such as checking
> formats in printf-like functions, or marking parameters as non-null). So
> often this define is with conditional compilation - if the compiler is
> gcc (or a mostly compatible alternative, like clang), you get more
> efficient code or better checking during development, and for other
> compilers you get code without this extension.

I suppose most is a matter of opinion. I suspect my most used would be
__attribute__((interrupt)) which definitively might make a difference
between working and non-working code (except on the Cortex-M series
where the hardware was defined to do what was needed automatically for
ISRs).

The next most common is likely __attribute__((weak)) which if ignored
would results in Undefined Behavior that tends to result in link errors.

You example of __attribute__((packed)) is another example where ignoring
the option will often yield incorrect code if it is being used to make a
structure to exactly match an externally defined structure that has
fields not properly aligned for the processor being used.

Yes, some usages of __attribute__ are just hints, but in my mind
#define __attribute__(x)
is a sign of a quick fix being applied that may be hiding a bigger issue.

[toc] | [prev] | [next] | [standalone]

#138476

On 01/12/2018 19:37, Richard Damon wrote:
> On 12/1/18 11:51 AM, David Brown wrote:
>> On 30/11/2018 23:56, Keith Thompson wrote:
>>> Geoff <geoff@invalid.invalid> writes:
>>>> On Fri, 30 Nov 2018 12:48:19 -0800, Geoff <geoff@invalid.invalid>
>>>> wrote:
>>>>
>>>>> If I can produce a simple project that reproduces this result I'll
>>>>> post it.
>>>>>
>>>>> Thanks for all the help.
>>>>
>>>> I found the error. One of the project headers, invoked by all the
>>>> modules had this at the very top:
>>>>
>>>> #define __attribute__ (x)
>>>>
>>>> This will probably hose over just about any implementation and I'm
>>>> surprised this problem didn't show up a long time ago. It sneaked into
>>>> the code somewhere between 2010 and 2013. I blame Obama. :-)
>>>
>>> I suspect it was actually
>>>
>>> #define __attribute__(x)
>>>
>>> without the space.  Normally __attribute__ (a common non-standard
>>> extension) takes a doubly parenthesized argument, such as __attribute__
>>> ((packed))
>>>
>>> The latter macro definition would remove all uses of __attribute__
>>> (which would of course break any code that depends on it).
>>>
>>
>> Most, but not all, uses of __attribute__ are not necessary for correct
>> code.  They improve optimisation, or error checking (such as checking
>> formats in printf-like functions, or marking parameters as non-null). So
>> often this define is with conditional compilation - if the compiler is
>> gcc (or a mostly compatible alternative, like clang), you get more
>> efficient code or better checking during development, and for other
>> compilers you get code without this extension.
> 
> I suppose most is a matter of opinion.

Yes - and of how you count them, and by the kind of code you write.

> I suspect my most used would be
> __attribute__((interrupt)) which definitively might make a difference
> between working and non-working code (except on the Cortex-M series
> where the hardware was defined to do what was needed automatically for
> ISRs).

Attributes like "interrupt" certainly do make a difference to how the 
code works.  Such code is rarely very portable, however.

> 
> The next most common is likely __attribute__((weak)) which if ignored
> would results in Undefined Behavior that tends to result in link errors.
> 
> You example of __attribute__((packed)) is another example where ignoring
> the option will often yield incorrect code if it is being used to make a
> structure to exactly match an externally defined structure that has
> fields not properly aligned for the processor being used.
> 
> Yes, some usages of __attribute__ are just hints, but in my mind
> #define __attribute__(x)
> is a sign of a quick fix being applied that may be hiding a bigger issue.
> 

Agreed.

My preference is to have things like:

	#define alwaysInline __attribute__((always_inline))

Then use the "alwaysInline" macro in the code, rather than using 
__attribute__ directly.  With this sort of abstraction, it is a lot 
easier to get portable code (at least, to make the bits that /can/ be 
portable, portable).

But /if/ you see the line "#define __attribute__(x)", it is usually for 
such making code acceptable to compilers other than gcc (or its 
friends).  It might be for a tool like doxygen, rather than another 
compiler.

[toc] | [prev] | [next] | [standalone]

#138480

On 12/2/18 6:49 AM, David Brown wrote:
> On 01/12/2018 19:37, Richard Damon wrote:
>> On 12/1/18 11:51 AM, David Brown wrote:
>>> On 30/11/2018 23:56, Keith Thompson wrote:
>>>> Geoff <geoff@invalid.invalid> writes:
>>>>> On Fri, 30 Nov 2018 12:48:19 -0800, Geoff <geoff@invalid.invalid>
>>>>> wrote:
>>>>>
>>>>>> If I can produce a simple project that reproduces this result I'll
>>>>>> post it.
>>>>>>
>>>>>> Thanks for all the help.
>>>>>
>>>>> I found the error. One of the project headers, invoked by all the
>>>>> modules had this at the very top:
>>>>>
>>>>> #define __attribute__ (x)
>>>>>
>>>>> This will probably hose over just about any implementation and I'm
>>>>> surprised this problem didn't show up a long time ago. It sneaked into
>>>>> the code somewhere between 2010 and 2013. I blame Obama. :-)
>>>>
>>>> I suspect it was actually
>>>>
>>>> #define __attribute__(x)
>>>>
>>>> without the space.  Normally __attribute__ (a common non-standard
>>>> extension) takes a doubly parenthesized argument, such as __attribute__
>>>> ((packed))
>>>>
>>>> The latter macro definition would remove all uses of __attribute__
>>>> (which would of course break any code that depends on it).
>>>>
>>>
>>> Most, but not all, uses of __attribute__ are not necessary for correct
>>> code.  They improve optimisation, or error checking (such as checking
>>> formats in printf-like functions, or marking parameters as non-null). So
>>> often this define is with conditional compilation - if the compiler is
>>> gcc (or a mostly compatible alternative, like clang), you get more
>>> efficient code or better checking during development, and for other
>>> compilers you get code without this extension.
>>
>> I suppose most is a matter of opinion.
> 
> Yes - and of how you count them, and by the kind of code you write.
> 
>> I suspect my most used would be
>> __attribute__((interrupt)) which definitively might make a difference
>> between working and non-working code (except on the Cortex-M series
>> where the hardware was defined to do what was needed automatically for
>> ISRs).
> 
> Attributes like "interrupt" certainly do make a difference to how the
> code works.  Such code is rarely very portable, however.
> 
>>
>> The next most common is likely __attribute__((weak)) which if ignored
>> would results in Undefined Behavior that tends to result in link errors.
>>
>> You example of __attribute__((packed)) is another example where ignoring
>> the option will often yield incorrect code if it is being used to make a
>> structure to exactly match an externally defined structure that has
>> fields not properly aligned for the processor being used.
>>
>> Yes, some usages of __attribute__ are just hints, but in my mind
>> #define __attribute__(x)
>> is a sign of a quick fix being applied that may be hiding a bigger issue.
>>
> 
> Agreed.
> 
> My preference is to have things like:
> 
>     #define alwaysInline __attribute__((always_inline))
> 
> Then use the "alwaysInline" macro in the code, rather than using
> __attribute__ directly.  With this sort of abstraction, it is a lot
> easier to get portable code (at least, to make the bits that /can/ be
> portable, portable).
> 
> But /if/ you see the line "#define __attribute__(x)", it is usually for
> such making code acceptable to compilers other than gcc (or its
> friends).  It might be for a tool like doxygen, rather than another
> compiler.

Yes, creating defines for particular attributes makes things more
portable, and then you can have a header that defines them based on the
detected compiler. Something like:

#if defined(GCC)
#define ALWAYS_INLINE __attribute__((always_inline))
#elif define(OTHER_CC)
#define ALWAYS_INLINE
#else
#error Unknow Compiler
#endif

(I use all caps for macros, and always add the else #error case to catch
that problem)

I will still say that for code that didn't do this, blanket removal with
a #define is likely going to produce non-working (even if it gives a
clean compile) code.

For tools like Doxygen, you can either conditionally define it based on
this being a Doxygen run, or put that definition in the Doxygen config.
Putting it as a bare #define that other systems will see is still wrong.

[toc] | [prev] | [next] | [standalone]

#138481

On 02/12/2018 14:16, Richard Damon wrote:
> On 12/2/18 6:49 AM, David Brown wrote:
>> On 01/12/2018 19:37, Richard Damon wrote:
<snip>
>>> Yes, some usages of __attribute__ are just hints, but in my mind
>>> #define __attribute__(x)
>>> is a sign of a quick fix being applied that may be hiding a bigger issue.
>>>
>>
>> Agreed.
>>
>> My preference is to have things like:
>>
>>      #define alwaysInline __attribute__((always_inline))
>>
>> Then use the "alwaysInline" macro in the code, rather than using
>> __attribute__ directly.  With this sort of abstraction, it is a lot
>> easier to get portable code (at least, to make the bits that /can/ be
>> portable, portable).
>>
>> But /if/ you see the line "#define __attribute__(x)", it is usually for
>> such making code acceptable to compilers other than gcc (or its
>> friends).  It might be for a tool like doxygen, rather than another
>> compiler.
> 
> Yes, creating defines for particular attributes makes things more
> portable, and then you can have a header that defines them based on the
> detected compiler. Something like:
> 
> #if defined(GCC)
> #define ALWAYS_INLINE __attribute__((always_inline))
> #elif define(OTHER_CC)
> #define ALWAYS_INLINE
> #else
> #error Unknow Compiler
> #endif
> 
> (I use all caps for macros, and always add the else #error case to catch
> that problem)

Yes, that's the way to do it.  Often I know my code is not going to be 
very portable (at least in parts), and that portability is simply not a 
concern.  So then it's enough to write:

#ifndef __GNUC__
#error This code has only been tested with gcc!
#endif

Still, I keep the defines for attributes because it makes any future 
porting easier (there's a difference between making code that is 
portable, and making code that can be ported), and can make the code 
clearer.  And even if you don't want to use a different compiler with 
the code, you might still want to use doxygen or other tools.

(I know all-caps is traditional for preprocessor macros, but I am not a 
big fan of them.  I use all-caps in cases where it is vital to know that 
you have a macro - such as for avoiding "x = MAX(y++, foo());" - and for 
macros defined on the command line.)

> 
> I will still say that for code that didn't do this, blanket removal with
> a #define is likely going to produce non-working (even if it gives a
> clean compile) code.
> 
> For tools like Doxygen, you can either conditionally define it based on
> this being a Doxygen run, or put that definition in the Doxygen config.
> Putting it as a bare #define that other systems will see is still wrong.
> 

[toc] | [prev] | [next] | [standalone]

#138497

On Fri, 30 Nov 2018 12:48:19 -0800, Geoff <geoff@invalid.invalid>
wrote:

>If I can produce a simple project that reproduces this result I'll
>post it.

As promised, here is a small project that reproduces the results.
None of the source files defines or uses any of the inlined functions
yet they are inlined into the object records when compiled.

==== main.c ====

#include "main.h"

int foo(int a);
int bar(int a);

int program_main (void)
{
	int i = 1;
	int j = 2;

	i = foo(i);
	j = bar(j);

	//printf("%i %i\n", i, j);

    return 0;
}


==== main.h ====

/* Comment line below to link the project correctly */
#define __attribute__(x)

#include <assert.h>
#include <float.h>
#include <limits.h>
#include <math.h>
#include <stdio.h>
#include <stdarg.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
#include <ctype.h>
#include <errno.h>

==== foo.c ====

#include "main.h"

int foo(int a)
{
	return (10 * a);
}

==== bar.c ====

#include "main.h"

int bar (int a)
{
	return 10 * a;
}

==== makefile ====

# Requires GNU make

# this nice line comes from the linux kernel makefile
ARCH := $(shell uname -m | sed -e s/i.86/i386/ \
	-e s/sun4u/sparc64/ -e s/arm.*/arm/ \
	-e s/sa110/arm/ -e s/alpha/axp/)

CC = gcc -std=c99 -Wall -Wpedantic

# This is for native build
CFLAGS=-O2 -DARCH="$(ARCH)" -DSTDC_HEADERS
# This is for 32-bit build on 64-bit host
ifeq ($(ARCH),i386)
CFLAGS =-m32 -O2 -DARCH="$(ARCH)" -DSTDC_HEADERS -I/usr/include
endif

# flavors of Linux
ifeq ($(shell uname),Linux)
#SVNDEV := -D'SVN_REV="$(shell svnversion -n .)"'
#CFLAGS += $(SVNDEV)
CFLAGS += -DLINUX
LIBTOOL = ldd
endif

# OS X wants to be Linux and FreeBSD too.
ifeq ($(shell uname),Darwin)
#SVNDEV := -D'SVN_REV="$(shell svnversion -n .)"'
#CFLAGS += $(SVNDEV)
CFLAGS += -DLINUX
LIBTOOL = otool
endif

SHLIBEXT=so
#set position independent code
SHLIBCFLAGS=-fPIC

ORIGDIR=Source

DO_SHLIB_CC=$(CC) $(CFLAGS) $(SHLIBCFLAGS) -o $@ -c $<

.c.o:
	$(DO_SHLIB_CC)

###########################################################
# SETUP AND BUILD
###########################################################

OBJS = main.o foo.o bar.o

program.$(SHLIBEXT) : $(OBJS)
	$(CC) $(CFLAGS) -shared -o $@ $(OBJS) -ldl -lm
	$(LIBTOOL) -r $@


###########################################################
# MISC
###########################################################

clean:
	/bin/rm -f $(OBJS)

depend:
	$(CC) $(CFLAGS) -MM $(OBJS:.o=.c)

depends:
	$(CC) $(CFLAGS) -MM *.c > dependencies

-include dependencies

========= output of make ========= 

make clean
/bin/rm -f main.o foo.o bar.o

make depends
gcc -std=c99 -Wall -Wpedantic -O2 -DARCH="x86_64" -DSTDC_HEADERS
-DLINUX -MM *.c > dependencies

make
gcc -std=c99 -Wall -Wpedantic -O2 -DARCH="x86_64" -DSTDC_HEADERS
-DLINUX -fPIC -o main.o -c main.c
gcc -std=c99 -Wall -Wpedantic -O2 -DARCH="x86_64" -DSTDC_HEADERS
-DLINUX -fPIC -o foo.o -c foo.c
gcc -std=c99 -Wall -Wpedantic -O2 -DARCH="x86_64" -DSTDC_HEADERS
-DLINUX -fPIC -o bar.o -c bar.c
gcc -std=c99 -Wall -Wpedantic -O2 -DARCH="x86_64" -DSTDC_HEADERS
-DLINUX -shared -o program.so main.o foo.o bar.o -ldl -lm
foo.o: In function `__signbitf':
foo.c:(.text+0x0): multiple definition of `__signbitf'
main.o:main.c:(.text+0x0): first defined here
foo.o: In function `__signbit':
foo.c:(.text+0x10): multiple definition of `__signbit'
main.o:main.c:(.text+0x10): first defined here
foo.o: In function `__signbitl':
foo.c:(.text+0x20): multiple definition of `__signbitl'
main.o:main.c:(.text+0x20): first defined here
foo.o: In function `vprintf':
foo.c:(.text+0x40): multiple definition of `vprintf'
main.o:main.c:(.text+0x40): first defined here
foo.o: In function `getchar':
foo.c:(.text+0x60): multiple definition of `getchar'
main.o:main.c:(.text+0x60): first defined here
foo.o: In function `putchar':
foo.c:(.text+0x70): multiple definition of `putchar'
main.o:main.c:(.text+0x70): first defined here
foo.o: In function `__strtok_r_1c':
foo.c:(.text+0x80): multiple definition of `__strtok_r_1c'
main.o:main.c:(.text+0x80): first defined here
foo.o: In function `__strsep_1c':
foo.c:(.text+0xe0): multiple definition of `__strsep_1c'
main.o:main.c:(.text+0xe0): first defined here
foo.o: In function `__strsep_2c':
foo.c:(.text+0x130): multiple definition of `__strsep_2c'
main.o:main.c:(.text+0x130): first defined here
foo.o: In function `__strsep_3c':
foo.c:(.text+0x190): multiple definition of `__strsep_3c'
main.o:main.c:(.text+0x190): first defined here
foo.o: In function `atoi':
foo.c:(.text+0x210): multiple definition of `atoi'
main.o:main.c:(.text+0x210): first defined here
foo.o: In function `atol':
foo.c:(.text+0x230): multiple definition of `atol'
main.o:main.c:(.text+0x230): first defined here
foo.o: In function `atoll':
foo.c:(.text+0x240): multiple definition of `atoll'
main.o:main.c:(.text+0x240): first defined here
foo.o: In function `bsearch':
foo.c:(.text+0x250): multiple definition of `bsearch'
main.o:main.c:(.text+0x250): first defined here
foo.o: In function `atof':
foo.c:(.text+0x2e0): multiple definition of `atof'
main.o:main.c:(.text+0x2e0): first defined here
foo.o: In function `tolower':
foo.c:(.text+0x2f0): multiple definition of `tolower'
main.o:main.c:(.text+0x2f0): first defined here
foo.o: In function `toupper':
foo.c:(.text+0x310): multiple definition of `toupper'
main.o:main.c:(.text+0x310): first defined here
bar.o: In function `__signbitf':
bar.c:(.text+0x0): multiple definition of `__signbitf'
main.o:main.c:(.text+0x0): first defined here
bar.o: In function `__signbit':
bar.c:(.text+0x10): multiple definition of `__signbit'
main.o:main.c:(.text+0x10): first defined here
bar.o: In function `__signbitl':
bar.c:(.text+0x20): multiple definition of `__signbitl'
main.o:main.c:(.text+0x20): first defined here
bar.o: In function `vprintf':
bar.c:(.text+0x40): multiple definition of `vprintf'
main.o:main.c:(.text+0x40): first defined here
bar.o: In function `getchar':
bar.c:(.text+0x60): multiple definition of `getchar'
main.o:main.c:(.text+0x60): first defined here
bar.o: In function `putchar':
bar.c:(.text+0x70): multiple definition of `putchar'
main.o:main.c:(.text+0x70): first defined here
bar.o: In function `__strtok_r_1c':
bar.c:(.text+0x80): multiple definition of `__strtok_r_1c'
main.o:main.c:(.text+0x80): first defined here
bar.o: In function `__strsep_1c':
bar.c:(.text+0xe0): multiple definition of `__strsep_1c'
main.o:main.c:(.text+0xe0): first defined here
bar.o: In function `__strsep_2c':
bar.c:(.text+0x130): multiple definition of `__strsep_2c'
main.o:main.c:(.text+0x130): first defined here
bar.o: In function `__strsep_3c':
bar.c:(.text+0x190): multiple definition of `__strsep_3c'
main.o:main.c:(.text+0x190): first defined here
bar.o: In function `atoi':
bar.c:(.text+0x210): multiple definition of `atoi'
main.o:main.c:(.text+0x210): first defined here
bar.o: In function `atol':
bar.c:(.text+0x230): multiple definition of `atol'
main.o:main.c:(.text+0x230): first defined here
bar.o: In function `atoll':
bar.c:(.text+0x240): multiple definition of `atoll'
main.o:main.c:(.text+0x240): first defined here
bar.o: In function `bsearch':
bar.c:(.text+0x250): multiple definition of `bsearch'
main.o:main.c:(.text+0x250): first defined here
bar.o: In function `atof':
bar.c:(.text+0x2e0): multiple definition of `atof'
main.o:main.c:(.text+0x2e0): first defined here
bar.o: In function `tolower':
bar.c:(.text+0x2f0): multiple definition of `tolower'
main.o:main.c:(.text+0x2f0): first defined here
bar.o: In function `toupper':
bar.c:(.text+0x310): multiple definition of `toupper'
main.o:main.c:(.text+0x310): first defined here
collect2: error: ld returned 1 exit status
makefile:51: recipe for target 'program.so' failed
make[1]: *** [program.so] Error 1
makefile:69: recipe for target 'all' failed
make: *** [all] Error 2

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web