http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54791
--- Comment #12 from Adi <adivilceanu at yahoo dot com> 2012-11-05 21:14:22 UTC
---
(In reply to comment #11)
> I believe that the G++ front end tries to create a unique name from the first
> symbol it sees. I do not now if this is related to the constructor name
> collision that you are seeing.
What do you mean that it is not related? From my point of view it is.
>
> Is it valid C++ to define an object with the same name in multiple files? I
> cannot tell if you were doing something that happened to work but the behavior
> is not clearly defined by the language, or if this is allowed and does not
> work
> on AIX, in which case it is a bug.
I agree with you here. This is why I am not insisting that this is a bug. I
mean you can expect bad results if you define this. BTW on Linux GNU ld does
not let me to define 2 globals with same name. I get a multiple definition
error. it seems that the AIX ld is more friendly :(.
>
> Why does inlining or not inlining affect the name collision?
Because if you have a function declared as inline in a header file that gets
propagated to multiple source files is ok, but in my case that inline keyword
was removed by some $ifdef LINUX and so I end up with having the constructor
body defined in the header like this: ClassA::ClassA(){//body}. Now because
this is in the header it will propagate to all sources that includes it. So
finally I end up with that constructor in multiple constructors sources. This
would not happen if the inline keyword have not been removed from it. This was
a bug in our code and I removed it.
>
> Do SVR4/ELF systems mangle each of the constructors uniquely? I thought that
> they all would end up in the ".init" sections, which will be concatenated. I
> am
> curious how the calls to the different ctors are disambiguated at link time.
I admit I am not very good at compilers(I am a beginner in understanding how
compilers are working on various platforms ) so on this question I am going to
make assumptions.
I am going to test on Linux and see what happens there.
>
> collect2 could warn, but it currently does not scan the constructor names it
> finds for duplicates in its object file scan. A warning would be nice, but I
> do not know if it is valid C++ that it should expect.
>
> I am not sure what you mean by order of initialization of global constructors
> across compilation units. This is within one library? GCC has a way to
> decorate constructors with a priority to order the constructors. If you mean
> order of constructors among multiple shared libraries, that is a separate,
> known issue on AIX.
Our project has one exe and several shared and static libs. To make the
things easier I moved every source file in the exe. Now the problem I have is
with the order of the initialization of global objects that reside in multiple
object files. I need objects in a source file by constructed first before any
other objects in the rest of the files are constructed.
You said that I can decorate the constructors with a priority. How to do that
? Before migrating from xlC we used #pragma priority. This is ignored by gcc.
We also used -qpriority flag of xlC. Also gcc does not have something like
this. Or?
Also I tried moving the objects I need constructed in the source files where
main() is defined. Still seems that these objects are not constructed first.
Also I put the object file where these objects are defined as the first one
wen passing to the linker. Still no luck.
