Issues building the spec.o on win32 with mingw

[Steven Edwards]

I get this on almost every *.spec.o

Administrator@LAPTOP /cygdrive/d/src/winehq/wine/dlls/commdlg
$ make
PATH="../../unicode:$PATH" ../../tools/wrc/wrc  -I. -I. -I../../include
-I../../
include  -o rsrc.res -r rsrc.rc
PATH="../../unicode:$PATH" ../../tools/winebuild/winebuild  -L../../dlls
-o comm
dlg.spec.c -spec commdlg.spec
gcc -mno-cygwin -c -I. -I. -I../../include -I../../include  -D__MINGW__
-D_WINDO
WS -DWINE_NOWINSOCK -Wall -mpreferred-stack-boundary=2 -D__WINE__
-D_REENTRANT
 -o commdlg.spec.o commdlg.spec.c
/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccU3cEQ7.s: Assembler
messages:
/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccU3cEQ7.s:1104: Warning:
unknown se
ction attribute 'a'
/cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccU3cEQ7.s:1106: Error:
unknown pseu
do-op: `.previous'
make: *** [commdlg.spec.o] Error 1

Any ideas? I really don't need the spec because I can do a -l if I can
build the .a for ntdll and a few others. I can use dlltool with the
*.defs and then I only need winebuild to make the *.defs. Only problem
is winebuild wants so's not dll's when building a def or looking for
imports. I was going to have a look at the loader/winedump code for
ideas but I thought I would ask here first.

Thanks
Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson

[Dmitry Timoshkov]

"Steven Edwards"  wrote:

[skipped]
> /cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccU3cEQ7.s:1104: Warning:
> unknown se
> ction attribute 'a'
> /cygdrive/c/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ccU3cEQ7.s:1106: Error:
> unknown pseu
> do-op: `.previous'
> make: *** [commdlg.spec.o] Error 1

That's the problem with binutils/gas which doesn't support for some reason
the .previous statement for the PE target. There are at least two possibilities
to resolve it: 1) implement required support in binutils/gas, 2) rearrange code
produced by winebuild to not require .previous statement at all.

[Dimitrie O. Paun]

On May 1, 2002 01:12 am, Dmitry Timoshkov wrote:
> That's the problem with binutils/gas which doesn't support for some reason
> the .previous statement for the PE target. There are at least two
> possibilities to resolve it: 1) implement required support in binutils/gas,
> 2) rearrange code produced by winebuild to not require .previous statement
> at all.

Well, they clearly say that .previous is ELF specific. Don't know why,
but it is... However, do we really need it? I couldn't spot any place
were we don't know the section we want to go to...

[Steven Edwards]

I'm sending this to all of you because I'm a little behind on my mail
and these two issues go hand in hand
Winebuild && wrc.
> Well, they clearly say that .previous is ELF specific. Don't
> know why, but it is... However, do we really need it? I 
> couldn't spot any place were we don't know the section we 
> want to go to...

.previous can be fixed easy it seems. Will the dlls be relocateable if I
can use the spec and winebuild?
> That's the right way yes, you shouldn't have to build the
> .spec.c files at all. I guess the import information could be 
> moved back into the makefiles (where it actually used to be 
> before dll separation).

The current system works well for you guys and I don't want to have To
make any major changes to the build system if I can avoid it. The issue
I forgot to take in to account was the wrc compiled resources. If I try
to build the spec when a rsrc.res is present I get this

PATH="../../unicode:$PATH" ../../tools/winebuild/winebuild  -L../../dlls
-sym pr ogman.tmp.o -o progman.spec.c -spec ./progman.spec
./progman.spec:5: Cannot read rsrc.res

The specs I tested before didn't have any resources with them so I
didn't notice this. Is there anyway I can debug winebuild to see what is
really going on here?

I have a few ideas for fixing these issues but they wouldn't really help
the MS_VC port. I could always patch windress to be able to compile wrc
resources and then change the build process to use winebuild to only
build the *.def and let dlltool/wrap do the linking but as I stated
before I don't want to change the build system to much and this wouldn't
really help the MS_VC port.

Thanks
Steven

"Every revolution was once a thought in one man's mind"
- Ralph Waldo Emerson

[Alexandre Julliard]

