Thread overview | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
April 29, 2006 DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Fixed wxWindows problem. -Walter http://ftp.digitalmars.com/Digital_Mars_C++/Patch/beta.zip http://www.digitalmars.com/download/freecompiler.html |
May 02, 2006 Re: DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
May 03, 2006 Re: DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to W³odzimierz Skiba | W³odzimierz 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?
|
May 03, 2006 Re: DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to W³odzimierz Skiba | 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³odzimierz 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 |
May 03, 2006 Re: DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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.
|
May 03, 2006 Re: DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments: | 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. |
May 03, 2006 Re: DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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 */
>> The compiler doesn't emit data for unreferenced const declarations. To
>> make it work,
>>
>> extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo";
>>
>> will do it.
>
>
|
May 03, 2006 Re: DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 */ >>> The compiler doesn't emit data for unreferenced const declarations. To make it work, >>> >>> extern char FE_SIMPLE_PROCESS_IDENTITY[] = "foo"; >>> >>> will do it. >> |
May 04, 2006 Re: DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
May 04, 2006 Re: DMC++ 8.48.5 | ||||
---|---|---|---|---|
| ||||
Posted in reply to W³odzimierz Skiba | W³odzimierz 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?
>> 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.
I mean can you live with it without a change in the compiler?
|
Copyright © 1999-2021 by the D Language Foundation