2 Mar
2004
2 Mar
'04
3:29 p.m.
On Tue, 2 Mar 2004, Francois Gouget wrote:
winemaker is pretty broken since it has been patched
to call winegcc. I
suspect it was not tested.
Hey, I can't do everything! :))) I just wanted to get the ball rolling.
We must specify '-lmsvcrt' if using the
msvcrt.
Please don't, it's not needed. If you want to use msvcrt, please
pass the -mno-cygwin switch. if that doesn' work, it's a bug
in winegcc.
There is still work to do:
1. Linking with uuid is broken. I suspect winegcc finds the Unix
/lib/libuuid.so first and links with that instead of with our libuuid.a
library.
That shouldn't happen. Can you please run winegcc with the -v flag,
and send the output my way please?
2. wrc does not find 'windows.h' (yes, some RC
files #include Win32
headers). wrc should know about the location of the headers like winegcc
(since our Makefile don't know anything about where the Wine headers are
anymore).
I've verified the source and it should. Maybe you can produce a
--debug=FF trace?
4. We have lost the autoconf integration.
We should encapsulate our macros so they can conveniently be
used by people in their configure.ac scripts. I think that's
the proper way to get autoconf integration.
5. Nothing works if Wine has not been installed. This
is quite
impractical for Wine developers.
It's true, but there are many reasons you need to install Wine
to be able to use Winelib. I doubt it will change in the near
future.
6. winegcc is not rebuilt if the '--prefix'
changes.
Maybe AJ can fix the Makefile. I think winegcc.o should depend on
the Makefile.
7. Building dlls does not work yet but that was
expected and Dimi is
working on it.
In progress :)
--
Dimi.
2 Mar
2 Mar
7:35 p.m.
New subject: winemaker fixes
"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes:
Nothing gets rebuilt if the prefix changes, you have to do a make
clean.
--
Alexandre Julliard
julliard(a)winehq.org
6. winegcc is
not rebuilt if the '--prefix' changes.
Maybe AJ can fix the Makefile. I think winegcc.o should depend on
the Makefile. 
10:12 p.m.
New subject: winemaker fixes
On Tue, 2 Mar 2004, Dimitrie O. Paun wrote:
At link time too? Ah, ok. I'll submit an updated patch.
I get undefined references to things like IID_IUnknown despite a -luuid
which is why I reported a problem. However I have just realised that
these cases probably all involve building dlls so it's probably not an
issue at this stage.
So don't worry about this one I'll let you know if it persists once we
have dll support.
Here goes:
$ cat foo.rc
#include <windows.h>
$ wrc --debug=255 -fofoo.res foo.rc
FYI: Starting preprocess
Added define ((null), 0) <__FLAT__> to <1>
Added define ((null), 0) <__WIN32__> to <1>
Added define ((null), 0) <RC_INVOKED> to <1>
Added define ((null), 0) <__WRC_PATCH__> to <9>
Added define ((null), 0) <__WRC_MICRO__> to <9>
Added define ((null), 0) <__WRC_MINOR__> to <1>
Added define ((null), 0) <__WRC__> to <1>
Added define ((null), 0) <__DATE__> to <"Mar 02 2004">
Added define ((null), 0) <__TIME__> to <"23:03:31">
Added define ((null), 0) <__FILE__> to <>
Added define ((null), 0) <__LINE__> to <>
Starting parse
Entering state 0
Reducing stack by rule 1 (line 181), -> pp_file
Stack now 0
Entering state 1
Reading a token: --(end of buffer or a NUL)
--accepting rule at line 309 ("#")
--accepting rule at line 314 ("include ")
Next token is token tINCLUDE ()
Shifting token tINCLUDE, Entering state 10
Reading a token: --accepting rule at line 339 ("<")
--accepting rule at line 578 ("windows.h")
--accepting rule at line 579 (">")
Next token is token tIQSTRING ()
Shifting token tIQSTRING, Entering state 43
Reading a token: --(end of buffer or a NUL)
--accepting rule at line 342 ("
")
Next token is token tNL ()
Shifting token tNL, Entering state 88
Reducing stack by rule 4 (line 187), tINCLUDE tIQSTRING tNL -> preprocessor
foo.rc:1:1: Error: Unable to open include file windows.h
I meant that we should be able to generate Makefile.in files that
reference a global Make.rules.in file or something like that.
Setting PATH, LD_LIBRARY_PATH and WINEDLLPATH appropriately was all that
was needed. Not so anymore :-(
Could the prefix value used by winegcc go into config.h? Then I believe
we would not have this problem. Many other projects embed this kind of
information in the binaries. How do they handle it?
--
Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
Linux: Because rebooting is for adding new hardware
On Tue, 2 Mar 2004, Francois Gouget wrote:
[...]
We must
specify '-lmsvcrt' if using the msvcrt.
Please don't, it's not needed. If you want to use msvcrt, please
pass the -mno-cygwin switch. if that doesn' work, it's a bug
in winegcc. There is still
work to do:
1. Linking with uuid is broken. I suspect winegcc finds the Unix
/lib/libuuid.so first and links with that instead of with our libuuid.a
library.
That shouldn't happen. Can you please run winegcc with the -v flag,
and send the output my way please? 2. wrc does
not find 'windows.h' (yes, some RC files #include Win32
headers). wrc should know about the location of the headers like winegcc
(since our Makefile don't know anything about where the Wine headers are
anymore).
I've verified the source and it should. Maybe you can produce a
--debug=FF trace? 4. We have
lost the autoconf integration.
We should encapsulate our macros so they can conveniently be
used by people in their configure.ac scripts. I think that's
the proper way to get autoconf integration. 5. Nothing
works if Wine has not been installed. This is quite
impractical for Wine developers.
It's true, but there are many reasons you need to install Wine
to be able to use Winelib. I doubt it will change in the near
future. 6. winegcc is
not rebuilt if the '--prefix' changes.
Maybe AJ can fix the Makefile. I think winegcc.o should depend on
the Makefile.
7386
days inactive
7386
days old
2 comments
3 participants
participants (3)
-
Alexandre Julliard -
Dimitrie O. Paun -
Francois Gouget