↑ ↓ ← → "W這dzimierz Skiba" <abx abx.art.pl>
writes:
Walter Bright <newshound digitalmars.com> wrote in
news:e2uoho$1pbq$1 digitaldaemon.com:
Fixed wxWindows problem. -Walter
Many, many thanks! Works fine.
Another problem is related to linking. We have series of labels (names of
controls)
which we introduce in headers like:
extern const wxChar wxStaticBoxNameStr[];
and later within .cpp file we give them value, like:
extern const wxChar wxStaticBoxNameStr[] = "groupBox";
(with typedef char wxChar;)
Every keyword in these constructions was added to please one of the compilers
or
build mode but they in current shape cause linking problem with DMC:
.\..\..\lib\dmc_lib\wxmsw27d_core.lib(sizer)
Error 42: Symbol Undefined ?wxStaticBoxNameStr 3QBDB (const char const
*const
wxStaticBoxNameStr)
We had in this place char* rather than char[] and it worked fine but now it is
failing. The strange thing is that only some of labels cause this linking
error. Any
idea?
ABX
↑ ↓ ← → Walter Bright <newshound digitalmars.com>
writes:
W這dzimierz Skiba wrote:
We had in this place char* rather than char[] and it worked fine but now it is
failing. The strange thing is that only some of labels cause this linking
error. Any
idea?
No, I don't know what's going on at the moment. But can you live with it
for now?
↑ ↓ ← → "W這dzimierz Skiba" <abx abx.art.pl>
writes:
Walter Bright <newshound digitalmars.com> wrote in
news:e38sj1$2t9l$1 digitaldaemon.com:
Wlodzimierz Skiba wrote:
We had in this place char* rather than char[] and it worked fine but
now it is failing. The strange thing is that only some of labels
cause this linking error. Any idea?
No, I don't know what's going on at the moment. But can you live with
it for now?
Not sure what kind of 'now' are you asking for :( On one hand it's kind of
private
problem since it's in development branch (ie. not in any release yet). OTOH the
relase of these sources was planned at the end of April and we delay it due to
not
finished work around scripts for using more automation in releases.
ABX
↑ ↓ ← → Walter Bright <newshound digitalmars.com>
writes:
W這dzimierz Skiba wrote:
Walter Bright <newshound digitalmars.com> wrote in
news:e38sj1$2t9l$1 digitaldaemon.com:
Wlodzimierz Skiba wrote:
We had in this place char* rather than char[] and it worked fine but
now it is failing. The strange thing is that only some of labels
cause this linking error. Any idea?
it for now?
Not sure what kind of 'now' are you asking for :( On one hand it's kind of
private
problem since it's in development branch (ie. not in any release yet). OTOH
the
relase of these sources was planned at the end of April and we delay it due to
not
finished work around scripts for using more automation in releases.
I mean can you live with it without a change in the compiler?
↑ ↓ ← → "W這dzimierz Skiba" <abx abx.art.pl>
writes:
Walter Bright <newshound digitalmars.com> wrote in
news:e3de6i$2o26$1 digitaldaemon.com:
Not sure what kind of 'now' are you asking for :( On one hand it's
kind of private problem since it's in development branch (ie. not in
any release yet). OTOH the relase of these sources was planned at the
end of April and we delay it due to not finished work around scripts
for using more automation in releases.
I mean can you live with it without a change in the compiler?
I don't think so :( These labels are part of public headers and replacing them
from
const char* to char* would require other people to change where they use them.
And
doing such change for only single release (until it's not fixed) would be not
nice
for them. Moreover I don't even know if they can be made non-const due to
requirements of other ports.
OTOH I don't want to put any pressure on you so I can live with informing
people
that this issue is 'under fixing' and the temporary fix it to do following
changes
in local copy: .... All in all it is for wxWidgets 2.7.0 which is named
development
release so things can be broken in this release ;)
ABX
↑ ↓
← → "Matthew" <nowhere noaddress.co.us>
writes:
I've had the same problem with Pantheios.
I've just had to special-case DMC++, as in
#if defined(__DMC__)
extern const char *FE_SIMPLE_PROCESS_IDENTITY;
#else /* ? compiler */
extern const char FE_SIMPLE_PROCESS_IDENTITY[];
#endif /* compiler */
"W這dzimierz Skiba" <abx abx.art.pl> wrote in message
news:e383ac$19e6$1 digitaldaemon.com...
Walter Bright <newshound digitalmars.com> wrote in
news:e2uoho$1pbq$1 digitaldaemon.com:
Fixed wxWindows problem. -Walter
Many, many thanks! Works fine.
Another problem is related to linking. We have series of labels (names of
controls)
which we introduce in headers like:
extern const wxChar wxStaticBoxNameStr[];
and later within .cpp file we give them value, like:
extern const wxChar wxStaticBoxNameStr[] = "groupBox";
(with typedef char wxChar;)
Every keyword in these constructions was added to please one of the
compilers or
build mode but they in current shape cause linking problem with DMC:
.\..\..\lib\dmc_lib\wxmsw27d_core.lib(sizer)
Error 42: Symbol Undefined ?wxStaticBoxNameStr 3QBDB (const char const
*const
wxStaticBoxNameStr)
We had in this place char* rather than char[] and it worked fine but now
it is
failing. The strange thing is that only some of labels cause this linking
error. Any
idea?
ABX
↑ ↓ ← → Walter Bright <newshound digitalmars.com>
writes:
Matthew wrote:
I've had the same problem with Pantheios.
I've just had to special-case DMC++, as in
#if defined(__DMC__)
extern const char *FE_SIMPLE_PROCESS_IDENTITY;
#else /* ? compiler */
extern const char FE_SIMPLE_PROCESS_IDENTITY[];
#endif /* compiler */
The compiler doesn't emit data for unreferenced const declarations. To
make it work,
extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo";
will do it.
↑ ↓ ← → "Matthew" <nowhere noaddress.co.us>
writes:
It's not unreferenced. See attached file. (And all other compilers/linkers
do the 'right' thing, so I'm assuming it is genuinely right. It certainly
accords with my understanding of C these last 18 yrs. <g>)
"Walter Bright" <newshound digitalmars.com> wrote in message
news:e3b89g$13r6$1 digitaldaemon.com...
Matthew wrote:
I've had the same problem with Pantheios.
I've just had to special-case DMC++, as in
#if defined(__DMC__)
extern const char *FE_SIMPLE_PROCESS_IDENTITY;
#else /* ? compiler */
extern const char FE_SIMPLE_PROCESS_IDENTITY[];
#endif /* compiler */
The compiler doesn't emit data for unreferenced const declarations. To
make it work,
extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo";
will do it.
↑ ↓ ← → Walter Bright <newshound digitalmars.com>
writes:
I can't compile your file because it is incomplete. However, this file:
--------------
extern const char FE_SIMPLE_PROCESS_IDENTITY[] = "foo";
const char *f()
{
return FE_SIMPLE_PROCESS_IDENTITY;
}
--------------
compiles to:
--------------
FLAT group
includelib SNN.lib
public ?f YAPBDXZ
_TEXT segment
assume CS:_TEXT
?f YAPBDXZ:
mov EAX,offset FLAT:_DATA
ret
_TEXT ends
_DATA segment
D0 db 066h,06fh,06fh,000h
_DATA ends
--------------
So it is put in the object file, it just isn't made global. So, as a
workaround, I suggest either removing the 'const' or referencing it via
a function.
Matthew wrote:
It's not unreferenced. See attached file. (And all other compilers/linkers
do the 'right' thing, so I'm assuming it is genuinely right. It certainly
accords with my understanding of C these last 18 yrs. <g>)
"Walter Bright" <newshound digitalmars.com> wrote in message
news:e3b89g$13r6$1 digitaldaemon.com...
Matthew wrote:
I've had the same problem with Pantheios.
I've just had to special-case DMC++, as in
#if defined(__DMC__)
extern const char *FE_SIMPLE_PROCESS_IDENTITY;
#else /* ? compiler */
extern const char FE_SIMPLE_PROCESS_IDENTITY[];
#endif /* compiler */
make it work,
extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo";
will do it.
↑ ↓ ← → "Matthew" <matthew hat_synesis.dot_.com.dot_.au>
writes:
So you're saying that, for DMC++, the const qualifier means that the extern
aspect is ignored? Do I understand correctly?
I presume that that's not standard, but don't _know_. Am interested to hear
your take on that.
"Walter Bright" <newshound digitalmars.com> wrote in message
news:e3bd9n$1dsu$1 digitaldaemon.com...
I can't compile your file because it is incomplete. However, this file:
--------------
extern const char FE_SIMPLE_PROCESS_IDENTITY[] = "foo";
const char *f()
{
return FE_SIMPLE_PROCESS_IDENTITY;
}
--------------
compiles to:
--------------
FLAT group
includelib SNN.lib
public ?f YAPBDXZ
_TEXT segment
assume CS:_TEXT
?f YAPBDXZ:
mov EAX,offset FLAT:_DATA
ret
_TEXT ends
_DATA segment
D0 db 066h,06fh,06fh,000h
_DATA ends
--------------
So it is put in the object file, it just isn't made global. So, as a
workaround, I suggest either removing the 'const' or referencing it via a
function.
Matthew wrote:
It's not unreferenced. See attached file. (And all other
compilers/linkers do the 'right' thing, so I'm assuming it is genuinely
right. It certainly accords with my understanding of C these last 18 yrs.
<g>)
"Walter Bright" <newshound digitalmars.com> wrote in message
news:e3b89g$13r6$1 digitaldaemon.com...
Matthew wrote:
I've had the same problem with Pantheios.
I've just had to special-case DMC++, as in
#if defined(__DMC__)
extern const char *FE_SIMPLE_PROCESS_IDENTITY;
#else /* ? compiler */
extern const char FE_SIMPLE_PROCESS_IDENTITY[];
#endif /* compiler */
make it work,
extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo";
will do it.
↑ ↓ ← → Walter Bright <newshound digitalmars.com>
writes:
Matthew wrote:
So you're saying that, for DMC++, the const qualifier means that the extern
aspect is ignored? Do I understand correctly?
I presume that that's not standard, but don't _know_. Am interested to hear
your take on that.
I'd have to go reread the spec carefully on that to see.
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next