Quantcast

Producing a cegcc binutils/gcc patchset, after all

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Producing a cegcc binutils/gcc patchset, after all

Paul Sokolovsky
Hello,

I'd like to ask people who worked on producing a cegcc patchset/porting
cegcc to newer versions of binutils/gcc to share any results they have,
no matter how incomplete or preliminary they are (I in particular cc:
Pavel Pavlov who worked on this at the summer per his posts to the
mailing list). Just seeing size of patches and curious peek inside can
give info/motivation someone needs to continue the work.

--
Best regards,
 Paul                          mailto:[hidden email]

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Producing a cegcc binutils/gcc patchset, after all

Paul Sokolovsky
Hello,

Well, ok, should have read the list archive a bit more ;-). Pedro
Alves' cleanup: http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2839

I'd still ask for other parties' patchsets, as that one is year's old,
and for gcc only apparently.

On Thu, 16 Dec 2010 05:55:23 +0200
Paul Sokolovsky <[hidden email]> wrote:

> Hello,
>
> I'd like to ask people who worked on producing a cegcc
> patchset/porting cegcc to newer versions of binutils/gcc to share any
> results they have, no matter how incomplete or preliminary they are
> (I in particular cc: Pavel Pavlov who worked on this at the summer
> per his posts to the mailing list). Just seeing size of patches and
> curious peek inside can give info/motivation someone needs to
> continue the work.
>
> --
> Best regards,
>  Paul                          mailto:[hidden email]



--
Best regards,
 Paul                          mailto:[hidden email]

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Producing a cegcc binutils/gcc patchset, after all

Vincent Torri


On Thu, 16 Dec 2010, Paul Sokolovsky wrote:

> Hello,
>
> Well, ok, should have read the list archive a bit more ;-). Pedro
> Alves' cleanup: http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2839
>
> I'd still ask for other parties' patchsets, as that one is year's old,
> and for gcc only apparently.

there was also an attempt to put some cegcc parts into the mingw-w64
project. Maybe you can contact them to know what has been done and what
needs to be done

regards

Vincent Torri

>
> On Thu, 16 Dec 2010 05:55:23 +0200
> Paul Sokolovsky <[hidden email]> wrote:
>
>> Hello,
>>
>> I'd like to ask people who worked on producing a cegcc
>> patchset/porting cegcc to newer versions of binutils/gcc to share any
>> results they have, no matter how incomplete or preliminary they are
>> (I in particular cc: Pavel Pavlov who worked on this at the summer
>> per his posts to the mailing list). Just seeing size of patches and
>> curious peek inside can give info/motivation someone needs to
>> continue the work.
>>
>> --
>> Best regards,
>>  Paul                          mailto:[hidden email]
>
>
>
> --
> Best regards,
> Paul                          mailto:[hidden email]
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Cegcc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/cegcc-devel
>
>

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Producing a cegcc binutils/gcc patchset, after all

Paul Sokolovsky
Hello,

On Thu, 16 Dec 2010 07:17:27 +0100 (CET)
Vincent Torri <[hidden email]> wrote:

>
>
> On Thu, 16 Dec 2010, Paul Sokolovsky wrote:
>
> > Hello,
> >
> > Well, ok, should have read the list archive a bit more ;-). Pedro
> > Alves' cleanup:
> > http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2839
> >
> > I'd still ask for other parties' patchsets, as that one is year's
> > old, and for gcc only apparently.
>
> there was also an attempt to put some cegcc parts into the mingw-w64
> project. Maybe you can contact them to know what has been done and
> what needs to be done

I skimmed over the cegcc-devel archive for about one year's depth,
and didn't see anything related, do you have any references (like list
archive links)? It would be nice to have them at the top of non-busy
list archive for the people who want to know status of the project.

>
> regards
>
> Vincent Torri
>

--
Best regards,
 Paul                          mailto:[hidden email]

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Producing a cegcc binutils/gcc patchset, after all

Danny Backx
In reply to this post by Paul Sokolovsky
The src/gcc-4.4.0 tree contains stuff which I believe to work, except
when you target WinCE > 6.1 and try to build e.g. C++ DLLs.

The toolset does still produce working results, in my experience, for
WinCE 6.5 if you avoid such DLLs. And it works for C++ if WinCE <= 6.1.

But this is from memory, I may have forgotten some aspects.

Note that I can provide SVN write access on the cegcc project for those
who want to do real work on it.

        Danny