"Steven Edwards"  writes:
> .previous can be fixed easy it seems. Will the dlls be relocateable if I
> can use the spec and winebuild?

You really can't use the .spec.c file. The result won't be a proper PE
dll, and you would need the Wine loader to patch things up at run-time
to make it look like a real dll. It's much easier to build a true PE
dll in the first place.
> The current system works well for you guys and I don't want to have To
> make any major changes to the build system if I can avoid it.

Don't be afraid of suggesting changes. There are many things in the
build system that could be done differently without impacting the Unix
side at all, and making Wine more portable is always a good thing.
> PATH="../../unicode:$PATH" ../../tools/winebuild/winebuild  -L../../dlls
> -sym pr ogman.tmp.o -o progman.spec.c -spec ./progman.spec
> ./progman.spec:5: Cannot read rsrc.res
>
> The specs I tested before didn't have any resources with them so I
> didn't notice this. Is there anyway I can debug winebuild to see what is
> really going on here?

This message comes from load_res32_file() in tools/winebuild/res32.c.
Looks like the read() failed to read the whole file.

[Steven Edwards]

> You really can't use the .spec.c file. The result
> won't be a proper PE
> dll, and you would need the Wine loader to patch
> things up at run-time
> to make it look like a real dll. It's much easier to
> build a true PE
> dll in the first place.

Ok cool, once I send the last of my current patches in
I will move on to building the dlls/programs.
> Don't be afraid of suggesting changes. There are
> many things in the
> build system that could be done differently without
> impacting the Unix
> side at all, and making Wine more portable is always
> a good thing.

Ok, I just try not to make suggestions/comments where
I have no place. My programming skill is low so I am
being reserved about my suggestions if I cant
implement them.
> This message comes from load_res32_file() in
> tools/winebuild/res32.c.
> Looks like the read() failed to read the whole file.

Cool, I will take a look at it.

Thanks
Steven

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

[Alexandre Julliard]

"Steven Edwards"  writes:
> Any ideas? I really don't need the spec because I can do a -l if I can
> build the .a for ntdll and a few others. I can use dlltool with the
> *.defs and then I only need winebuild to make the *.defs. Only problem
> is winebuild wants so's not dll's when building a def or looking for
> imports. I was going to have a look at the loader/winedump code for
> ideas but I thought I would ask here first.

Why does it need to look for imports when building the .def file?
I thought I had fixed that.

[Steven Edwards]

Sorry about that. I meant to say that it still looks
for *.so imports when building the DLL like the way it
used to look for its imports for a *.so when building
a *.def. Not that it still does when building a *.def

If I try to build the dll under mingw when it gets the
spec it will bitch about not being able to open *.so
for import. Winebuild still builds the dllname.spec.c
anyway but if I run it again then I get the asm error.

Sorry I wasnt to clear about all of that. So what is
going to be the best way to go from here? I can build
the *.defs along with 90% of the source and then make
a dirty hack with dlltool/wrap that cuts winebuild
out. The only big problem I see is that the spec
contains the import information that has to be passed
to dlltool/wrap.

I also still dont know if mingw/cygwin can link wrc
compiled resources.

--- Alexandre Julliard  wrote:
> "Steven Edwards"  writes:
> > Any ideas? I really don't need the spec because I
>
> can do a -l if I can
> > build the .a for ntdll and a few others. I can use
>
> dlltool with the
> > *.defs and then I only need winebuild to make the
>
> *.defs. Only problem
> > is winebuild wants so's not dll's when building a
>
> def or looking for
> > imports. I was going to have a look at the
>
> loader/winedump code for
> > ideas but I thought I would ask here first.
>
> Why does it need to look for imports when building
> the .def file?
> I thought I had fixed that.
>
> -- 
> Alexandre Julliard
> [e-mail]

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

[Alexandre Julliard]

Steven Edwards  writes:
> Sorry I wasnt to clear about all of that. So what is
> going to be the best way to go from here? I can build
> the *.defs along with 90% of the source and then make
> a dirty hack with dlltool/wrap that cuts winebuild
> out. The only big problem I see is that the spec
> contains the import information that has to be passed
> to dlltool/wrap.

That's the right way yes, you shouldn't have to build the .spec.c
files at all. I guess the import information could be moved back into
the makefiles (where it actually used to be before dll separation).