[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] TCC and external variables - am I not seeing somethin

From: Christian Jullien
Subject: Re: [Tinycc-devel] TCC and external variables - am I not seeing something?
Date: Sun, 10 Mar 2013 00:51:14 +0100


The issue you have is not related to TCC, any C compiler will produce this

If you define a variable in a header and you include this header from more
than one translation unit you get this variable define more than once and
linker complains.

-- decl.h
int i = 100;

-- source1.c
#include <decl.h>

-- source2.c
#include <decl.h>

Linker sees I defined twice!

The correct way to do that is to declare i extern (with no value) in include
file and to define it in only one source file

-- decl.h
extern int i; /* no value */

-- source1.c
#include <decl.h>

-- source2.c
#include <decl.h>

int i = 100; /* i is only defined here */


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Aleksandar Kuktin
Sent: dimanche 10 mars 2013 00:31
To: address@hidden
Subject: [Tinycc-devel] TCC and external variables - am I not seeing


I apologize if I am writing to the wrong list. This is really an issue for
something like tinycc-support, but the TCC website does not list any such
maillist (or have I just gone blind?). If there is, infact, such a list,
please direct me to it so I don't spam the -dev list.


I have a problem with TCC and external variables, and right now I am not
sure if I am the one who is not behaving or if it is an issue with TCC.

I should probably mention that I have no formal schooling in neither
programming nor anything computer-science related. I am entirely self-taught
and therefore may be missing an obvious thing or two. So please don't berate
me if that's the case. :)

I am currently working on a solo practice project (open-source, but not yet
published) and I have a number of header files which contain global
variables, (some are ints, some are structs) and I access them from several
functions spread over several source files. System is ELF-Linux-GNU_libc. My
problem is that I can not make TCC link the files into an executable. It
complains (excerpt):

obj/daemon.o: error: 'nbworks_errno' defined twice
obj/daemon.o: error: 'nbworks_do_align' defined twice
obj/daemon.o: error: 'nbworks_rootscope' defined twice
obj/library.o: error: 'nbworks_libcntl' defined twice
obj/library.o: error: 'nbworks_errno' defined twice
obj/library.o: error: 'nbworks_do_align' defined twice
obj/library.o: error: 'nbworks_rootscope' defined twice <<this goes on for
quite a while>>

When linking, obj/daemon.o is preceded by obj/api.o which also uses those
three variables. Ditto for obj/library.o and all the other files.

As far as I am able to understand, when I first compile individual source
files into object files, TCC makes a separate copy of all global variables
for each object file. Then, when it tries to link them together, it
apparently sees the same symbol in multiple files, concludes that there is a
definition conflict and aborts.

Did I get this right? Is there a way to force TCC to link the files?

The compiler I normally use is GCC, which has no problems about linking
these files. But, I am seeing some strange bugs and crashes in my program
and am really starting to wonder if it is all GCCs fault. So I chose to try
a different compiler and see if I can reproduce the errors.
Unfortunately, thats when I ran into this. :(

Header files have this:

typedef int nbworks_errno_t;
/*extern*/ nbworks_errno_t nbworks_errno; typedef unsigned char
nbworks_do_align_t; /*extern*/ nbworks_do_align_t nbworks_do_align;

Source files have this:

struct thread_cache *
  daemon_internal_initializer(struct thread_cache *tcache) {
    extern nbworks_do_align_t nbworks_do_align;
    extern struct nbworks_namsrvc_cntrl_t nbworks_namsrvc_cntrl;
    extern struct nbworks_pruners_cntrl_t nbworks_pruners_cntrl;
    struct thread_cache *result;
    struct rail_params railparams;

    /* blah, blah, blah... */

You don't need an AI for a robot uprising.
Humans will do just fine.

Tinycc-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]