On Thu, 2010-12-16 at 06:11 +0200, Paul Sokolovsky wrote:

> Hello,
>
> Well, ok, should have read the list archive a bit more ;-). Pedro
> Alves' cleanup: http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2839
>
> I'd still ask for other parties' patchsets, as that one is year's old,
> and for gcc only apparently.
>
> On Thu, 16 Dec 2010 05:55:23 +0200
> Paul Sokolovsky <[hidden email]> wrote:
>
> > Hello,
> >
> > I'd like to ask people who worked on producing a cegcc
> > patchset/porting cegcc to newer versions of binutils/gcc to share any
> > results they have, no matter how incomplete or preliminary they are
> > (I in particular cc: Pavel Pavlov who worked on this at the summer
> > per his posts to the mailing list). Just seeing size of patches and
> > curious peek inside can give info/motivation someone needs to
> > continue the work.
> >
> > --
> > Best regards,
> >  Paul                          mailto:[hidden email]
>
>
>

--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Some cegcc issues, was: Re: Producing a cegcc binutils/gcc patchset, after all

Paul Sokolovsky
Hello,

On Thu, 16 Dec 2010 17:25:57 +0100
Danny Backx <[hidden email]> wrote:

> The src/gcc-4.4.0 tree contains stuff which I believe to work, except
> when you target WinCE > 6.1 and try to build e.g. C++ DLLs.
>
> The toolset does still produce working results, in my experience, for
> WinCE 6.5 if you avoid such DLLs. And it works for C++ if WinCE <=
> 6.1.

Well, have to say, trying cegcc after some break (cursory usage before)
initially made me disappointed. I immediately hit this issue:
http://www.mail-archive.com/cegcc-devel@.../msg03053.html ,
and after patching it, got seemingly non-startable application. But it
turned out that it started and went well into daemon mode, and when I
compiled and linked in resources even showed UI ;-). By now I
quickly-ported (from eVC) FtpSvr and GSPlayer, and both seem to work.
But they are pretty sizy (-static), and when compiled without static,
it throws auro-import warning on linking against libstdc++.dll. Is
auto-import actually supported on arm-pe?

And back to the issue at that link, I worked it around with the
following patch:

-BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW);
+BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW);
-#define Shell_NotifyIcon Shell_NotifyIconW
+//#define Shell_NotifyIcon Shell_NotifyIconW

But where's correct place to resolve this issue? AFAIK, headers come
from w32api/mingw32, so extra-patching them makes little sense, besises
they seem to be correct per MS docs, which say that wince has only "W"
functions. I understand that coredll is dllinked by oridinals, so names
are secondary, but maybe libcoredll.a is what actually should provide
"W" symbols?

>
> But this is from memory, I may have forgotten some aspects.
>
> Note that I can provide SVN write access on the cegcc project for
> those who want to do real work on it.

I guess, with the current situation, scope should change from
maintaining a project repo to maintaining a project patch, with the
implication it has (minimize patch size, avoid changing which can be
not changed). And I agree with previous people who spoke on this, git
should be the tool for maintenance.

That said, I already find me diffing build-mingw32ce.sh & build-x86.sh,
expectably finding them to be cases of code duplication and expectably
having random divergences due to this, and trying to patch those
divergences away. So, if I finish and submit patch for that, we can
discuss this further.

But what I'd appreciate is mediawiki write access, so I at least can
collect gnu-wince related links in a public place. My SF username is
'pfalcon'. Thanks.


>
> Danny
>
> On Thu, 2010-12-16 at 06:11 +0200, Paul Sokolovsky wrote:
> > Hello,
> >
> > Well, ok, should have read the list archive a bit more ;-). Pedro
> > Alves' cleanup:
> > http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2839
> >
> > I'd still ask for other parties' patchsets, as that one is year's
> > old, and for gcc only apparently.
> >
> > On Thu, 16 Dec 2010 05:55:23 +0200
> > Paul Sokolovsky <[hidden email]> wrote:
> >
> > > Hello,
> > >
> > > I'd like to ask people who worked on producing a cegcc
> > > patchset/porting cegcc to newer versions of binutils/gcc to share
> > > any results they have, no matter how incomplete or preliminary
> > > they are (I in particular cc: Pavel Pavlov who worked on this at
> > > the summer per his posts to the mailing list). Just seeing size
> > > of patches and curious peek inside can give info/motivation
> > > someone needs to continue the work.
> > >
> > > --
> > > Best regards,
> > >  Paul                          mailto:[hidden email]
> >
> >
> >
>
> --
> Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
>



