Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion wxMSW 2.9.x build fails under Borland

Received: by 10.151.51.9 with SMTP id d9mr3015441ybk.55.1288519219206;
        Sun, 31 Oct 2010 03:00:19 -0700 (PDT)
X-BeenThere: wx-dev@googlegroups.com
Received: by 10.151.85.5 with SMTP id n5ls2643257ybl.2.p; Sun, 31 Oct 2010
 03:00:18 -0700 (PDT)
Received: by 10.151.27.1 with SMTP id e1mr1069509ybj.23.1288519218656;
        Sun, 31 Oct 2010 03:00:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.91.62.6 with SMTP id p6mr471258agk.20.1288475066838; Sat, 30
 Oct 2010 14:44:26 -0700 (PDT)
Received: by x42g2000yqx.googlegroups.com with HTTP; Sat, 30 Oct 2010 14:44:26
 -0700 (PDT)
Date: Sat, 30 Oct 2010 14:44:26 -0700 (PDT)
In-Reply-To: <4CCAFA8A.4060205@york.ac.uk>
X-IP: 67.188.178.11
References: <7a8fc1b0-3f98-49a2-87cc-d645f6bb5c90@x18g2000pro.googlegroups.com><E1Orzxx-00028O-Jo@smtp.tt-solutions.com>
 <9b41218e-de59-41bf-be6b-ebb9b86f82b1@x18g2000pro.googlegroups.com>
 <E1Os1BC-000773-CK@smtp.tt-solutions.com> <3CB85155-896A-427B-99F9-0017889CD81A@york.ac.uk>
 <8fef5d19-5d7e-4780-9f6b-eb46d723331c@y32g2000prc.googlegroups.com>
 <20DDDC0F-EE7D-460F-85D5-AC858CDD8E78@york.ac.uk> <E1Ot5WB-0005vY-Ky@smtp.tt-solutions.com>
 <0346a41e-a82d-451d-853b-34271b3d56a8@i4g2000prf.googlegroups.com>
 <b73419d0-c487-426e-bfb4-6b2890d03c8a@y12g2000prb.googlegroups.com> <4CCAFA8A.4060205@york.ac.uk>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US)
 AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.41 Safari/534.7,gzip(gfe)
Message-ID: <1eec2cd5-a4ff-4a9a-9a90-beb834464894@x42g2000yqx.googlegroups.com>
Subject: Re: wxMSW 2.9.x build fails under Borland
From: Greatwolf <google.greatw...@mamber.net>
To: wx-dev <wx-dev@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

ce> Two questions
ce>
ce> 1) Does the  bcc551fix-revision2.diff patch supercede all the
others. or
ce> do i have to apply them all in turn ?

Just to add to this, if you're building from the trunk you'll want to
apply revision 3 followed by revision 4. The last one fixes some
borland compile errors from wx/meta/implicitconversion.h.


On Oct 29, 9:47=A0am, chris elliott <bio...@york.ac.uk> wrote:
>
> Hi, and i've looked at the patch, and I don't see
> _RWSTD_COMPILE_INSTANTIATE anywhere in it, and i get a linker error
>
> Error: Unresolved external
> 'std::basic_string<wchar_t,std::char_traits........
>
> when I get as far as the minimal sample, default build with bc551
>
> {I replaced the ilink32 command with ulink command in
> minimal/makefile.bcc ; ulink atftp://ftp.styx.cabel.net/pub/UniLink/[curr=
ent version ulnb0117.zip ]
>

Yes you can define -D_RWSTD_COMPILE_INSTANTIATE in config.bcc under
the cpp flag variable. I didn't include this in the patch since it's
unclear, at least to me, what the most appropriate workaround for this
should be. On the one hand, compiling a shared dll with this method in
release with optimizations and inlining enabled will cause a crash at
runtime. However, a debug build with opts disabled and function
inlining disabled then everything runs fine. I did a google for
_RWSTD_COMPILE_INSTANTIATE and found

  http://www.boost.org/doc/libs/1_39_0/boost/regex/config/borland.hpp

The pragma message is of particular interest because it seems to
pertain exactly to this runtime crash I'm observing. On the other
hand, without _RWSTD_COMPILE_INSTANTIATE then some of the needed
basic_string members won't get properly instantiated and linking will
fail because of those missing symbols.

Another alternative I've tried is to just put together a small
separate stand-alone build that explicitly instantiates the missing
symbols from linking. It'll be built without opts and inlining
enabled. The obj/lib produced will just get included as part of the
linking of wxwidgets to resolve the symbols. This way only the part
that's crashing -- namely the roguewave stl strings, will be built
with no optimizations and inlining.

But how exactly would we apply this to the trunk of wxwidgets though?
This workaround is very borland specific and I'm not sure if mixing