Menu
▾
▴
#8 Cross-compilation from Linux fixes
open
nobody
None
5
2005-11-24
2005-11-24
Anonymous
No
Various problems with prefix for binutils/gcc binaries.
Case-sensitiveness on some headers. Mostly hacks though.
-Os makes ffdshow's subtile compilation troublesome.
verinc.exe and rebase.exe use too much Win32 API, and
they have to be run during build process: no good when
cross-compiling from Linux. I've replaced verinc by a
sed script (I'll let you enjoy it) but rebase
functionnality can't be reproduced.
The binaries can be packaged with a Linux version of
makensis. The installer works under Windows, and
ffdshow seems to work.
Tested under Debian unstable:
- mingw32 gcc 3.4.4 is packaged but I used my own 4.0.2
version
- makensis 2.06
- mingw-runtime 3.8 and w32-api 3.5 with patched
streams.h (tagVMR)
- whatever binutils is current (probably 2.16.90)
diff to CVS version for hacking cross-compilation support
Logged In: YES
user_id=547197
Thank you for the patch. I started to apply the changes,
here are few comments:
I fixed -Os compilation of subtitles by forcing inlining of
Tdll::loadFunction. However, more than a fix this was a
workaround, because I think it was caused by a GCC bug.
Why did you removed -Os flag from ff_libfaad2 makefile? Did
it caused some problems?
Sed 3.02 which is installed in my copy on msys tools doesn't
support -i switch, but this wouldn't be necessary anyway.
What's wrong with the line "CC:=$(FFDSHOW_PREFIX)$(CC)"? I'm
asking only because it wasn't put it makefiles by me anyway
and I don't want to break something which might be used by
someone already.
nasm and nasmw could be perhaps solved by variable like
$(NASM).
Logged In: NO
> I fixed -Os compilation of subtitles by forcing inlining
> of Tdll::loadFunction. However, more than a fix this was
> a workaround, because I think it was caused by a GCC bug.
Nice of you to fix this while I didn't specify it. Are you
testing under some Linux system or do you check the
behaviour under win32 mingw ?
> Why did you removed -Os flag from ff_libfaad2 makefile?
> Did it caused some problems?
Sorry, none at all. It is just that I had other changes here
and there for testing, and I overlooked this change when
editing the diff.
I was mostly checking what was the output command-line, and
checking discrepancies if any. On another hand, why
overriding the optimization flag? Now that you mention that
difference, maybe a comment would be good.
> Sed 3.02 which is installed in my copy on msys tools
> doesn't support -i switch, but this wouldn't be necessary
> anyway.
4.1.2 already dates back to 2003, so this is probably pretty
old (makes me think of win32 mingw/msys). But a simple fix
is to use a temporary file:
sed -e "..." version.ver > tmp.ver && mv tmp.ver version.ver
> What's wrong with the line
> "CC:=$(FFDSHOW_PREFIX)$(CC)"?
> I'm asking only because it wasn't put it makefiles by me
> anyway and I don't want to break something which might be
> used by someone already.
This is the hackish part I mentionned.
When compiling, I had instances of
i686mingw32-i686mingw32-gcc called for instance. I'm not
sure why this happens. This solution is unsatisfactory,
mainly, in my opinion, in the case where the native compiler
has to be used. For instance, if verinc is modified to run
and compile under Linux, some care has to be taken so that
it uses a different target.
Here, FFDSHOW_PREFIX is an environment variable in my case,
because it seems that include is made in the start folder.
So, if Makefile includes ../makefile.inc and makefile.inc
includes linux.inc, it is linux.inc that is included and not
../linux.inc
There is probably a fix or a problem somewhere, but I didn't
dig enough.
> Then comes the use of nasm and nasmw could be perhaps
> solved by variable like $(NASM)
Yes, in both makefile_c.inc and makefile.inc then. Actually
checking for a cross-compilation (isn't this the reason for
FFDSHOW_PREFIX?) is cleaner and might automate the process.
Logged In: NO
In the latest CVS revision, you set NASM at the start of the
file, certainly for proper edition. I still suggest
something of this form instead:
ifeq ($(FFDSHOW_PREFIX),)
NASM=nasmw.exe
else
NASM=nasm
endif
Secondly, no need for $(FFDSHOW_PREFIX)$(NASM). With -f
win32, nasm already knows it has to build a proper win32 object.
Thirdly, I'm not sure the --target is in fact required, as
it is not needed for a native compiler and probably
automatical for a cross-compiler. In any case, it is too
dependant on the actual compiler. So a requirement of this
shape would be better:
$(FFDSHOW_PREFIX:%-:--target=%)
Not tested, because I have compilation problems at the
moment. If it doesn't work, this may work:
$(patsubst %-,--target=%,$(FFDSHOW_PREFIX))
Logged In: NO
Nevermind, I just noticed that this flag is for dllwrap, so
it really is important that the --target is specified to
i386-mingw32. In addition, I changed that to i686-mingw32
because I had wrongly compiled that way my cross compiler.
But this should be fixed, because most compilers will be i386.
This makes me think of the rebase problem for cross
compilation. I couldn't get to compile cygwin's rebase tool
that reimplements the RebaseImage API and didn't want to try
too long either.
I don't know what's the relation between image size and what
the command 'size' outputs. Exploiting it is even more complex.