While trying to build a Mach-O dynamically linked shared library with GPC and LD, I get the following error:
ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_0__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_1__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_2__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_3__ (size 32)
In the Mach-O Runtime Architecture docs I found:
"A common symbol is a symbol that may appear in multiple intermediate object files. The static linker permits multiple common symbol definitions with the same name in input files, and copies the one with the largest size to the final product. If there is an another symbol with the same name as a common symbol, the static linker will ignore the common symbol instead.
The standard C compiler generates a common symbol when it sees a tentative definition—a global variable that has no initializer and is not marked extern. The following line is an example of a tentative definition:
int x;
A shared library cannot have common symbols. To eliminate common symbols in an existing shared library, you must either explicitly define the symbol (with an initialized value, for example) in one of the modules of the shared library, or pass the -fno-common flag to the compiler."
My questions are: 1. Is there something special about symbols for sets ? 2. Would it help to rebuild libgpc.a with the --no-common flag ? 3. Any other ideas or suggestions ?
Regards,
Adriaan van Os
I always prefer to get my code compiling with -Wall without warnings if at all possible. But it seems to be that the capitalisation warning is a little over the top:
program test;
type MyInt = Integer; MyRec = record myint: Integer; end;
begin end.
complains about that capitalisation of myint and MyInt. To me, these two have nothing to do with each other.
I would have thought the warning would only apply to the case where a references to an identifier is different to that with which it was defined. So var a: MYINT; would complain, as would rec.myInt, but
type MyInt = Integer; MyRec = record myint: Integer; end; MyRec2 = record MYINT: Integer; end;
var myInt: Integer;
should not generate any warnings.
Is this a limitation in the way GPC handles identifiers (perhaps in the hash table or some such), or is this a deliberate design decision?
Thanks, Peter.
Peter N Lewis wrote:
I always prefer to get my code compiling with -Wall without warnings if at all possible. But it seems to be that the capitalisation warning is a little over the top:
I've replied to this a few times already, but again, it's about identifiers not declarations.
Is this a limitation in the way GPC handles identifiers (perhaps in the hash table or some such), or is this a deliberate design decision?
In a way, both. Applying it to declarations seems to be more work (though not impossible). Also, I myself prefer it for identifiers globally. I.e., when I care about matching capitalisation at all, I like to have it the same everywhere rather than calling the same identifier differently in different routines etc.
If you want to implement it for declarations, just go ahead, but make it optional (i.e., allow the existing behaviour as well).
Frank
Adriaan van Os wrote:
While trying to build a Mach-O dynamically linked shared library with GPC and LD, I get the following error:
ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_0__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_1__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_2__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/3.2.1// libgpc.a(filename.o) definition of common ___set_result_3__ (size 32)
My questions are:
- Is there something special about symbols for sets ?
The special thing is that they're temporary variables that may occur in the values of constants (e.g. `const Foo = [a, b] + [c .. d]'). It would be nicer to avoid it. For `+', merging the set constructors would be easy, but for the other operators, it gets hairier ...
- Would it help to rebuild libgpc.a with the --no-common flag ?
Perhaps, but there may be other conflicts then.
- Any other ideas or suggestions ?
As a work-around try replacing the set operations in EnvVarChars and FileNameSpecialChars in p/rts/filename.pas and p/rts/gpc.pas by their values.
I hope I can fix this problem in the next release.
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
While trying to build a Mach-O dynamically linked shared library with GPC and LD, I get the following error:
As a work-around try replacing the set operations in EnvVarChars and FileNameSpecialChars in p/rts/filename.pas and p/rts/gpc.pas by their values.
Thanks, the work around removes the common symbol problem and gets me one step further:
[G4:~] adriaan% ld -L$LibPath /usr/lib/dylib1.o usummer.o -dylib -lgpc -lgcc -lSystem ld: Undefined symbols: _environ
I have looked around for the _environ symbol and found it in rts.c. The // comments show how I worked around the problem to build the dynamically linked shared library. But it is a hack and there will probably be a better way.
#if defined (HAVE_ENVIRON) || defined (environ) #if !defined (environ) && !defined (ENVIRON_DECLARED) // extern char **environ; #endif #elif defined (HAVE___ENVIRON) || defined (__environ) #if !defined (__environ) && !defined (__ENVIRON_DECLARED) // extern char **__environ; #endif #define environ __environ #endif
GLOBAL (PCStrings _p_GetStartEnvironment (PCStrings ValueIfNotFound UNUSED)) { // #if defined (HAVE_ENVIRON) || defined (environ) // return environ; // #else return ValueIfNotFound; // #endif }
On Mac OS X, rts-config.h reads as follows:
/* Define if you have an environ variable. */ #define HAVE_ENVIRON 1
/* Define if you have an __environ variable. */ /* #undef HAVE___ENVIRON */
/* Define if the environ variable is declared in <unistd.h>. */ /* #undef ENVIRON_DECLARED */
/* Define if the __environ variable is declared in <unistd.h>. */ /* #undef __ENVIRON_DECLARED */
Regards,
Adriaan van Os
Frank Heckenbach wrote:
Adriaan van Os wrote:
While trying to build a Mach-O dynamically linked shared library with GPC and LD, I get the following error:
ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/ 3.2.1// libgpc.a(filename.o) definition of common ___set_result_0__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/ 3.2.1// libgpc.a(filename.o) definition of common ___set_result_1__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/ 3.2.1// libgpc.a(filename.o) definition of common ___set_result_2__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/ 3.2.1// libgpc.a(filename.o) definition of common ___set_result_3__ (size 32)
My questions are:
- Is there something special about symbols for sets ?
The special thing is that they're temporary variables that may occur in the values of constants (e.g. `const Foo = [a, b] + [c .. d]'). It would be nicer to avoid it. For `+', merging the set constructors would be easy, but for the other operators, it gets hairier ...
I hope I can fix this problem in the next release.
A quick test revealed that gpc-20030507 fixes it, am I correct ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
While trying to build a Mach-O dynamically linked shared library with GPC and LD, I get the following error:
ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/ 3.2.1// libgpc.a(filename.o) definition of common ___set_result_0__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/ 3.2.1// libgpc.a(filename.o) definition of common ___set_result_1__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/ 3.2.1// libgpc.a(filename.o) definition of common ___set_result_2__ (size 32) /Developer/Pascal/gpc321d11/lib/gcc-lib/powerpc-apple-darwin6.3/ 3.2.1// libgpc.a(filename.o) definition of common ___set_result_3__ (size 32)
My questions are:
- Is there something special about symbols for sets ?
The special thing is that they're temporary variables that may occur in the values of constants (e.g. `const Foo = [a, b] + [c .. d]'). It would be nicer to avoid it. For `+', merging the set constructors would be easy, but for the other operators, it gets hairier ...
I hope I can fix this problem in the next release.
A quick test revealed that gpc-20030507 fixes it, am I correct ?
Fixes it for `+', works around it for other operators.
Frank
-
Adriaan van Os -
Frank Heckenbach -
Peter N Lewis