--
Best regards,
 Paul                          mailto:[hidden email]

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some cegcc issues, was: Re: Producing a cegcc binutils/gcc patchset, after all

Paul Sokolovsky
Hello,

On Thu, 16 Dec 2010 23:48:20 +0200
Paul Sokolovsky <[hidden email]> wrote:

[]
>
http://www.mail-archive.com/cegcc-devel@.../msg03053.html ,

>
> And back to the issue at that link, I worked it around with the
> following patch:
>
> -BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW);
> +BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW);
> -#define Shell_NotifyIcon Shell_NotifyIconW
> +//#define Shell_NotifyIcon Shell_NotifyIconW
>
> But where's correct place to resolve this issue? AFAIK, headers come
> from w32api/mingw32, so extra-patching them makes little sense,
> besises they seem to be correct per MS docs, which say that wince has
> only "W" functions. I understand that coredll is dllinked by
> oridinals, so names are secondary, but maybe libcoredll.a is what
> actually should provide "W" symbols?

Update: turns out that .def files don't have ordinals, so, at least on
the level of implibs, they are not used. I also see how this issue
being handled:

winuser.h:
#ifndef _WIN32_WCE
WINUSERAPI LONG WINAPI ChangeDisplaySettingsA(PDEVMODEA,DWORD);
WINUSERAPI LONG WINAPI ChangeDisplaySettingsW(PDEVMODEW,DWORD);
WINUSERAPI LONG WINAPI ChangeDisplaySettingsExA(LPCSTR,LPDEVMODEA,HWND,DWORD,LPVOID);
WINUSERAPI LONG WINAPI ChangeDisplaySettingsExW(LPCWSTR,LPDEVMODEW,HWND,DWORD,LPVOID);
#else /* _WIN32_WCE */
WINUSERAPI LONG WINAPI ChangeDisplaySettingsEx(LPCWSTR,LPDEVMODEW,HWND,DWORD,LPVOID);
#endif /* _WIN32_WCE */

But that goes out of hand IMHO, as if it's not enough that MS dupped
every string-receiving function, and everyone actually maintains 2 defs
instead of employing some preprocessor to generate them out of common
description. Duplication (triplication?) leads to apparent errors, like:

#ifdef _WIN32_WCE
WINUSERAPI BOOL WINAPI SetProp(HWND,LPCSTR,HANDLE);
#else
WINUSERAPI BOOL WINAPI SetPropA(HWND,LPCSTR,HANDLE);
WINUSERAPI BOOL WINAPI SetPropW(HWND,LPCWSTR,HANDLE);
#endif

Note pointer type in SetProp().


So, this should be handled differently. Quick idea is to use implib
aliasing, like

SetPropW=SetProp

That assumes that coredll.dll indeed exports A/W-less functions.
Seeing's believing, but it's locked on device, google is noisy, and
have no idea where my own rom dumps...

>
> >
> > But this is from memory, I may have forgotten some aspects.
> >
> > Note that I can provide SVN write access on the cegcc project for
> > those who want to do real work on it.
>
> I guess, with the current situation, scope should change from
> maintaining a project repo to maintaining a project patch, with the
> implication it has (minimize patch size, avoid changing which can be
> not changed). And I agree with previous people who spoke on this, git
> should be the tool for maintenance.
>
> That said, I already find me diffing build-mingw32ce.sh &
> build-x86.sh, expectably finding them to be cases of code duplication
> and expectably having random divergences due to this, and trying to
> patch those divergences away. So, if I finish and submit patch for
> that, we can discuss this further.
>
> But what I'd appreciate is mediawiki write access, so I at least can
> collect gnu-wince related links in a public place. My SF username is
> 'pfalcon'. Thanks.
>
>
> >
> > Danny
> >
> > On Thu, 2010-12-16 at 06:11 +0200, Paul Sokolovsky wrote:
> > > Hello,
> > >
> > > Well, ok, should have read the list archive a bit more ;-). Pedro
> > > Alves' cleanup:
> > > http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2839
> > >
> > > I'd still ask for other parties' patchsets, as that one is year's
> > > old, and for gcc only apparently.
> > >
> > > On Thu, 16 Dec 2010 05:55:23 +0200
> > > Paul Sokolovsky <[hidden email]> wrote:
> > >
> > > > Hello,
> > > >
> > > > I'd like to ask people who worked on producing a cegcc
> > > > patchset/porting cegcc to newer versions of binutils/gcc to
> > > > share any results they have, no matter how incomplete or
> > > > preliminary they are (I in particular cc: Pavel Pavlov who
> > > > worked on this at the summer per his posts to the mailing
> > > > list). Just seeing size of patches and curious peek inside can
> > > > give info/motivation someone needs to continue the work.
> > > >
> > > > --
> > > > Best regards,
> > > >  Paul                          mailto:[hidden email]
> > >
> > >
> > >
> >
> > --
> > Danny Backx ; danny.backx - at - scarlet.be ;
> > http://danny.backx.info
> >
>
>
>
> --
> Best regards,
>  Paul                          mailto:[hidden email]
>
> ------------------------------------------------------------------------------
> Lotusphere 2011
> Register now for Lotusphere 2011 and learn how
> to connect the dots, take your collaborative environment
> to the next level, and enter the era of Social Business.
> http://p.sf.net/sfu/lotusphere-d2d
> _______________________________________________
> Cegcc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/cegcc-devel



