This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: windres: serious bug


On March 21, 2003 05:55 am, Nick Clifton wrote:
> Just to be clear ... Dimitrie, please could you try Ian's patch and
> provide us with feedback as to how well it works.  This would not
> violate copyright restrictions (provided that you do not post any
> code), and since you are actually using this tool, you are the one
> most like likey to be able to verify that the patch is working
> properly.

Well, certainly. To be honest, the situation is a bit more complicated.
I haven't been doing any active work on the Mozilla port, my interest
in the port is as a starting base for a port to Wine. This may sound
odd, but for various reasons (of which just being cool is not least
important), I'd like to compile the Win32 port of Mozilla under Wine in
Linux.

Needless to say, such ports are not trivial, but I set out to make them
a lot simpler, so that we make it practical for people to port their Win32
app to Linux via Winelib. To that end I started created a MinGW-compatible
build environment in Wine. Thus, porting to Wine will become a two step
process: first port to MinGW, then port to Wine. It is easy to see that
this approach is a lot more evolutionary, and the steps are simpler.
Moreover, you have intermediate working code (the mingw port) which is also
very important, not to mention that smaller number of things that change 
from under you in each step (in the mingw port, you only have to deal with
the build tools changing, while the wine port, given that I can provide
mingw-compatible tools in Wine, it's just the OS that changes).

Ideally, if everything works according to the plan, the above process looks
like so:
  A. Port MSVC/BCC app to MinGW
	1. Create GNU Makefiles
	2. Deal with difference between cl/bcc and gcc
	3. Get working versions of the app under MinGW
  B. Port from MinGW to Wine
	1. Copy source code to a Linux box, run dos2unix on it
	2. Change #include directives from
		#include "some\dir\file.h"
	   to
		#include "some/dir/file.h"
	3. Change file/dir name capitalization to match the one on disk
	   
	    NOTE: Changed (2) & (3) are scriptable, and we already
		  have a tool that takes care of them. Most importantly,
		  they are portable between all ports so a common source 
		  code can be maintained. Needless to say, this is 
		  paramount, few people have the resources to maintain 
		  different sources.

	4. Change the Makefile as follows:
		+ ifndef WINE
		  CC = gcc
		  CXX = g++
		  WRC = windres
		+ else
		+ CC = winegcc
		+ CXX = wineg++
		+ WRC = wrc
		+ endif
	    Again this change is portable between ports, so a common build
	    system can be maintained. The winegcc/wineg++ tools already
	    work, but they are not ready. They mainly lack -shared support
	    for generating DLLs, but they already proved useful in porting
	    a number of apps (http://24.103.33.114/wine/Winelib-Apps.html)
	    or toolkits (http://www.dssd.ca/wine/Wine-Fun.html#wxwindows).

This should give people a better idea why I think command line compatibility
between tools is important.

However, to get back to the topic of this message, I was interested in the
Mozilla port to MinGW only as a starting point form my efforts toward a
Winelib port. As such I haven't actually worked on it, so I don't have the
environment handy to test the changes. I've posted the patch to the Mozilla
bug, and hopefully someone will give it a try. If not, I'll test it, but it
will take a little while to get everything up to speed. Another way is to
post a test .rc file that was experiencing the problem before, would that be
useful?

-- 
Dimi.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]