[lmi] 'mingw_setup.make' [Fwd: [Mingw-users] '/mingw' directory and multiple definition of `typeinfo for std::bad_alloc']

[Greg Chicares]

The answer to the message quoted below was:

  http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00703.html

In light of that, wouldn't it be better to avoid using this:

  mingw_dir  := $(system_root)/MinGW

and instead append a date to each version?

I don't think there's any better way to distinguish versions than by date.
The most important package is the compiler itself, but if they update
binutils only, then the compiler version alone isn't sufficient. There are
too many packages to specify the version of each. 'MinGW-3.2.0-rc-3.exe'
and similar names were used in the past for their installers, but those
haven't been updated as frequently as we may need. I believe a resolution
of one day is adequate.

AFAICT from
  http://prdownloads.sourceforge.net/mingw/
, these are the names we'd want for the installer versions we've used
since lmi's inception:

  MinGW-20030915 == MinGW-3.1.0-1.exe
  MinGW-20050120 == MinGW-3.2.0-rc-3.exe

and what 'mingw_setup.make' installs today might be called

  MinGW-20050827

which would seem to correspond to 'MinGW-5.0.0.exe'. Note that there have
been three updates of two packages since then.

-------- Original Message --------
Subject: [Mingw-users] '/mingw' directory and multiple definition of `typeinfo 
for std::bad_alloc'
Date: Mon, 17 Jan 2005 11:30:44 -0500
From: Greg Chicares <address@hidden>
Reply-To: address@hidden
To: mingw-users <address@hidden>

Experimenting with the MinGW-3.2.0-rc-1.exe package, I
observed strange linker errors. I installed the new
package in /MinGW-3.4.2 but left 3.2.3 in /MinGW ; but
when I renamed the old toolset's directory, the errors
disappeared. I'm wondering why.

Here's my link command:

C:/MinGW-3.4.2/bin/g++ -o libihs.dll convenience.o exception.o \
[snip many .o files]
 enumtypes.o xrange.o -shared -LC:/msys/1.0/local/lib -lxml2_dll \
 -Wl,--stats -Wl,-Map,libihs.dll.map -L. -L C:/msys/1.0/local/lib \
 -lxml2_dll

I mistakenly mention libxml2 twice, but that's a C
library, so it can't account for these problems:

/mingw/lib/libstdc++.a(eh_personality.o)
  (.data$_ZTISt9exception[typeinfo for std::exception]+0x0):
  multiple definition of `typeinfo for std::exception'
exception.o(.rdata$_ZTISt9exception[typeinfo for std::exception]+0x0):
  C:/MinGW-3.4.2/bin/../lib/gcc/mingw32/3.4.2/../../../../ \
  include/c++/3.4.2/bits/locale_facets.tcc:2493:
  first defined here
/mingw/lib/libstdc++.a(eh_personality.o)
  (.text$_ZTSSt9exception[typeinfo name for std::exception]+0x0):
  multiple definition of `typeinfo name for std::exception'
exception.o(.rdata$_ZTSSt9exception[typeinfo name for std::exception]+0x0):
  exception.cpp:
  first defined here
[snip about 90 more lines like that]

The '/mingw/' all in lower case in
  /mingw/lib/libstdc++.a(eh_personality.o)
seems significant. I don't have any such directory.
If directory '/MinGW/' with uppercase 'M', G', and 'W'
exists, then these problems occur; otherwise, they
don't occur.

The shell I'm using is zsh, so this can't be an MSYS
problem. I've never seen any other path translated to
lower case. The zsh version is a native msw port, so
it doesn't depend on cygwin1.dll or anything like that.

I've grepped all my makefiles
  grep -iw mingw *make*
and found no token that case-insensitively matches
'mingw' . Similarly,
  print $mingw
prints nothing, and
  set | grep -iw mingw
finds no matching environment string.

Is this a possible defect that I should report?