--
Best regards,
 Paul                          mailto:[hidden email]

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some cegcc issues, was: Re: Producing a cegcc binutils/gcc patchset, after all

Paul Sokolovsky
Hello,

Well, here's situation in utero:

PocketPC2003 SDK defines Shell_NotifyIcon. Yet there's MessageBoxW.
Apparently, for WinCE they decided to add W only for functions which
directly get LPTSTR, not indirectly via structures.

But on WinXP, shell32.dll has all 3 of Shell_NotifyIcon,
Shell_NotifyIconA, Shell_NotifyIconW (and w32api def too, but headers
lack Shell_NotifyIcon).

What a mess! And I'm still not sure how to deal with it. It depends on
the scope of effort. One thing is to run behind the vendor to support
its platform with alternative tools, and another is to maintain platform
they fail to maintain (PocketPC, WindowsMobile).



On Fri, 17 Dec 2010 15:46:55 +0200
Paul Sokolovsky <[hidden email]> wrote:

> Hello,
>
> On Thu, 16 Dec 2010 23:48:20 +0200
> Paul Sokolovsky <[hidden email]> wrote:
>
> []
> >
> http://www.mail-archive.com/cegcc-devel@.../msg03053.html ,
> >
> > And back to the issue at that link, I worked it around with the
> > following patch:
> >
> > -BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW);
> > +BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW);
> > -#define Shell_NotifyIcon Shell_NotifyIconW
> > +//#define Shell_NotifyIcon Shell_NotifyIconW
> >
> > But where's correct place to resolve this issue? AFAIK, headers come
> > from w32api/mingw32, so extra-patching them makes little sense,
> > besises they seem to be correct per MS docs, which say that wince
> > has only "W" functions. I understand that coredll is dllinked by
> > oridinals, so names are secondary, but maybe libcoredll.a is what
> > actually should provide "W" symbols?
>
> Update: turns out that .def files don't have ordinals, so, at least on
> the level of implibs, they are not used. I also see how this issue
> being handled:
>
> winuser.h:
> #ifndef _WIN32_WCE
> WINUSERAPI LONG WINAPI ChangeDisplaySettingsA(PDEVMODEA,DWORD);
> WINUSERAPI LONG WINAPI ChangeDisplaySettingsW(PDEVMODEW,DWORD);
> WINUSERAPI LONG WINAPI
> ChangeDisplaySettingsExA(LPCSTR,LPDEVMODEA,HWND,DWORD,LPVOID);
> WINUSERAPI LONG WINAPI
> ChangeDisplaySettingsExW(LPCWSTR,LPDEVMODEW,HWND,DWORD,LPVOID);
> #else /* _WIN32_WCE */ WINUSERAPI LONG WINAPI
> ChangeDisplaySettingsEx(LPCWSTR,LPDEVMODEW,HWND,DWORD,LPVOID);
> #endif /* _WIN32_WCE */
>
> But that goes out of hand IMHO, as if it's not enough that MS dupped
> every string-receiving function, and everyone actually maintains 2
> defs instead of employing some preprocessor to generate them out of
> common description. Duplication (triplication?) leads to apparent
> errors, like:
>
> #ifdef _WIN32_WCE
> WINUSERAPI BOOL WINAPI SetProp(HWND,LPCSTR,HANDLE);
> #else
> WINUSERAPI BOOL WINAPI SetPropA(HWND,LPCSTR,HANDLE);
> WINUSERAPI BOOL WINAPI SetPropW(HWND,LPCWSTR,HANDLE);
> #endif
>
> Note pointer type in SetProp().
>
>
> So, this should be handled differently. Quick idea is to use implib
> aliasing, like
>
> SetPropW=SetProp
>
> That assumes that coredll.dll indeed exports A/W-less functions.
> Seeing's believing, but it's locked on device, google is noisy, and
> have no idea where my own rom dumps...
>
> >
> > >
> > > But this is from memory, I may have forgotten some aspects.
> > >
> > > Note that I can provide SVN write access on the cegcc project for
> > > those who want to do real work on it.
> >
> > I guess, with the current situation, scope should change from
> > maintaining a project repo to maintaining a project patch, with the
> > implication it has (minimize patch size, avoid changing which can be
> > not changed). And I agree with previous people who spoke on this,
> > git should be the tool for maintenance.
> >
> > That said, I already find me diffing build-mingw32ce.sh &
> > build-x86.sh, expectably finding them to be cases of code
> > duplication and expectably having random divergences due to this,
> > and trying to patch those divergences away. So, if I finish and
> > submit patch for that, we can discuss this further.
> >
> > But what I'd appreciate is mediawiki write access, so I at least can
> > collect gnu-wince related links in a public place. My SF username is
> > 'pfalcon'. Thanks.
> >
> >
> > >
> > > Danny
> > >
> > > On Thu, 2010-12-16 at 06:11 +0200, Paul Sokolovsky wrote:
> > > > Hello,
> > > >
> > > > Well, ok, should have read the list archive a bit more ;-).
> > > > Pedro Alves' cleanup:
> > > > http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2839
> > > >
> > > > I'd still ask for other parties' patchsets, as that one is
> > > > year's old, and for gcc only apparently.
> > > >
> > > > On Thu, 16 Dec 2010 05:55:23 +0200
> > > > Paul Sokolovsky <[hidden email]> wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I'd like to ask people who worked on producing a cegcc
> > > > > patchset/porting cegcc to newer versions of binutils/gcc to
> > > > > share any results they have, no matter how incomplete or
> > > > > preliminary they are (I in particular cc: Pavel Pavlov who
> > > > > worked on this at the summer per his posts to the mailing
> > > > > list). Just seeing size of patches and curious peek inside can
> > > > > give info/motivation someone needs to continue the work.
> > > > >
> > > > > --
> > > > > Best regards,
> > > > >  Paul                          mailto:[hidden email]
> > > >
> > > >
> > > >
> > >
> > > --
> > > Danny Backx ; danny.backx - at - scarlet.be ;
> > > http://danny.backx.info
> > >
> >
> >
> >
> > --
> > Best regards,
> >  Paul                          mailto:[hidden email]
> >
> > ------------------------------------------------------------------------------
> > Lotusphere 2011
> > Register now for Lotusphere 2011 and learn how
> > to connect the dots, take your collaborative environment
> > to the next level, and enter the era of Social Business.
> > http://p.sf.net/sfu/lotusphere-d2d
> > _______________________________________________
> > Cegcc-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/cegcc-devel
>
>
>
> --
> Best regards,
>  Paul                          mailto:[hidden email]



