> Sigh. #2 doesn't work as the compiler can synthesize common
> variables that you can't control, and when it does this, things
> won't work. Forcing people to use -single_module strikes me as
> wrong.
I don't know why it was set up like that. Come to think of it, this would
probably be a rea
On Friday, June 10, 2005, at 04:15 PM, Sam Lauber wrote:
#1. I need to tell the linker to use -single_module
#2. Rewrite the code to make a fake initialization
#3. I need to pass -fno-common to the compiler
From a standpoint of just getting the thing deployed, any one of these
three
is right.
> > I'd put this more simply...
> >
> > On Monday, June 6, 2005, at 02:06 PM, Mathieu Malaterre wrote:
> >>I have a question about a valid C code. I am trying to
> >> compile the following code in MacOSX (*). I don't understand
> >> what the problem is?
> >
> > You must use -fno-common when
On Friday, June 10, 2005, at 02:48 PM, Mathieu Malaterre wrote:
Could someone please explain me what is going on?
You didn't use -fno-common.
Can someone please tell me then which one of the three possibilities
is the right one:
#1. I need to tell the linker to use -single_module
#2. Rewrite
On Jun 10, 2005, at 3:45 PM, Mike Stump wrote:
I'd put this more simply...
On Monday, June 6, 2005, at 02:06 PM, Mathieu Malaterre wrote:
I have a question about a valid C code. I am trying to compile the
following code in MacOSX (*). I don't understand what the problem is?
You must use
I'd put this more simply...
On Monday, June 6, 2005, at 02:06 PM, Mathieu Malaterre wrote:
I have a question about a valid C code. I am trying to compile the
following code in MacOSX (*). I don't understand what the problem is?
You must use -fno-common when you are building dynamic librari
> int bar [ 4 * 256 ] = { 0,1,2, ... };
>
> I did not changed nor any compiler option, neither any
> declaration. I still cannot see the difference in between those
> two, since the declaration is exactly the same. The only difference
> being a default initialization.
There is a more subtl
-c foo.c
$ gcc -dynamiclib -o libfoo.dylib foo.o
ld: common symbols not allowed with MH_DYLIB output format with the
-multi_module option
foo.o definition of common _bar (size 4096)
/usr/bin/libtool: internal link edit command failed
using gcc 3.3 20030304 (Apple Computer, Inc. build 1671)
Th
to pass
> -fno-common, right ?
>
> Thanks for your help
> Mathieu
>
> foo.h:
> extern int bar[];
>
> foo.c:
> int bar[4 * 256];
>
> And compile lines are:
> $ gcc -o foo.o -Wall -W -fPIC -c foo.c
> $ gcc -dynamiclib -o libfoo.dylib foo.o
>
to pass
> -fno-common, right ?
>
> Thanks for your help
> Mathieu
>
> foo.h:
> extern int bar[];
>
> foo.c:
> int bar[4 * 256];
>
> And compile lines are:
> $ gcc -o foo.o -Wall -W -fPIC -c foo.c
> $ gcc -dynamiclib -o libfoo.dylib foo.o
>
right ?
Thanks for your help
Mathieu
foo.h:
extern int bar[];
foo.c:
int bar[4 * 256];
And compile lines are:
$ gcc -o foo.o -Wall -W -fPIC-c foo.c
$ gcc -dynamiclib -o libfoo.dylib foo.o
ld: common symbols not allowed with MH_DYLIB output format with the
-multi_module option
foo.o definiti
11 matches
Mail list logo