ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
Hello, 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 ? Could someone please explain me what is going on ? Since I declare the variable with extern I should not need 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 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)
Re: ld: common symbols not allowed with MH_DYLIB output
Sam,
Since you seems very knowledgable why does the error desepear when I
initialize the structure ?
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.
Thanks again for your time,
Mathieu
On Jun 6, 2005, at 5:57 PM, Sam Lauber wrote:
Hello,
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 ? Could someone please explain me what is going on ?
Since I declare the variable with extern I should not need 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
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)
This is not a problem with GCC. In fact, it is not a problem at all.
It is a
misunderstanding of the linker. When you run
gcc -dynamiclib -o libfoo.dylib foo.o
it really does
libtool -dynamic -o libfoo.dylib foo.o
which becomes
ld -dylib -o libfoo.dylib foo.o
However, -multi_module is the default, so it really is
ld -dylib -o libfoo.dylib foo.o -multi_module
-multi_module is enabled by default, so you can get errors from the
linker of
the form `libfoo.dylib(foo.o)' when there's a link problem.
The error happens because
a) an `extern' variable is called a `common variable'
b) in multipule module mode, common variables are not allowed
c) if they were allowed, it would defeat the purpose of that option:
better
diagnostics
To fix it, add -Wl,-single_module to the end of the GCC command line.
However, note that subsequent linker errors will refer to
`libfoo.dylib' instead
of `libfoo.dylib(foo.o)'.
Samuel Lauber
--
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com
Powered by Outblaze
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
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 -fno-common when you are building dynamic libraries on darwin. 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 the code to make a fake initialization #3. I need to pass -fno-common to the compiler I really don't understand why I need to do that, since this is valid C code. Why the linker does not default to proper option, or why the -fno-common option isn't used. At compile time gcc should figure that out, right ? Now compared to the linker option, at least the compiler flag I can specify it for the specific file I want, which is great. But then again why is this up to the user to do it ? Is there a performance reason ? Why isn't it the default ? How do other people do when porting *nix lib to MacOSX ? Is this is trial-and-error process to get the lib compiled ? Thanks Mathieu
Re: c/c++ validator
Something like: http://www.cs.rpi.edu/~gregod/STLlint/STLlint.html HTH Mathieu Tommy Vercetti wrote: Hi folks I would like to ask you about source validation software. Software that runs trough source code, and attempts to find any possible memory leaks, and other problems. Is there anything opensource for C or/and C++ out there ? I know it's the wrong list to ask for it, but that's quite close to compilers, and some of you may know about it. Thanks.
Re: c/c++ validator
Gabriel Dos Reis wrote: Tommy Vercetti <[EMAIL PROTECTED]> writes: | On Sunday 19 June 2005 03:03, you wrote: | > Tommy Vercetti <[EMAIL PROTECTED]> writes: | > | On Sunday 19 June 2005 00:32, you wrote: | > | > Something like: | > | > | > | > http://www.cs.rpi.edu/~gregod/STLlint/STLlint.html | > | | > | Yeah, but for more than just STL, and opensource. C++ checker that | > | is going to work for instance for KDE. | > | Wonder why they use proprietary parser, | > | > maybe because they work? ;-p | | > | there are opensource | > | parsers around, like elsa, or gcc c++ parser. | > | > Elsa does not parse C++. | Elsa is for C/C++, so it says on their website. I know what the website says. My comment was about the actual *uses* of the parser. Have you tried it on actual C++ programs? How about gccxml: http://www.gccxml.org Mathieu
Surprising behavior of __attribute__((deprecated)) in ctor
Hello,
I have quite a surpising behavior with gcc when compiling the following
code (*). Here is the output:
$ g++ deprecated.cxx /tmp
deprecated.cxx: In constructor `A::A(int)':
deprecated.cxx:11: warning: `A' is deprecated (declared at deprecated.cxx:9)
deprecated.cxx: In constructor `A::A(int)':
deprecated.cxx:11: warning: `A' is deprecated (declared at deprecated.cxx:9)
Using:
$ g++ --version
g++ (GCC) 3.3 20030304 (Apple Computer, Inc. build 1671)
I cannot reproduce that with gcc 3.3, 3.4, 4.0 on my linux box (debian
testing package).
Comment ?
Thanks,
Mathieu
Ps: function seems fine.
(*)
deprecated.cxx --
class A
{
public:
A() { foo=0; };
A(int b) __attribute__((deprecated));
int foo;
};
A::A(int b)
{
foo = b;
}
int main()
{
A a;
// A a(2);
}
Re: Surprising behavior of __attribute__((deprecated)) in ctor
mrs $ g++-3.3 t7.cc t7.cc: In constructor `A::A(int)': t7.cc:11: warning: `A' is deprecated (declared at t7.cc:9) t7.cc: In constructor `A::A(int)': t7.cc:11: warning: `A' is deprecated (declared at t7.cc:9) Yup, right testcase... To support Panther I defined a MACRO: # if defined(__GNUC__) && !defined(__INTEL_COMPILER) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) #if defined(__APPLE__) && (__GNUC__ == 3) && (__GNUC_MINOR__ == 3) // Seems like there is a bug in APPLE gcc for deprecated attribute and ctor // This is fixed in g++ 4.0 (Tiger) # define GDCM_LEGACY(method) method #else # define GDCM_LEGACY(method) method __attribute__((deprecated)) #endif # elif defined(_MSC_VER) && _MSC_VER >= 1300 # define GDCM_LEGACY(method) __declspec(deprecated) method # else # define GDCM_LEGACY(method) method # endif #endif Basically I am testing if GNU and not APPLE with 'feature' :) Mathieu
Need help to fill bug report (gcc 4.0.1 and above)
Hello, I have currently a reproducable seg fault from an exe produced by gcc 4.0.1 (*). It does not appear using gcc 2.95, 3.2, 3.3, 3.4. If I run it throught gdb I get: 0x402814b1 in __gnu_cxx::__pool::_M_reclaim_block () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x402814b1 in __gnu_cxx::__pool::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0x08062907 in __gnu_cxx::__mt_allocstd::string> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate (this=0x806d888, __p=0x8221f10, __n=1) at mt_allocator.h:746 ... and the structure being: static std::set< std::pair< std::string, std::string > > foo; If I try to run through valgrind 3.0 everything is fine, and it produce correct output. Any advice on a way to narrow down a simple testcase, right now it would require building VTK(**) Thanks for any help, Mathieu (*) debian testing. but I can also reproduce with gcc 4.1.0 20050726 (gcc-snapshot) (**) http://vtk.org
Segfault with gcc4 and LD_PRELOAD (was: Need help to fill bug report (gcc 4.0.1 and above))
Hi, I am very sorry to insist but I would really appreciate if someone could shed some light on my current problem. I really don't see why my code is only segfaulting when using gcc4.0.1 (and above). Description: I am running a program that is outputing a file. The very same program when run with LD_PRELOAD set to libGL.so, is segfaulting. The backtrace can be found here: http://www.creatis.insa-lyon.fr/~malaterre/gcc/gdb.log And I ran also strace with/ and without LD_PRELOAD set: $ export LD_PRELOAD=/usr/X11R6/lib/libGL.so $ strace /home/mathieu/Dashboards/MyTests/VTK-gcc4/bin/vtkParseOGLExt /home/mathieu/Dashboards/MyTests/VTK-gcc4/Rendering /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glext.h /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glxext.h /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/wglext.h >& /tmp/log1 $ unset LD_PRELOAD $ strace /home/mathieu/Dashboards/MyTests/VTK-gcc4/bin/vtkParseOGLExt /home/mathieu/Dashboards/MyTests/VTK-gcc4/Rendering /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glext.h /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/glxext.h /home/mathieu/Dashboards/MyTests/ParaView/VTK/Utilities/ParseOGLExt/headers/wglext.h >& /tmp/log2 Those logs files can be found here: http://www.creatis.insa-lyon.fr/~malaterre/gcc/log1 and http://www.creatis.insa-lyon.fr/~malaterre/gcc/log2 --- Anyone interested in reproducing the bug need a debian testing with gcc4: (assuming gcc points to gcc 4.0.1) $ sudo apt-get install cmake $ cvs -d:pserver:[EMAIL PROTECTED]:2401/cvsroot/VTK login $ cvs -d:pserver:[EMAIL PROTECTED]:2401/cvsroot/VTK co VTK $ mkdir VTK-gcc $ cd VTK-gcc $ cmake ../VTK $ make ... Thanks for any advice on tracking down this bug, Mathieu Mathieu Malaterre wrote: Hello, I have currently a reproducable seg fault from an exe produced by gcc 4.0.1 (*). It does not appear using gcc 2.95, 3.2, 3.3, 3.4. If I run it throught gdb I get: 0x402814b1 in __gnu_cxx::__pool::_M_reclaim_block () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x402814b1 in __gnu_cxx::__pool::_M_reclaim_block () from /usr/lib/libstdc++.so.6 #1 0x08062907 in __gnu_cxx::__mt_allocstd::string> >, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::deallocate (this=0x806d888, __p=0x8221f10, __n=1) at mt_allocator.h:746 ... and the structure being: static std::set< std::pair< std::string, std::string > > foo; If I try to run through valgrind 3.0 everything is fine, and it produce correct output. Any advice on a way to narrow down a simple testcase, right now it would require building VTK(**) Thanks for any help, Mathieu (*) debian testing. but I can also reproduce with gcc 4.1.0 20050726 (gcc-snapshot) (**) http://vtk.org