--
Best regards,
 Paul                          mailto:[hidden email]

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some cegcc issues, was: Re: Producing a cegcc binutils/gcc patchset, after all

Paul Sokolovsky
In reply to this post by Paul Sokolovsky
Hello,

On Fri, 17 Dec 2010 15:46:55 +0200
Paul Sokolovsky <[hidden email]> wrote:

[]

> So, this should be handled differently. Quick idea is to use implib
> aliasing, like
>
> SetPropW=SetProp

Well, either I mix up things, or in my times (ca. 10 years ago) that
indeed worked with dlltool for creating implibs from .defs. But it
doesn't now, and it was a hell to find an MS compiler to verify that
behavior. In the process, learned that there's no implib.exe nowadays
(eVC4), but lib.exe does the trick.

Still, binutils people made what I had in mind:
http://sourceware.org/git/?p=binutils.git;a=commit;f=binutils/dlltool.c;h=f762b0771734d0a4c81f3b19302bce8a1853a9d8
http://sourceware.org/git/?p=binutils.git;a=blob;f=binutils/testsuite/binutils-all/alias-2.def;h=ef41eec6c15954b8e252481e4adc9a69b6248c6c;hb=f762b0771734d0a4c81f3b19302bce8a1853a9d8

But well, would need to upgrade binutils to elaborate w32api. Scope
creep. Another issue is that objects produced with such technique would
be unlinkable by MSVC - some people appear to use such scenario.

