[Bug c++/12413] New: 'symbol already defined' when building ICU 2.6 with Cygwin

[Bug c++/12413] New: 'symbol already defined' when building ICU 2.6 with Cygwin

[ron_hylton at hotmail dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12413

           Summary: 'symbol already defined' when building ICU 2.6 with
                    Cygwin
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ron_hylton at hotmail dot com
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-cygwin

When building ICU 2.6 from http://oss.software.ibm.com/icu/ using Cygwin on 
Windows 2000 I get the error:
strmatch.s:1914: Error: symbol `_N' is already defined
This code compiles under Visual Studio 7.1 & Comeau 4.3.

Details:  

$ c++ -v -save-temps -D_REENTRANT -I. -I../common -D_REENTRANT -DHAVE_CONFIG_H
-DU_I18N_IMPLEMENTATION  -c -DPIC  -Wall -o strmatch.o strmatch.cpp
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs
Configured with: /netrel/src/gcc-3.3.1-1/configure --enable-languages=c,c++,f77,
java --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --wi
thout-included-gettext --enable-interpreter --enable-sjlj-exceptions --disable-v
ersion-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-p
c-cygwin --target=i686-pc-cygwin --prefix=/usr --exec-prefix=/usr --sysconfdir=/
etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecdir=/usr/sbin
Thread model: posix
gcc version 3.3.1 (cygming special)
 /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/cc1plus.exe -E -D__GNUG__=3 -quiet -v -I.
 -I../common -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=1 -D__CYGWIN3
2__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc-lib/i686-pc-
cygwin/3.3.1/../../../../include/w32api -idirafter /usr/lib/gcc-lib/i686-pc-cygw
in/3.3.1/../../../../i686-pc-cygwin/lib/../../include/w32api -D_REENTRANT -D_REE
NTRANT -DHAVE_CONFIG_H -DU_I18N_IMPLEMENTATION -DPIC strmatch.cpp -Wall strmatch
.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/usr/i686-pc-cygwin/include"
ignoring duplicate directory "/usr/i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../common
 /usr/include/c++/3.3.1
 /usr/include/c++/3.3.1/i686-pc-cygwin
 /usr/include/c++/3.3.1/backward
 /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/include
 /usr/include
 /usr/include/w32api
End of search list.
 /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/cc1plus.exe -fpreprocessed strmatch.ii -q
uiet -dumpbase strmatch.cpp -auxbase-strip strmatch.o -Wall -version -o strmatch
.s
GNU C++ version 3.3.1 (cygming special) (i686-pc-cygwin)
        compiled by GNU C version 3.3.1 (cygming special).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65410
 /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/as.exe --t
raditional-format -o strmatch.o strmatch.s
strmatch.s: Assembler messages:
strmatch.s:1914: Error: symbol `_N' is already defined

I have a .ii file which I can hopefully attach once the bug is posted.

[Bug c++/12413] 'symbol already defined' when building ICU 2.6 with Cygwin

[ron_hylton at hotmail dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12413



------- Additional Comments From ron_hylton at hotmail dot com  2003-09-25 22:17 -------
Created an attachment (id=4824)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4824&action=view)
bz2 compressed ii file

[Bug target/12413] 'symbol already defined' when building ICU 2.6 with Cygwin

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12413


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target
           Keywords|                            |wrong-code

[Bug target/12413] 'symbol already defined' when building ICU 2.6 with Cygwin

[dannysmith at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12413



------- Additional Comments From dannysmith at gcc dot gnu dot org  2003-09-30 11:25 -------
Confirmed on mainline with i386-mingw32:  YADIB (YetAnotherDllImportBug).

The problem is that virtual tables are being marked as dllimport (that is as 
undefined symbols ) and than later, because of loss of the dllimport attribute 
from the containing class, they are emitted.

Why is the attribute being lost from the containing class? 

Because of redeclaration of the class without the attribute after initial 
definition.

If I comment out the unnecessary 'forward' declarations in the preprocessed 
source (ie, declarations that follow the the class deinition with dllimport 
attribute), like so:

2531,2532c2531,2532
< class Replaceable;
< class UnicodeString;
---
> // class Replaceable;
> // class UnicodeString;
2594,2596c2594,2596
< class Replaceable;
< class UnicodeString;
< class UnicodeSet;
---
> // class Replaceable;
> // class UnicodeString;
> // class UnicodeSet;
3598c3598
< class Replaceable;
---
> // class Replaceable;
3602,3603c3602,3603
< class UnicodeString;
< class UnicodeSet;
---
> // class UnicodeString;
> // class UnicodeSet;
3699,3702c3699,3702
< class UnicodeFunctor;
< class UnicodeString;
< class UnicodeMatcher;
< class UnicodeReplacer;
---
> // class UnicodeFunctor;
> // class UnicodeString;
> // class UnicodeMatcher;
> // class UnicodeReplacer;


the compilation succeeds without error.

Here is a reduced testcase, that shows the redeclaration problem, but without 
the vtable fallout

// redecl.C
struct __attribute__ ((dllimport)) 
DllClass1
{
  static int instances;
};

struct __attribute__ ((dllimport)) 
DllClass2
{
  static int instances;
};


// Use DllClass1 and so force it to be emitted now

int foo()
{
   return DllClass1::instances;
}

// re-declarations without dllimport attribute
struct DllClass1;
struct DllClass2;

int bar1()
{
   // DllClass1::instances is marked as dllimport
   return DllClass1::instances;
}

int bar2()
{
  // DllClass2::instances is not marked as dllimport
  return DllClass2::instances;
}
// end redecl.C

Here is the assembler output for above:

	.file	"redecl.C"
	.text
	.align 2
.globl __Z3foov
	.def	__Z3foov;	.scl	2;	.type	32;	.endef
__Z3foov:
	pushl	%ebp
	movl	%esp, %ebp
	movl	__imp___ZN9DllClass19instancesE, %eax
	movl	(%eax), %eax
	popl	%ebp
	ret
	.align 2
.globl __Z4bar1v
	.def	__Z4bar1v;	.scl	2;	.type	32;	.endef
__Z4bar1v:
	pushl	%ebp
	movl	%esp, %ebp
	movl	__imp___ZN9DllClass19instancesE, %eax
	movl	(%eax), %eax
	popl	%ebp
	ret
	.align 2
.globl __Z4bar2v
	.def	__Z4bar2v;	.scl	2;	.type	32;	.endef
__Z4bar2v:
	pushl	%ebp
	movl	%esp, %ebp
	movl	__ZN9DllClass29instancesE, %eax  <<< no _imp__ prefix
	popl	%ebp
	ret


Note that DllClass2::instances is not marked as a dllimport (no _imp__ prefix).

In the strmatch case submitted by the OP, the vtable data for some classes
had initially been marked as imported, but had not been been used before
redeclaration.  It appears that these vtable's are being treated as  both
externally defined and needing a local definition.

I initially thought that setting INTERFACE_ONLY and INTEFACE_KNOWN for 
dllimport'd classes might help here, but looking at the comments for 
MULTIPLE_SYMBOL_SPACES in i386/cygming.h and in cp/decl.c and decl2.c I'm not 
so sure.  

Danny

[Bug target/12413] 'symbol already defined' when building ICU 2.6 with Cygwin

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12413


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-09-30 15:43:27
               date|                            |


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-09-30 15:43 -------
Already analyzed by Danny.

[Bug target/12413] 'symbol already defined' when building ICU 2.6 with Cygwin

[dannysmith at gcc dot gnu dot org]

------- Additional Comments From dannysmith at gcc dot gnu dot org  2004-01-19 21:35 -------
Hello.

This bug is caused by the way vtable are handled in cp/decl2.c
(import_export_vtable) vs the need for the dllimport marking mechanism
to avoid marking defined data as dllimport. The vtable may be first
marked as DECL_EXTERNAL when import_export_vtable is called by
maybe_emit_vtables() and then later (when final == 1), the DECL_EXTERNAL
is removed. This change in storage class causes the problems. When
config/i386/winnt.c (i386_pe_dllimport_p) sees the DECL_EXTERNAL on a
vtable symbol from a dllimported class, it tells
i386_pe_mark_dllimport() to decorate the symbol with _imp_ prefix, and
to pass it through get_identifier. When the DECL_EXTERNAL is later
removed by import_export_vtable, the vtable definition is emitted, but
with a bogus identifier.


Here is one way to fix:

Patch (1)

cp/ChangedLog

	decl2.c (import_export_vtable): Always set DECL_EXTERNAL for
	vtables of dllimported classes.


Index: decl2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/decl2.c,v
retrieving revision 1.695
diff -c -3 -p -r1.695 decl2.c
*** decl2.c	13 Jan 2004 23:59:19 -0000	1.695
--- decl2.c	18 Jan 2004 02:45:21 -0000
*************** import_export_vtable (tree decl, tree ty
*** 1447,1453 ****
    if (DECL_INTERFACE_KNOWN (decl))
      return;
  
!   if (TYPE_FOR_JAVA (type))
      {
        TREE_PUBLIC (decl) = 1;
        DECL_EXTERNAL (decl) = 1;
--- 1447,1454 ----
    if (DECL_INTERFACE_KNOWN (decl))
      return;
  
!   if (TYPE_FOR_JAVA (type)
!       || lookup_attribute ("dllimport", TYPE_ATTRIBUTES (type)))
      {
        TREE_PUBLIC (decl) = 1;
        DECL_EXTERNAL (decl) = 1;


Following is another way to fix, that is more intrusive. but by removing
all the MULTIPLE_SYMBOL_SPACE business, we also get a fix for some problems
with #pragma interface when linking against static libs.

If we remove the MULTIPLE_SYMBOL_SPACES define for win32 targets. then
we set both INTERFACE_ONLY and INTERFACE_KNOWN for dllimported classes.
This is the right thing to do for vtables, since (1) vtables are always
exported from the dll along with the class as long as the class type
definition has the dllexport attribute (or if ld is told to
--export-all), and (2) vtables get marked as dllimport when the class is
imported. It is also the right thing to do for ordinary class members,
since dllimport means the that symbols are defined exterally. However,
it is not the right thing to do for type info nodes, since these do not
currently inherit the dll attributes of the class (should they?). So
rather than tarring the whole class with MULTIPLE_SYMBOL_SPACES
protection, we just make a special excption for type info objects, and
always emit them even if a class has INTERFACE_ONLY set by virtue of
dllimport attribute.

I suspect I'm missing something.  The problem is I don't really
understand the logic behind the MULTIPLE_SYMBOL_SPACES in the first
place.  Can someone more familiar with the history of this please
suggest a testcase that shows why it was/is needed.


Jason, since your name appears most often against MULTIPLE_SYMBOL_SPACES in 
ChangeLogs I've add you to CC.


Patch (2):


ChangeLog

	* config/i386/cygming.h (MULTIPLE_SYMBOL_SPACES): Don't define.

cp/ChangeLog

	* decl2.c (import_export_tinfo): Always emit tinfo nodes for
	dllimported classes.
 

Index: config/i386/cygming.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/cygming.h,v
retrieving revision 1.11
diff -c -3 -p -r1.11 cygming.h
*** config/i386/cygming.h	2 Jan 2004 15:30:42 -0000	1.11
--- config/i386/cygming.h	19 Jan 2004 21:06:23 -0000
*************** do {							\
*** 249,255 ****
     unit may not be bound to undefined symbols in another translation unit
     without user intervention.  For instance, under Microsoft Windows
     symbols must be explicitly imported from shared libraries (DLLs).  */
! #define MULTIPLE_SYMBOL_SPACES
  
  extern void i386_pe_unique_section (TREE, int);
  #define TARGET_ASM_UNIQUE_SECTION i386_pe_unique_section
--- 249,255 ----
     unit may not be bound to undefined symbols in another translation unit
     without user intervention.  For instance, under Microsoft Windows
     symbols must be explicitly imported from shared libraries (DLLs).  */
! #undef MULTIPLE_SYMBOL_SPACES
  
  extern void i386_pe_unique_section (TREE, int);
  #define TARGET_ASM_UNIQUE_SECTION i386_pe_unique_section
Index: cp/decl2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/decl2.c,v
retrieving revision 1.695
diff -c -3 -p -r1.695 decl2.c
*** cp/decl2.c	13 Jan 2004 23:59:19 -0000	1.695
--- cp/decl2.c	19 Jan 2004 21:06:30 -0000
*************** import_export_tinfo (tree decl, tree typ
*** 1740,1746 ****
        /* If -fno-rtti, we're not necessarily emitting this stuff with
  	 the class, so go ahead and emit it now.  This can happen when
  	 a class is used in exception handling.  */
!       && flag_rtti)
      {
        DECL_NOT_REALLY_EXTERN (decl) = !CLASSTYPE_INTERFACE_ONLY (type);
        DECL_COMDAT (decl) = 0;
--- 1740,1754 ----
        /* If -fno-rtti, we're not necessarily emitting this stuff with
  	 the class, so go ahead and emit it now.  This can happen when
  	 a class is used in exception handling.  */
!       && flag_rtti
! #if defined (TARGET_DLLIMPORT_DECL_ATTRIBUTES)
!       /* FIXME: Always emit typeinfo for dllimported classes, since we
! 	 don't know if it has been exported from the library. Even if it
! 	 has been exported, we would still need to add the dllimport
! 	 attribute to the typeinfo object to get it to link correctly.  */
!       && !lookup_attribute ("dllimport", TYPE_ATTRIBUTES (type))
! #endif
!      )
      {
        DECL_NOT_REALLY_EXTERN (decl) = !CLASSTYPE_INTERFACE_ONLY (type);
        DECL_COMDAT (decl) = 0;



Danny


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com,
                   |                            |dannysmith at gcc dot gnu
                   |                            |dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12413

[Bug target/12413] 'symbol already defined' when building ICU 2.6 with Cygwin

[dannysmith at users dot sourceforge dot net]

------- Comment #5 from dannysmith at users dot sourceforge dot net  2007-09-20 21:24 -------
This testcase compiles with problem  on trunk and 4.2.2.  I haven't tested
4.1.x
Danny


-- 

dannysmith at users dot sourceforge dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.2.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12413