Fixed wxWindows problem. -Walter

http://ftp.digitalmars.com/Digital_Mars_C++/Patch/beta.zip

http://www.digitalmars.com/download/freecompiler.html

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

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?

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

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.

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.

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. 
> 
> 

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.
>> 

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

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?