From owner-freebsd-ports Sun Mar 31 14: 1:46 2002 Delivered-To: freebsd-ports@freebsd.org Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by hub.freebsd.org (Postfix) with ESMTP id 67DC937B416; Sun, 31 Mar 2002 14:01:36 -0800 (PST) Received: from pool0321.cvx21-bradley.dialup.earthlink.net ([209.179.193.66] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16rnO8-0003UD-00; Sun, 31 Mar 2002 14:01:24 -0800 Message-ID: <3CA7871C.90383DE3@mindspring.com> Date: Sun, 31 Mar 2002 14:01:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Simon 'corecode' Schubert Cc: Alexander Leidinger , nick-lists@netability.ie, hackers@FreeBSD.ORG, ports@FreeBSD.ORG, cy@FreeBSD.ORG Subject: Re: lang/icc doesn't compile c++ sources References: <200203311104.g2VB4FFL003781@Magelan.Leidinger.net> <200203311752.g2VHqLFL006965@Magelan.Leidinger.net> <20020331221442.038bf9ce.corecode@corecode.ath.cx> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org 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, _Alloc=std::allocator]" matches the argument list > argument types are: (char *, std::allocator) > : _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, _Alloc > =std::allocator]" 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