#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)

Discussion

  • diff to CVS version for hacking cross-compilation support

     
    Attachments
  • Milan Cutka
    Milan Cutka
    2005-11-24

    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.