wxMSW 2.9.x build fails under Borland
Greatwolf
tools fail to build with the error messages:
wxwidgets:
..\..\src\regex\regc_locale.c line 30: illegal initialization
That corresponding source line is:
wxwidgets:
static struct cname {
chr *name;
char code;
} cnames[] = {
{wxT("NUL"), '\0'},
{wxT("SOH"), '\001'},
{wxT("STX"), '\002'},
{wxT("ETX"), '\003'},
{wxT("EOT"), '\004'},
{wxT("ENQ"), '\005'},
{wxT("ACK"), '\006'},
{wxT("BEL"), '\007'},
If I remove wxT from ("NUL") then the error message will move down to
the next line 31. I had no problems building wxMSW 2.8.10 btw. wxMSW
2.8.11 appears to be the first branch where borland fails to build
properly.
After some investigation, I found that the preprocessing is screwed
up. The preprocessed file looked like this:
static struct cname {
chr *name;
char code;
} cnames[] = {
{L"NUL", '\0'},
{wxT("SOH"), '\001'},
{L"STX", '\002'},
{wxT("ETX"), '\003'},
{L"EOT", '\004'},
// and this pattern keeps alternating
// when the obvious preprocessed output should be
{L"NUL", '\0'},
{L"SOH", '\001'},
{L"STX", '\002'},
{L"ETX", '\003'},
{L"EOT", '\004'},
I found that chartype.h defined wxT to use wxCONCAT_HELPER. I changed
it to
wxT(x) L ## x
and that fixed the preprocessor issue.
I notice a recent change in wxwidgets where _T() macro has been
changed to wxT(). How is wxT suppose to be defined and where can I
find it? More importantly, how should this problem be fixed?
I got a little further in the build process and now I ran into yet
another issue:
..\..\src\stc\scintilla\src\Editor.cxx:
Error E2034 ..\..\include\wx/msw/winundef.h 44: Cannot convert 'const
char *' to 'const wchar_t *' in function CreateDialog(HINSTANCE__
*,const char *,HWND__ *,int (__stdcall *)(HWND__ *,unsigned
int,unsigned int,long))
And there are more similar errors with the same type mismatch with
char_t vs wchar_t albeit with different function names. How can this
error be corrected?
There might be more build errors I haven't encountered yet but this is
as far as I've gotten. Did anyone bother to check that the changes
made to wxwidget doesn't break any existing compiler support before
committing to svn?
Vadim Zeitlin
G> When building the latest wxMSW svn-trunk the Borland 5.5.1 commandline
G> tools fail to build with the error messages:
G>
G> wxwidgets:
G> ..\..\src\regex\regc_locale.c line 30: illegal initialization
G>
G>
G> That corresponding source line is:
G>
G> wxwidgets:
G> static struct cname {
G> chr *name;
G> char code;
G> } cnames[] = {
G> {wxT("NUL"), '\0'},
G> {wxT("SOH"), '\001'},
G> {wxT("STX"), '\002'},
G> {wxT("ETX"), '\003'},
G> {wxT("EOT"), '\004'},
G> {wxT("ENQ"), '\005'},
G> {wxT("ACK"), '\006'},
G> {wxT("BEL"), '\007'},
G>
G>
G> If I remove wxT from ("NUL") then the error message will move down to
G> the next line 31. I had no problems building wxMSW 2.8.10 btw. wxMSW
G> 2.8.11 appears to be the first branch where borland fails to build
G> properly.
G>
G> After some investigation, I found that the preprocessing is screwed
G> up. The preprocessed file looked like this:
G>
G> static struct cname {
G> chr *name;
G> char code;
G> } cnames[] = {
G> {L"NUL", '\0'},
G> {wxT("SOH"), '\001'},
G> {L"STX", '\002'},
G> {wxT("ETX"), '\003'},
G> {L"EOT", '\004'},
G> // and this pattern keeps alternating
I honestly have no idea what could explain this. It definitely looks like
a preprocessor bug to me.
G> I found that chartype.h defined wxT to use wxCONCAT_HELPER.
Which is 100% correct unless I'm really missing something...
G> I changed it to
G>
G> wxT(x) L ## x
This wouldn't be correct because it wouldn't work if x is itself a macro.
There are probably some occurrences of this even in wx itself. There surely
are some in user code.
G> I notice a recent change in wxwidgets where _T() macro has been
G> changed to wxT(). How is wxT suppose to be defined and where can I
G> find it?
I'm afraid I don't understand the question. You already found where it was
defined (wx/chartype.h) and the definition there answers the question about
how it's supposed to be defined.
G> More importantly, how should this problem be fixed?
As usual with compiler bugs, you may need to try randomly changing things
until they start working. Unfortunately I can't give any better advice.
G> I got a little further in the build process and now I ran into yet
G> another issue:
G>
G> ..\..\src\stc\scintilla\src\Editor.cxx:
G> Error E2034 ..\..\include\wx/msw/winundef.h 44: Cannot convert 'const
G> char *' to 'const wchar_t *' in function CreateDialog(HINSTANCE__
G> *,const char *,HWND__ *,int (__stdcall *)(HWND__ *,unsigned
G> int,unsigned int,long))
This would seem to indicate that you build wx in non-Unicode mode, i.e.
without UNICODE, _UNICODE or wxUSE_UNICODE=1 being defined. If you really
do this I don't know why does wxT() appear at all in preprocessor output in
regc_locale.c case because it shouldn't be used at all then. If you build
in Unicode mode then there must be something wrong in makefiles and Unicode
definition must not be correctly used when compiling Scintilla.
G> There might be more build errors I haven't encountered yet but this is
G> as far as I've gotten. Did anyone bother to check that the changes
G> made to wxwidget doesn't break any existing compiler support before
G> committing to svn?
No, not for this compiler. It's too old, broken and generally presents too
little interest to bother with it. Granted, we support VC6 which is still
older but only because some people really clamoured for it. And also
because it has its build slave (which currently seems to be offline
unfortunately) which makes it easy to see when the build using it is
broken. If you want to help with making Borland compiler supported, we'd
welcome it and help as far as possible but personally I simply can't
promise to spend any time on this compiler support myself.
Sorry,
VZ
Greatwolf
build process. I did this by setting UNICODE=1 in build/msw/
config.bcc.
Understandable regarding bcc support. How are VC6 compiler issues
usually worked around? Taking this preprocessing issue as an example,
what would be an acceptable fix to get it to work? e.g. would I just
put conditional defines in the problematic sections like this?
chartype.h
#ifdef __BORLANDC__
#define wxT(x) L ## x //workaround for borland preprocessor bug
#else
#define wxT(x) wxCONCAT_HELPER(L, x) //define it normally
#endif
I'm not sure this is the correct way to approach it. What's advisable?
As for the later errors, I'll do a preprocess on that compilation
unit when I have time. Hopefully, it'll reveal some details as to what
the problem might be. Is there anything that comes to mind regarding
differences in how unicode is handled between wxMSW 2.8.10 and
versions that came after that? 2.8.10 is the last version I'm able to
build successfully 'out of the box' without any needed changes to the
source itself.
Vadim Zeitlin
G> Thank you for the response. afaik I did enable UNICODE during the
G> build process. I did this by setting UNICODE=1 in build/msw/
G> config.bcc.
Then I really don't understand why is this not used for Scintilla library
compilation. Maybe something undefines _UNICODE somewhere in Borland
headers? Normally having UNICODE=1 in config.bcc should result in
-DUNICODE=1 on the compiler command line and then wxUSE_UNICODE=1 and
_UNICODE should be defined in wx/platform.h. If you insert some fragments
#ifndef _UNICODE
#error should be defined
#endif
here and there you should be able to localize the problem.
G> Understandable regarding bcc support. How are VC6 compiler issues
G> usually worked around? Taking this preprocessing issue as an example,
G> what would be an acceptable fix to get it to work? e.g. would I just
G> put conditional defines in the problematic sections like this?
G>
G> chartype.h
G> #ifdef __BORLANDC__
G> #define wxT(x) L ## x //workaround for borland preprocessor bug
G> #else
G> #define wxT(x) wxCONCAT_HELPER(L, x) //define it normally
G> #endif
This would be acceptable if you can confirm that the rest of the
compilation works after it and if no other solution can be found. But, as I
said, I think this might not work because wxT() might be used with macros
elsewhere.
If the bug is only triggered in regc_locale.c, maybe the best would be to
override wxT() definition (for Borland) in this file only.
G> As for the later errors, I'll do a preprocess on that compilation
G> unit when I have time. Hopefully, it'll reveal some details as to what
G> the problem might be. Is there anything that comes to mind regarding
G> differences in how unicode is handled between wxMSW 2.8.10 and
G> versions that came after that? 2.8.10 is the last version I'm able to
G> build successfully 'out of the box' without any needed changes to the
G> source itself.
Compared to 2.8.11 the only change was the global replacement of _T() with
wxT(). FWIW I was against applying it to the stable branch because I was
sure it was going to break some obscure configuration but got convinced
that a patch as trivial as this one couldn't break anything and so, as it
was required to fix compilation with Sun CC, I finally applied it. Sadly,
it seems like I was right initially...
Compared to 2.9 too many things to make it possible to list them have
changed. Basically almost everything Unicode-related did.
Regards,
VZ
Chris Elliott
I would suggest using the latest Borland compiler rather than 5.5.1; In the 2.8 installation instructions I wrote: "Cmpilation succeeds with CBuilderX personal edition and CBuilder6, but you may have to copy make.exe from the 5.5 download to the new bin directory."
I used Cbuilder debuggers a lot more easily than the 5.5 command line version. You can use the command line tools to make the libraries, and then use minimal.bpr to run the debugger. To debug your own projects, you only need to use a text editor to change minimal to the name of your project
All the best
chris
Greatwolf
On Sep 5, 10:27 am, Chris Elliott <bio...@york.ac.uk> wrote:
>
> I would suggest using the latest Borland compiler rather than 5.5.1; In the 2.8 installation instructions I wrote: "Cmpilation succeeds with CBuilderX personal edition and CBuilder6, but you may have to copy make.exe from the 5.5 download to the new bin directory."
>
get this to build I'll definitely try that route.
Anyway, here's a quick update of my progress so far:
- wxT() macro expansion problem. After some exhaustive testing I have
determined that it only seems to have an issue if you're prepending L
+ "some string literal". It's really an odd bug, for example, if I
change L to something else like M or JK then it magically expands
properly! After finding that out, I changed my earlier fixup on wxT()
to this instead:
#define wxT(x) wxCONCAT_HELPER_L(x)
where wxCONCAT_HELPER_L is defined as
#define wxCONCAT_HELPER_L(x) L ## x
That corrects the expansion problem under Borland but I need
confirmation that this fix will work where x is a macro too.
- Unicode issue in Scintilla.cxx. After checking through the build
process I found that _UNICODE was actually not defined for that
translation unit. To fix it I made a correction in the build/msw/
make.bcc file line 197:
$(__wxscintilla_usingdll_p) -D__WXMSW__ $(__WXUNIV_DEFINE_p) $
(__UNICODE_DEFINE_p) \
Note the addition of $(__UNICODE_DEFINE_p). After comparing to 2.8.10
I also found that the older version does not infact compile in
wxScintilla as part of its default build. I was unable to find any
references to that translation unit in the make.bcc.
- wxVector<> template issue. Borland unfortunately has trouble dealing
with the following non-type template code:
template <bool>
class foo
{};
template <typename T>
struct bar
{
foo< T::bool_flag > m_foo;
};
This created a lot of issues where the metaconstruct wxIf<> was being
used. I couldn't find any obvious quick fixes to this. For the time
being I've just enabled wxUSE_STL 1 in the setup.h as a workaround.
- issues w/ implicit conversion and overloaded operators. Following
code snippet demostrates the problem:
class wxString
{
private:
wxString(int);
wxString(long);
wxString(__int64);
};
enum wxOrientation
{
wxHORIZONTAL = 0x04,
wxVERTICAL = 0x08
};
enum wxform {};
enum wx {};
bool operator==(int lhs, const wxString &rhs) { return true; }
bool operator==(wx lhs, wxform rhs) { return true; }
int main()
{
wxOrientation orient = wxHORIZONTAL;
orient == wxVERTICAL; // ambiguous error! wtf??
}
The compiler erroneously complains that orient == wxVERTICAL is
ambiguous between
bool operator==(int, const wxString &);
and
bool operator==(int, int);
despite the conversion constructor being private in wxString! Same
issue applies to other comparision operators like != . wxWindowIdRef
class has the same problem. As a workaround I just enclosed all the
operands inside int() like this:
int(orient) == int(wxVERTICAL);
it's not pretty but it seems to fix the ambiguous problem. I also made
explicit wxString(int), not sure if this one's a good idea or not but
it also partially corrects the ambiguous issue.
- wxXLocale_Ctag was undefined. For the time being I just undefined
wxUse_Locale in the setup.h file
- Multiple declaration error in bitmap.cpp from wx/rawbmp.h. After
some investigation I've narrowed the problem down to this example code
usage:
template <typename T>
class typedef_test
{
public:
typedef T TType;
enum { sizePixel = sizeof(TType) };
};
struct dummy
{
typedef typedef_test<unsigned char>::TType TType;
};
dummy::TType& Get_TTtype(); // multiple declaration error between
this line and typedef in dummy. wtf??
The sizeof() operator is somehow breaking the typedefs and making the
compiler think there're multiple declarations where there aren't. If I
comment out the line using sizeof() then it compiles fine. Also if I
change
dummy::TType& Get_TTtype();
to
typedef_test<unsigned char>::TType& Get_TTtype();
then that compiles as well.
This is about as far as I've gotten on this now.
Chris Elliott
On 7 Sep 2010, at 21:10, Greatwolf wrote:
>
>
> enum wxOrientation
> {
> wxHORIZONTAL = 0x04,
> wxVERTICAL = 0x08
> };
>
> enum wxform {};
> enum wx {};
>
> bool operator==(int lhs, const wxString &rhs) { return true; }
> bool operator==(wx lhs, wxform rhs) { return true; }
>
> int main()
> {
> wxOrientation orient = wxHORIZONTAL;
> orient == wxVERTICAL; // ambiguous error! wtf??
> }
>
> The compiler erroneously complains that orient == wxVERTICAL is
> ambiguous between
yes, never ever use the == in Borland code for wx, always write an if statement. I've changed lots of these in the past
chris
Vadim Zeitlin
CE> > int main()
CE> > {
CE> > wxOrientation orient = wxHORIZONTAL;
CE> > orient == wxVERTICAL; // ambiguous error! wtf??
CE> > }
CE> >
CE> > The compiler erroneously complains that orient == wxVERTICAL is
CE> > ambiguous between
CE>
CE> yes, never ever use the == in Borland code for wx, always write an if statement. I've changed lots of these in the past
I'm sure you mean ?: operator and not the == one. AFAIK we've never had
any problem like this before.
Regards,
VZ
Vadim Zeitlin
G> Anyway, here's a quick update of my progress so far:
G>
G> - wxT() macro expansion problem. After some exhaustive testing I have
G> determined that it only seems to have an issue if you're prepending L
G> + "some string literal". It's really an odd bug, for example, if I
G> change L to something else like M or JK then it magically expands
G> properly!
This is because it changes the meaning. M"foo" or JK"foo" doesn't mean
anything (i.e. is a syntax error if the compiler gets to look at it) while
L"foo" is a wide char string, i.e. a single token. Apparently Borland
preprocessor gets confused by this.
G> After finding that out, I changed my earlier fixup on wxT()
G> to this instead:
G>
G> #define wxT(x) wxCONCAT_HELPER_L(x)
G>
G> where wxCONCAT_HELPER_L is defined as
G>
G> #define wxCONCAT_HELPER_L(x) L ## x
G>
G> That corrects the expansion problem under Borland but I need
G> confirmation that this fix will work where x is a macro too.
Normally it wouldn't. But maybe Borland precompiles it wrongly too, who
knows. You could just test it.
G> - Unicode issue in Scintilla.cxx. After checking through the build
G> process I found that _UNICODE was actually not defined for that
G> translation unit. To fix it I made a correction in the build/msw/
G> make.bcc file line 197:
G>
G> $(__wxscintilla_usingdll_p) -D__WXMSW__ $(__WXUNIV_DEFINE_p) $
G> (__UNICODE_DEFINE_p) \
G>
G> Note the addition of $(__UNICODE_DEFINE_p).
The strange thing is that it's not defined for any other compilers
neither. So now I don't understand not why it doesn't compile with Borland
but why does it compile with the others.
Anyhow, I've added the missing Unicode define now, thanks.
G> After comparing to 2.8.10 I also found that the older version does not
G> infact compile in wxScintilla as part of its default build. I was unable
G> to find any references to that translation unit in the make.bcc.
Scintilla stuff was in contrib in 2.8, it only got moved to the core in
2.9.
G> - wxVector<> template issue. Borland unfortunately has trouble dealing
G> with the following non-type template code:
G>
G> template <bool>
G> class foo
G> {};
G>
G> template <typename T>
G> struct bar
G> {
G> foo< T::bool_flag > m_foo;
G> };
G>
G> This created a lot of issues where the metaconstruct wxIf<> was being
G> used. I couldn't find any obvious quick fixes to this. For the time
G> being I've just enabled wxUSE_STL 1 in the setup.h as a workaround.
It might be worth looking at Boost. I think it still supports some version
of Borland, maybe looking at the workarounds they use might help.
G> - issues w/ implicit conversion and overloaded operators. Following
G> code snippet demostrates the problem:
G>
G> class wxString
G> {
G> private:
G> wxString(int);
G> wxString(long);
G> wxString(__int64);
G> };
G>
G> enum wxOrientation
G> {
G> wxHORIZONTAL = 0x04,
G> wxVERTICAL = 0x08
G> };
G>
G> enum wxform {};
G> enum wx {};
G>
G> bool operator==(int lhs, const wxString &rhs) { return true; }
G> bool operator==(wx lhs, wxform rhs) { return true; }
G>
G> int main()
G> {
G> wxOrientation orient = wxHORIZONTAL;
G> orient == wxVERTICAL; // ambiguous error! wtf??
G> }
G>
G> The compiler erroneously complains that orient == wxVERTICAL is
G> ambiguous between
G>
G> bool operator==(int, const wxString &);
G>
G> and
G>
G> bool operator==(int, int);
G>
G> despite the conversion constructor being private in wxString!
It is correct in this, the access specifier doesn't enter overload
resolution. However I have no idea why does it consider an overload
involving a conversion when an exact match is available. This does look
like a compiler bug. The strange thing is that we definitely never saw this
before, might you have some especially defective BC version? I tested early
wx 2.9 with 5.8.something and while I had some issues (and don't remember
if I could resolve them or not, although I think I did) I certainly didn't
see anything like this. You really might want to try a different version.
G> - wxXLocale_Ctag was undefined. For the time being I just undefined
G> wxUse_Locale in the setup.h file
This can be done in wx/msw/chkconf.h inside "#ifdef __BORLANDC__" if it
really can't be fixed.
G> - Multiple declaration error in bitmap.cpp from wx/rawbmp.h.
This is strange too as this code didn't change much since 2.8 so if
Borland could compile it then I don't see why does it fail now. Anyhow, if
it can't be fixed neither you could just undefine wxHAS_RAW_BITMAP in
wx/features.h for Borland.
Good luck,
VZ
Greatwolf
Usually I found that enclosing the entire expression with an extra
parenthesis solves that problem.
Greatwolf
attempts. This will most likely be my last post on this as I have to
get ready to move and will unlikely have time to investigate this
further.
First a bit of good news, I finally got wxmsw 2.9.x to build and link
successfully a week or so ago. Now onto the final bits I had to change
to get this to happen.
- Borland is unable to perform a cast to a class pointer with the
'newer' C++ casting methods unless the class is fully defined at that
point -- a forward declaration is not enough:
class foo;
static_cast<foo *> (&foobar); // this line will give a compile error
In fact, none of the C++ static_cast, dynamic_cast, reinterpret_cast
seems to work. I had to resort to using the uglier old C type cast as
a workaround.
- For some odd reason, the Rogue Wave STL implementation for bcc5.5.1
doesn't fully instantiate the basic_string template members. I got
some unresolved symbols during linking to __nullref and one of the
overloaded basic_string::replace() methods which apparently is called
by basic_string::assign(). After some digging around in the STL string
header files I've determined that '_RWSTD_COMPILE_INSTANTIATE' needs
to be defined for basic_string to be fully instantiated. What's
interesting is that basic_string<wchar_t> and basic_string<char>
doesn't seem to need this. I can only guess that the borland runtime
already has these two instances compiled in.
After the successful build, I compiled wxMinimal and wxAUI to test.
Here's where I ran into something strange, when wxwidget is built as a
debug dll inline disabled, everything runs fine. However, if wxwidget
is built as a release dll with inlining enabled then crashing happens.
wxMinimal runs but it crashes upon exit. wxAUI crashes right away upon
execution. If widgets is built as a static library then everything
runs fine -- in both debug and release.
This is pretty hard to diagnose since if I build it with debug info
then everything behaviors correctly but if built as release then
things start crashing unexpectedly. I did manage to find out that for
wxAUI during initialization when the crash happens the stack trace and
disassembly shows cc3250mt.dll in the delete void* routine(cc3250 is
the dynamic runtime for borland). This is a strong indicator to me
that somehow when inlining is enabled there's a dll boundary violation
somewhere. I also found out that wxMSW 2.8.10 exhibits the same
crashing behavior *if* stl is compiled in.
That's about as far as I got for diagnosing that crashing issue. I
probably won't be troubleshooting that further. Worse comes to worse,
I can just compile wxwidget as a dll with debug on and inlining
disabled or just compile it as a static lib and it'll work fine.
I also managed to build wxwidgets 2.9.x with embarcadero's
compiler(6.21) and those aforementioned issues are no longer there.
- Borland ilinker has issues linking the final executable if the debug
info in it grows too big (~30mb from what I've seen). Surprisingly
this issue is still present in the latest ilinker that comes with
embarcadero's compiler. I have found 3 possible workarounds for this
issue.
1. compile it in release mode without any debug info.
2. don't build wxwidget as a monolithic lib.
3. use the 3rd party ulinker suggested from the borland/embarcadero
forum.
So finally I did get the latest wxmsw branch to build after many
modifications. I'm just wondering if I should submit a patch for it or
not. Maybe put it under contrib branch in case someone else is looking
to build wxwidget with borland/embarcadero's compiler? I'm not sure
where to go from here
Vadim Zeitlin
G> Alright, just thought I'd make one last progress update on my
G> attempts. This will most likely be my last post on this as I have to
G> get ready to move and will unlikely have time to investigate this
G> further.
It would be nice if you could submit the fixes you have done as a patch
(please see http://trac.wxwidgets.org/wiki/HowToSubmitPatches) to avoid
losing them and the time you already spent on this.
G> - Borland is unable to perform a cast to a class pointer with the
G> 'newer' C++ casting methods unless the class is fully defined at that
G> point -- a forward declaration is not enough:
G>
G> class foo;
G>
G> static_cast<foo *> (&foobar); // this line will give a compile error
This is actually the correct behaviour, at least for static and dynamic
casts (I'm not sure about reinterpret_cast<>). Where do we do this? This
needs to be fixed in our code...
G> - For some odd reason, the Rogue Wave STL implementation for bcc5.5.1
G> doesn't fully instantiate the basic_string template members. I got
G> some unresolved symbols during linking to __nullref and one of the
G> overloaded basic_string::replace() methods which apparently is called
G> by basic_string::assign(). After some digging around in the STL string
G> header files I've determined that '_RWSTD_COMPILE_INSTANTIATE' needs
G> to be defined for basic_string to be fully instantiated. What's
G> interesting is that basic_string<wchar_t> and basic_string<char>
G> doesn't seem to need this. I can only guess that the borland runtime
G> already has these two instances compiled in.
I guess you mean the basic_string<uint32_t> used by wxUString?
Anyhow, it's not a problem to define _RWSTD_COMPILE_INSTANTIATE for
Borland if it's needed. Alternatively we could disable wxUString for it
(unfortunately it doesn't have any matching wxUSE_USTRING right now but we
could add it).
G> This is pretty hard to diagnose since if I build it with debug info
G> then everything behaviors correctly but if built as release then
G> things start crashing unexpectedly. I did manage to find out that for
G> wxAUI during initialization when the crash happens the stack trace and
G> disassembly shows cc3250mt.dll in the delete void* routine(cc3250 is
G> the dynamic runtime for borland). This is a strong indicator to me
G> that somehow when inlining is enabled there's a dll boundary violation
G> somewhere.
Don't both the application and wx DLL use the same run-time DLL? If they
don't, it's unsurprising/virtually certain that this will result in such
problems but if they do, then I don't understand what kind of violation can
there be.
G> I also managed to build wxwidgets 2.9.x with embarcadero's
G> compiler(6.21) and those aforementioned issues are no longer there.
Nice to know, could you please update the page at
http://wiki.wxwidgets.org/Supported_Platforms with this information?
BTW, is this new compiler available for download or does it need to be
bought? I don't really need it so I wouldn't do the latter but if I could
download it I could at least test that things build with it before the
release.
G> - Borland ilinker has issues linking the final executable if the debug
G> info in it grows too big (~30mb from what I've seen). Surprisingly
G> this issue is still present in the latest ilinker that comes with
G> embarcadero's compiler. I have found 3 possible workarounds for this
G> issue.
G>
G> 1. compile it in release mode without any debug info.
G> 2. don't build wxwidget as a monolithic lib.
G> 3. use the 3rd party ulinker suggested from the borland/embarcadero
G> forum.
30MB is a lot, but shouldn't be that much on modern hardware, I wonder
what kind of memory management they use (code ported from 16 bit Borland
DOS tools?). Anyhow, I don't have any ideas about this one but doing (2) is
better anyhow.
G> So finally I did get the latest wxmsw branch to build after many
G> modifications. I'm just wondering if I should submit a patch for it or
G> not.
Yes, of course. Maybe I won't apply all of it but at least some parts
should be uncontroversial.
Thanks,
VZ
Greatwolf
changes made. Ticket page can be found here:
http://trac.wxwidgets.org/ticket/12558
Some things to note, I managed to find a workaround for the non-type
template problem. It turns out to be quite simple actually, just
enclose the non-type argument with extra parentheses. I don't know why
I didn't think to try this earlier.
The overloaded ambiguity issue I changed my previous fix. I just
commented out the overloaded enum comparisons instead. This is better
than the alternative of putting cast or temp object construct on
everywhere it's used. Recall in my previous post that this ambiguity
issue only comes up if all 3 of these conditions are met:
- a class has a conversion constructor for an integral type
- overloading the comparison operators to compare between an integral
type and some class type as its two operands
- overloading comparison operators to compare between two defined enum
integral types as operands
Too much of the codebase relies on the conveniences provided by the
first 2 conditions as well as client code that uses it. Changing all
these places would be too tedious and would make the code more
difficult to read. So it made the most sense to just fix the last
condition; I could live with a few warnings ;)
> This is actually the correct behaviour, at least for static and dynamic
> casts (I'm not sure about reinterpret_cast<>). Where do we do this? This
> needs to be fixed in our code...
just something I found out while testing and debugging the c++ casting
behavior in bcc551.
>
> I guess you mean the basic_string<uint32_t> used by wxUString?
>
> Anyhow, it's not a problem to define _RWSTD_COMPILE_INSTANTIATE for
> Borland if it's needed. Alternatively we could disable wxUString for it
> (unfortunately it doesn't have any matching wxUSE_USTRING right now but we
> could add it).
>
>
> don't, it's unsurprising/virtually certain that this will result in such
> problems but if they do, then I don't understand what kind of violation can
> there be.
>
dynamic runtime for this compiler. To be certain I cracked open the
sample demos and the built wxmsw dll with a PE viewer and indeed they
both have cc32xx.dll in their imported section. So I am quite baffled
as to what the issue might be. Though I'm betting it has something to
do with the roguewave stl implementation.
>
> BTW, is this new compiler available for download or does it need to be
> bought? I don't really need it so I wouldn't do the latter but if I could
> download it I could at least test that things build with it before the
> release.
The IDE won't be accessible without a license after the 30-day trial,
however the commandline tools will still be functional though.
Vadim Zeitlin
G> Just finished moving and I found some time to upload a patch to the
G> changes made.
Thanks! I've left some comments in the patch, I hope you could improve it
a bit and it could be applied quickly (i.e. in time for 2.9.2).
G> Some things to note, I managed to find a workaround for the non-type
G> template problem. It turns out to be quite simple actually, just
G> enclose the non-type argument with extra parentheses. I don't know why
G> I didn't think to try this earlier.
Wow, I don't know how did you find it at all. I'd have never thought about
this, it's just plain weird.
G> The overloaded ambiguity issue I changed my previous fix. I just
G> commented out the overloaded enum comparisons instead. This is better
G> than the alternative of putting cast or temp object construct on
G> everywhere it's used. Recall in my previous post that this ambiguity
G> issue only comes up if all 3 of these conditions are met:
G>
G> - a class has a conversion constructor for an integral type
G> - overloading the comparison operators to compare between an integral
G> type and some class type as its two operands
G> - overloading comparison operators to compare between two defined enum
G> integral types as operands
G>
G> Too much of the codebase relies on the conveniences provided by the
G> first 2 conditions as well as client code that uses it. Changing all
G> these places would be too tedious and would make the code more
G> difficult to read. So it made the most sense to just fix the last
G> condition; I could live with a few warnings ;)
Well, those comparison operators will go away sooner or later (as they
involve deprecated symbols) so hopefully it won't be a problem in the
future.
G> > This is actually the correct behaviour, at least for static and dynamic
G> > casts (I'm not sure about reinterpret_cast<>). Where do we do this? This
G> > needs to be fixed in our code...
G>
G> I don't believe I saw any use of reinterpret_cast in wxwidgets.
We do use it:
% git grep reinterpret_cast include/wx src|wc -l
196
G> > BTW, is this new compiler available for download or does it need to be
G> > bought? I don't really need it so I wouldn't do the latter but if I could
G> > download it I could at least test that things build with it before the
G> > release.
G>
G> The latest trial version can be downloaded from the embarcadero site.
G> The IDE won't be accessible without a license after the 30-day trial,
G> however the commandline tools will still be functional though.
I've downloaded it but can't install it because I didn't get the
activation email... I guess I'll just wait more. I'm a bit confused about
the version of the compiler included in this download, is it still 5.5.1
(that you test against in your patch)?
Thanks,
VZ
Greatwolf
though I probably should have posted it on this thread.
On Oct 13, 2:24 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
>
>
> I'm a bit confused about
> the version of the compiler included in this download, is it still 5.5.1
> (that you test against in your patch)?
>
free borland commandline tools comes with compiler 5.5.1.
Vadim Zeitlin
G> I've revised and resubmit the patch.
Thanks, I'll apply it after dealing with the patches I am working with
already currently.
G> Add a few notes in there too
G> though I probably should have posted it on this thread.
Yes, I'd prefer to discuss the build issues here, it's more convenient.
G> On Oct 13, 2:24 pm, Vadim Zeitlin <va...@wxwidgets.org> wrote:
G> > I'm a bit confused about
G> > the version of the compiler included in this download, is it still 5.5.1
G> > (that you test against in your patch)?
G>
G> No, the compiler version for that download is 6.21 last I checked. The
G> free borland commandline tools comes with compiler 5.5.1.
I initially thought to suggest to not support 5.5.1 any more but if you
can make it work with the (relatively) limited changes then it's probably
better to keep support for it because this 6.21 is not easy to get hold of:
I downloaded it twice but never got the email with the serial number or
whatever I need to install it (and it's not a spam/similar problem, their
email never reached our SMTP server). So unfortunately I won't be able to
test this myself.
Regards,
VZ
Greatwolf
On Oct 21, 9:36 am, Vadim Zeitlin <va...@wxwidgets.org> wrote:
>
> I initially thought to suggest to not support 5.5.1 any more but if you
> can make it work with the (relatively) limited changes then it's probably
> better to keep support for it because this 6.21 is not easy to get hold of:
That's unfortunately, it would have been nice if I wasn't the only one
testing it :(
>
> One remaining question is about the (new AFAIR) change in src/common/mimecmn.cpp -- what is this for? Is it even intentional?
>
No it's not. I was isolating the code section that indirectly depends
on basic_string::replace and assign. I forgot to uncomment that -- an
oversight on my part.
>
> Another question is about wxCOMPILER_NO_OVERLOAD_ON_ENUM definition: shouldn't we test for BCC version being <= 0x551 instead of being
> equal to it?
>
I'm not really sure about this one. I suppose we could use the <=0x551
so I've made that change in my latest patch revision. On the other
hand, I recall seeing a preprocessor guard that errors out if borland
is less than a certain version. Originally when I put that check in I
was thinking bcc551 would probably be the last supported version under
wxwidget's future branches (> 2.8.x).
>
> AFAICS this shouldn't be a problem. I'd still like to call the new macro wxPREPEND_L though.
>
okie I've added some wxAPPEND_* in there as well. Just to follow the
same pattern as wxCOMPILE_NO_OVERLOAD_ON_ENUM, those macros are used
only if wxCONCAT_WORKAROUND is defined . I can't think of a better
name for these groups of macros so I just called it
wxCONCAT_WORKAROUND for the moment.
>
> ...if can tell us what changes exactly are needed at makefiles level I should be able to update bakefiles to generate the wanted output.
>
okie, I've modifed the needed changes in makefile.bcc for how linking
needs to happen. It's straightforward for the most part. An extra
option -Gi is now passed to the linker telling it to generate a import
lib along side the dll being linked. The second line has been changed
from implib to move to rename the imported lib. I didn't use rename
here because if another import lib with the same name already exist
then renaming will fail returning non-zero back to make. OTOH, move
will actually just overwrite that existing file so its behavior is
closer to implib in that respect.
Made some other slight changes and clean ups on the sample sources.
Replaced _( ) usage with wxT( ), added extra parentheses around
tenary's so borland doesn't complain etc.
Finally, I also did a test build with the patch using bcc551, bcc621,
mingw gcc4.4.1 and msvc9. It compiles successfully under all of them
for me so that's a good sign. (mingw gcc compiles god awfully slow
though, it doesn't look like precomp is being used)
Hopefully this patch is in a more acceptable state and you're able to
apply the proposed changes to the trunk.
Greatwolf
own string implementation instead of using the compiler's std::string.
I defined wxUSE_STL_BASED_WXSTRING=0 but I'm running into some compile
errors in wx/string.h:
Error E2285 ..\..\include\wx/string.h 1386: Could not find a match for
'wxScopedWCharBuffer::wxScopedCharTypeBuffer(const wchar_t *)' in
function wxString::ToStdWstring() const
A quick test build with VC9 also gives a similar error:
..\..\include\wx/string.h(1386) : error C2664:
'wxScopedCharTypeBuffer<T>::wxScopedCharTyp
eBuffer(const wxScopedCharTypeBuffer<T> &)' : cannot convert parameter
1 from 'const wchar
_t *' to 'const wxScopedCharTypeBuffer<T> &'
with
[
T=wchar_t
]
Reason: cannot convert from 'const wchar_t *' to 'const
wxScopedCharTypeBuffer<T>'
with
[
T=wchar_t
]
No constructor could take the source type, or constructor
overload resolution was
ambiguous
So it looks like wxScopedWCharBuffer doesn't have a ctor that takes a
const wchar_t*. Is it just a coding error or is the code relying on an
implicit conversion somewhere? How should this be resolved?
wxStdWideString ToStdWstring() const
{
wxScopedWCharBuffer buf(wc_str());
return wxStdWideString(buf.data(), buf.length());
}
btw, what's the current status of my last patch submission?
Thanks
Vadim Zeitlin
G> I thought I'd give the build another try and have it use wxwidget's
G> own string implementation instead of using the compiler's std::string.
Not sure if it's a good idea. Modern std::string implementations are
better than the old wxString one (which corresponds to a typical
implementation of std::string from 15 years ago).
G> So it looks like wxScopedWCharBuffer doesn't have a ctor that takes a
G> const wchar_t*. Is it just a coding error or is the code relying on an
G> implicit conversion somewhere? How should this be resolved?
G>
G> wxStdWideString ToStdWstring() const
G> {
G> wxScopedWCharBuffer buf(wc_str());
G> return wxStdWideString(buf.data(), buf.length());
G> }
It's a bug, this code hasn't been tested in !wxUSE_STL_BASED_WXSTRING &&
wxUSE_UNICODE_WCHAR case (in !wxUSE_UNICODE_WCHAR case wc_str() already
returns a buffer and not "const wchar_t*" so this is ok). I don't see any
elegant fix for this so I've just added an #if wxUSE_UNICODE_WCHAR test and
wrote it differently for the two cases (see r65928).
G> btw, what's the current status of my last patch submission?
Sorry, I didn't have time to look at it yet. I'm trying to work on my
patches queue in more or less chronological order and I'm still a few
months away from it :-(
Regards,
VZ
chris elliott
On 23/10/2010 22:39, Greatwolf wrote:
>
>
> On Oct 21, 9:36 am, Vadim Zeitlin<va...@wxwidgets.org> wrote:
>>
I have a variety of bcc versions, and was intending to test them. Two
questions
1) Does the bcc551fix-revision2.diff patch supercede all the others. or
do i have to apply them all in turn ?
2) Do I still need to #define _USE_OLD_RW_STL - or are there other
#defines I ne4ed to use to get this to work ?
chris
Vadim Zeitlin
ce> I have a variety of bcc versions, and was intending to test them.
TIA! I'll wait for the results of your tests before applying the patch.
In case you do it yourself (I'd be glad if you could), I'd like to globally
rename wxCONCAT_WORKAROUND to wxCOMPILER_NEEDS_CONCAT_WORKAROUND just for
consistency. Also, the changes to the generated files shouldn't be
committed as they would be overwritten after running bakefile anyhow, if
these changes are all that we need, we should modify bakefiles to create
them instead.
Finally, I don't know what is this with replacing many occurrence of _()
with wxT(). This wasn't in the previous patch versions and I really don't
think it's the right thing to do, the code using _() should definitely
compile, what's the problem with it?
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 ?
No, the last patch is the only one to be applied (it's -revision3 BTW).
ce> 2) Do I still need to #define _USE_OLD_RW_STL - or are there other
ce> #defines I ne4ed to use to get this to work ?
Only the OP can answer this authoritatively but I don't think you need to
define anything.
Regards,
VZ
Vadim Zeitlin
G> > I initially thought to suggest to not support 5.5.1 any more but if you
G> > can make it work with the (relatively) limited changes then it's probably
G> > better to keep support for it because this 6.21 is not easy to get hold of:
G> > I downloaded it twice but never got the email with the serial number ...
G>
G> That's unfortunately, it would have been nice if I wasn't the only one
G> testing it :(
I've retried again and this time I got the trial serial number so I'll try
to install it soon.
G> > ...if can tell us what changes exactly are needed at makefiles level I
G> > should be able to update bakefiles to generate the wanted output.
G>
G> okie, I've modifed the needed changes in makefile.bcc for how linking
G> needs to happen. It's straightforward for the most part. An extra
G> option -Gi is now passed to the linker telling it to generate a import
G> lib along side the dll being linked.
We probably can just add it to LDFLAGS by default.
G> The second line has been changed from implib to move to rename the
G> imported lib.
But this can't be done easily without modifying bakefile itself AFAICS
because the use of implib comes from its rules/makefile_defs_borland.bkl.
Or maybe we could redefine __LINK_DLL_CMD in wx bakefile? Vaclav, are you
interested in changing bakefile to support this -Gi linker option or should
we try to work around this in wx?
G> Made some other slight changes and clean ups on the sample sources.
I'd really prefer to separate this from the main patch as it's quite
unrelated.
G> Finally, I also did a test build with the patch using bcc551, bcc621,
G> mingw gcc4.4.1 and msvc9. It compiles successfully under all of them
G> for me so that's a good sign.
Definitely, thanks a lot for your testing!
G> Hopefully this patch is in a more acceptable state and you're able to
G> apply the proposed changes to the trunk.
Yes, as I just wrote in reply to Chris, I have only one cosmetic remark
(renaming of wxCONCAT_WORKAROUND) about it, otherwise all the changes to
the sources (i.e. not makefiles which should wait for the bakefiles update
nor samples which should be changed independently if at all -- if we change
them anyhow, I'd rather remove wxT() completely) can be applied without any
problem now.
Thanks again!
VZ
chris elliott
On 22/09/2010 06:38, Greatwolf wrote:
> - For some odd reason, the Rogue Wave STL implementation for bcc5.5.1
> doesn't fully instantiate the basic_string template members. I got
> some unresolved symbols during linking to __nullref and one of the
> overloaded basic_string::replace() methods which apparently is called
> by basic_string::assign(). After some digging around in the STL string
> header files I've determined that '_RWSTD_COMPILE_INSTANTIATE' needs
> to be defined for basic_string to be fully instantiated. What's
> interesting is that basic_string<wchar_t> and basic_string<char>
> doesn't seem to need this. I can only guess that the borland runtime
> already has these two instances compiled in.
>
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 at
ftp://ftp.styx.cabel.net/pub/UniLink/ [current version ulnb0117.zip ]
}
Greatwolf
> 1) Does the bcc551fix-revision2.diff patch supercede all the others. or
The last one fixes borland template errors for wx/meta/
implicitconversion.h that was recently added.
On Oct 29, 9:47 am, 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
>
>
resolve those linking errors. I didn't include it in the patch because
of the runtime crash when building it in release with dll share
enabled. I googled _RWSTD_COMPILE_INSTANTIATE and found this:
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 the cause of this runtime crash I'm observing.
However, if you're building it as a static lib though,
_RWSTD_COMPILE_INSTANTIATE should be ok.
Another workaround I'm investigating is to just create a small
independent project that just instantiates the missing basic_string
symbols and have it build with inlining and opts disabled. The
produced obj/lib will then be included as part of the link when
building wxMSW. This way the rest of the library can be built with
normal release mode config and the problematic part of basic_string
will be built with different config so it doesn't crash.
I'm not sure how best to apply this to the trunk though. This is a
specific borland workaround for the older compilers that use the
roguewave stl implementation. As I recall, C++ Builder 6 and later
uses different stl implementations(bcc560 uses stlport, bcc582-bcc621
uses dinkumware). It's probably not a good idea mixing this code in.
What are your thoughts on this?
Greatwolf
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.
> _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/[current version ulnb0117.zip ]
>
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
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
code for it is the best idea.
Vadim Zeitlin
G> _RWSTD_COMPILE_INSTANTIATE can be defined when building wxmsw to
G> resolve those linking errors. I didn't include it in the patch because
G> of the runtime crash when building it in release with dll share
G> enabled. I googled _RWSTD_COMPILE_INSTANTIATE and found this:
G>
G> http://www.boost.org/doc/libs/1_39_0/boost/regex/config/borland.hpp
G>
G> The pragma message is of particular interest because it seems to
G> pertain exactly to the cause of this runtime crash I'm observing.
G> However, if you're building it as a static lib though,
G> _RWSTD_COMPILE_INSTANTIATE should be ok.
So should _RWSTD_COMPILE_INSTANTIATE be defined by default for Borland in
static build?
G> Another workaround I'm investigating is to just create a small
G> independent project that just instantiates the missing basic_string
G> symbols and have it build with inlining and opts disabled. The
G> produced obj/lib will then be included as part of the link when
G> building wxMSW. This way the rest of the library can be built with
G> normal release mode config and the problematic part of basic_string
G> will be built with different config so it doesn't crash.
I'm not sure to understand how exactly would this work... Also, what are
the alternatives? I.e. do you know how does Boost.Regex deal with it?
Thanks,
VZ
Chris Elliott
On 30 Oct 2010, at 23:06, Greatwolf wrote:
>
>> 1) Does the bcc551fix-revision2.diff patch supercede all the others. or
>> do i have to apply them all in turn ?
>
> Just to add to this, you'll want to apply revision 3 and revision 4.
> The last one fixes borland template errors for wx/meta/
> implicitconversion.h that was recently added.
ok
>>
>
> _RWSTD_COMPILE_INSTANTIATE can be defined when building wxmsw to
> resolve those linking errors. I didn't include it in the patch because
> of the runtime crash when building it in release with dll share
> enabled. I googled _RWSTD_COMPILE_INSTANTIATE and found this:
>
> 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 the cause of this runtime crash I'm observing.
> However, if you're building it as a static lib though,
> _RWSTD_COMPILE_INSTANTIATE should be ok.
yes, I want to make sure the default build with the freely downloadable version compiles and so i will look at this
>
> Another workaround I'm investigating is to just create a small
> independent project that just instantiates the missing basic_string
> symbols and have it build with inlining and opts disabled. The
> produced obj/lib will then be included as part of the link when
> building wxMSW. This way the rest of the library can be built with
> normal release mode config and the problematic part of basic_string
> will be built with different config so it doesn't crash.
>
> I'm not sure how best to apply this to the trunk though. This is a
> specific borland workaround for the older compilers that use the
> roguewave stl implementation. As I recall, C++ Builder 6 and later
> uses different stl implementations(bcc560 uses stlport, bcc582-bcc621
> uses dinkumware). It's probably not a good idea mixing this code in.
>
> What are your thoughts on this?\\
Traditionally, we have tested for various Borland [watcom/vc6...] versions with ifdef and I think I would continue in this tradition. I'd be happy if the free version and the latest version are both OK
chris
>