Date: Sun, 31 Mar 2002 14:01:00 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Simon 'corecode' Schubert <corecode@corecode.ath.cx> Cc: Alexander Leidinger <Alexander@Leidinger.net>, nick-lists@netability.ie, hackers@FreeBSD.ORG, ports@FreeBSD.ORG, cy@FreeBSD.ORG Subject: Re: lang/icc doesn't compile c++ sources Message-ID: <3CA7871C.90383DE3@mindspring.com> References: <200203311104.g2VB4FFL003781@Magelan.Leidinger.net> <200203311752.g2VHqLFL006965@Magelan.Leidinger.net> <20020331221442.038bf9ce.corecode@corecode.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Simon 'corecode' Schubert wrote:
> icc -I./include -I/usr/include -I/usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/
> 3.0.4/include/g++ -I /usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.0.4/inclu
> de/g++/i386-portbld-freebsd5.0 -c e.cc
> e.cc:
> "/usr/local/lib/gcc-lib/i386-portbld-freebsd5.0/3.0.4/include/g++/bits/basic_str
> ing.h", line 860: error: no instance of constructor "std::basic_string<_CharT, _
> Traits, _Alloc>::_Alloc_hider::_Alloc_hider [with _CharT=char, _Traits=std::char
> _traits<char>, _Alloc=std::allocator<char>]" matches the argument list
> argument types are: (char *, std::allocator<char>)
> : _M_dataplus(_S_empty_rep()._M_refcopy(), _Alloc()) { }
> ^
> detected during instantiation of "std::basic_string<_CharT, _Traits, _
> Alloc>::basic_string() [with _CharT=char, _Traits=std::char_traits<char>, _Alloc
> =std::allocator<char>]"
OK, this one is evil.
There's code that assumes limk order here, and it seems that
the library is at fault, or the order in which the static
base class declarations are instantiated.
Jeremey Allison and I had the same problem with ACAP under g++,
when we were the first people to get it to compile, link, and
run. Doing this required multiple fixes:
1) The addition of per thread exception stacks; this is
now a feature of egcs, even though they implemented
the code wrong, such that you eat th thread overhead
always, not just when you are using threads.
2) We had to make modifications to the Moscow Center for
Supercomputing activities STL to do mutex construction,
similar to that done in the Windows version of the code,
to support POSIX threads Draft 4 compliance (this fixed
the STL for IRIX and several other platforms, like OSF,
which were also Draft 4).
3) We had to bring the FreeBSD pthreads into full compliance
with Draft 4 (this was one of the easiest parts of it,
but was broken when FreeBSD partially moved toward the
standard version by defining the PTHREAD_MUTEX_INITIALIZER,
which was the "standard" way of telling draft 4 compliant
from standards compliant implementations).
4) Jeremey discovered that the link order affected the order
of construction, and there were some assumptions that the
order of construction would be tsort'ed to work by the code,
but the compiler didn't make those assumptions true, so the
dead chicken to wave was to change the object order for the
list of object files to be linked.
I think this #4 is the magic one here, too, though I think that it
is more serious, in that it's an issue for ordering of static
instance declarations in the base class.
My main recommendation here is that the Moscow code is much
better at this, since it has been pounded upon more than any
other code in the same ecological niche, so using it instead
is probably the right thing to do.
Alternately, you could ensure ordering... by reordering the source
code. This seems like a poor idea, but it what Linux did implicitly,
I think. 8-(.
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CA7871C.90383DE3>