Another approach to at least minimize w32api patching is:

#ifdef _WIN32_WCE
#define _WNAME(name) name
#else
#define _WNAME(name) name ## W
#endif

BOOL WINAPI Shell_NotifyIconA(DWORD,PNOTIFYICONDATAA);
BOOL WINAPI _WNAME(Shell_NotifyIcon)(DWORD,PNOTIFYICONDATAW);

#define Shell_NotifyIcon _WNAME(Shell_NotifyIcon)


--
Best regards,
 Paul                          mailto:[hidden email]

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some cegcc issues, was: Re: Producing a cegcc binutils/gcc patchset, after all

Danny Backx
In reply to this post by Paul Sokolovsky
On Thu, 2010-12-16 at 23:48 +0200, Paul Sokolovsky wrote:

> And back to the issue at that link, I worked it around with the
> following patch:
>
> -BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW);
> +BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW);
> -#define Shell_NotifyIcon Shell_NotifyIconW
> +//#define Shell_NotifyIcon Shell_NotifyIconW
>
> But where's correct place to resolve this issue? AFAIK, headers come
> from w32api/mingw32, so extra-patching them makes little sense, besises
> they seem to be correct per MS docs, which say that wince has only "W"
> functions. I understand that coredll is dllinked by oridinals, so names
> are secondary, but maybe libcoredll.a is what actually should provide
> "W" symbols?

I'm not going to get involved again, but take this advice from me :
- you'll find that the MS docs are not always correct
- you'll find every version of Windows to be subtly different

Merging with some other development (e.g. w32api) involves introducing a
set of #ifdefs for CE into their sources.

        Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some cegcc issues, was: Re: Producing a cegcc binutils/gcc patchset, after all

Paul Sokolovsky
Hello,

On Sat, 18 Dec 2010 14:29:25 +0100
Danny Backx <[hidden email]> wrote:

> On Thu, 2010-12-16 at 23:48 +0200, Paul Sokolovsky wrote:
> > And back to the issue at that link, I worked it around with the
> > following patch:
> >
> > -BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW);
> > +BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW);
> > -#define Shell_NotifyIcon Shell_NotifyIconW
> > +//#define Shell_NotifyIcon Shell_NotifyIconW
> >
> > But where's correct place to resolve this issue? AFAIK, headers come
> > from w32api/mingw32, so extra-patching them makes little sense,
> > besises they seem to be correct per MS docs, which say that wince
> > has only "W" functions. I understand that coredll is dllinked by
> > oridinals, so names are secondary, but maybe libcoredll.a is what
> > actually should provide "W" symbols?
>
> I'm not going to get involved again, but take this advice from me :
> - you'll find that the MS docs are not always correct
> - you'll find every version of Windows to be subtly different

I bet ;-I

>
> Merging with some other development (e.g. w32api) involves
> introducing a set of #ifdefs for CE into their sources.

Well, #ifdef is 2 lines => bigger patches, harder to eye-ball, higher
chance of conflict on upstream merge. Would you have comments regarding
_WNAME() macro I proposed in the other mail? (I undertstand it's only
part of the story, there're also CE-only funcs, funcs introduced in
newer CE versions, where #ifdefs are unavoidable).

>
> Danny
> --
> Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
>



--
Best regards,
 Paul                          mailto:[hidden email]

------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Some cegcc issues, was: Re: Producing a cegcc binutils/gcc patchset, after all

Danny Backx
On Sat, 2010-12-18 at 17:52 +0200, Paul Sokolovsky wrote:
> Well, #ifdef is 2 lines => bigger patches, harder to eye-ball, higher
> chance of conflict on upstream merge. Would you have comments regarding
> _WNAME() macro I proposed in the other mail? (I undertstand it's only
> part of the story, there're also CE-only funcs, funcs introduced in
> newer CE versions, where #ifdefs are unavoidable).

I forget which ones, but there are exceptions to the implied rule that
CE functions end in a W.

        Danny

--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Cegcc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Loading...