From: Mark Wielaard <mark@klomp.org>
To: Joshua Watt <jpewhacker@gmail.com>
Cc: bzip2-devel@sourceware.org, Phil Ross <phil.ross@gmail.com>
Subject: Re: _stati64 patch (Was: [PATCH] Fix include path separator)
Date: Tue, 01 Jan 2019 00:00:00 -0000 [thread overview]
Message-ID: <dcf76836dc786d15edaa31ecfd9dfa087c96a969.camel@klomp.org> (raw)
In-Reply-To: <ff1fb102-fe22-2bc6-0a4c-7f40a33b35b7@gmail.com>
Hi Joshua,
On Mon, 2019-07-15 at 08:58 -0500, Joshua Watt wrote:
> On 7/14/19 4:23 PM, Mark Wielaard wrote:
> >
> > That is really awesome. Thanks so much for testing that out.
> > Can a cross build bzip2 using MinGw (and msys) be run under Wine?
> > That might give us a build CI pipeline for testing bzip2 using the
> > buildbot. It might not be identical to running under actual Windows.
> > But it might be scripted/automated.
>
> We do something similar to that to test our MinGW SDKs for the Yocto
> Project. We cross compile the SDK using the MinGW toolchain on Linux
> (note that MSYS is not required; the Linux system already has all the
> POSIX tools), then run a set of automated tests under Wine.
OK nice. So for testing you can just use the normal scripts/tools, just
make sure the binary itself is ran through wine?
> You might be able to take this approach also. It wouldn't verify that
> you can actually compile under Windows (as stated, it is a cross compile
> from Linux), but it would give some amount of confidence that you can
> actually run the cross compiled bzip2 on Windows and it will pass the
> tests. You are correct that Wine isn't a fully faithful reproduction of
> Windows; I've found a few things that just refuse to run properly under
> wine, but do fine on actual Windows.
Right. We only want to test that it builds as if for Windows. That is
test the code with BZ_UNIX 0 and BZ_LCCWIN32 1 compiles correctly.
> Most distros have a ready-made MinGW GCC compiler that can be installed.
> The harder part is getting any additional dependencies. Most of the
> distros I've seen don't have very many of the MinGW cross compiled
> library (why would they?) so if your trying to cross compile a large
> codebase, you can easily get into trouble with missing dependencies. The
> Yocto project has an advantage in this regard because we are already
> compiling everything from source anyway, so cross compiling the
> requisite dependencies for MinGW isn't any additional work. I think that
> bzip2 might also be able to be cross compiled easily because it doesn't
> have very many dependencies.
As far as I know bzip2 really shouldn't have any dependencies except
for what is provided by MinGW GCC itself.
> If you want to verify that you can compile under Windows, you might be
> able to install MSVC in wine and use it to build bzip2. You *might* also
> be able to install the Windows version of MinGW and MSYS in wine. I
> don't know how stable this would be or if it would work at all.
Both may go a bit too far. Just being able to (cross) compile to a
Windows binary and then check it works as expected seems all that is
really necessary to make sure we don't break thing (too much).
Lets see... So I installed mingw32-gcc and wine for my distro.
$ make CC=i686-w64-mingw32-gcc
[... mostly seems to work ...]
i686-w64-mingw32-gcc -Wall -Winline -O2 -g -D_FILE_OFFSET_BITS=64 -o
bzip2 bzip2.o -L. -lbz2
./libbz2.a: error adding symbols: Archive has no index; run ranlib to
add one
collect2: error: ld returned 1 exit status
make: *** [bzip2] Error 1
OK, that is odd, but lets do what it says:
$ i686-w64-mingw32-ranlib ./libbz2.a
$ i686-w64-mingw32-gcc -Wall -Winline -O2 -g -D_FILE_OFFSET_BITS=64 \
-o bzip2 bzip2.o -L. -lbz2
$ file bzip2
./bzip2: PE32 executable (console) Intel 80386, for MS Windows
Nice!
But...
$ wine ./bzip2
wine: Bad EXE format for Z:\home\mark\src\bzip2-work\bzip2..
OK, apparently I needed mingw64-gcc.
So, same as above with make CC=i686-w64-mingw32-gcc
x86_64-w64-mingw32-ranlib ./libbz2.a and
x86_64-w64-mingw32-gcc -Wall -Winline -O2 -g -D_FILE_OFFSET_BITS=64 -o
bzip2 bzip2.o -L. -lbz2
$ file bzip2
bzip2: PE32+ executable (console) x86-64, for MS Windows
$ wine ./bzip2 --help
bzip2, a block-sorting file compressor. Version 1.0.8, 13-Jul-2019.
usage: bzip2 [flags and input files in any order]
-h --help print this message
-d --decompress force decompression
-z --compress force compression
-k --keep keep (don't delete) input files
-f --force overwrite existing output files
-t --test test compressed file integrity
-c --stdout output to standard out
-q --quiet suppress noncritical error messages
-v --verbose be verbose (a 2nd -v gives more)
-L --license display software version & license
-V --version display software version & license
-s --small use less memory (at most 2500k)
-1 .. -9 set block size to 100k .. 900k
--fast alias for -1
--best alias for -9
If invoked as `bzip2', default action is to compress.
as `bunzip2', default action is to decompress.
as `bzcat', default action is to decompress to stdout.
If no file names are given, bzip2 compresses or decompresses
from standard input to standard output. You can combine
short flags, so `-v -4' means the same as -v4 or -4v, &c.
That is so awesome! Even though I am not exactly sure what I did.
But it seems possible with some tweaks to get this working.
Could you share some hints and tips on your setup? Or simply explain
what went wrong in the above or what accidentally worked and why?
Also is there a "command line wine"?
The first time you run wine it seems to spawn all kinds of windows
setup thingies. That would work on the buildbots of course.
Thanks,
Mark
next prev parent reply other threads:[~2019-07-15 22:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-01 0:00 [PATCH] Fix include path separator Joshua Watt
2019-01-01 0:00 ` Mark Wielaard
[not found] ` <CAJdd5GZfTk8EKeUE_C1keKm+gn=qapv9OQGGariiiXP9jyu0wQ@mail.gmail.com>
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` _stati64 patch (Was: [PATCH] Fix include path separator) Mark Wielaard
2019-01-01 0:00 ` Joshua Watt
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Joshua Watt
2019-01-01 0:00 ` Mark Wielaard
2019-01-01 0:00 ` Joshua Watt
2019-01-01 0:00 ` Mark Wielaard [this message]
2019-01-01 0:00 ` Joshua Watt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dcf76836dc786d15edaa31ecfd9dfa087c96a969.camel@klomp.org \
--to=mark@klomp.org \
--cc=bzip2-devel@sourceware.org \
--cc=jpewhacker@gmail.com \
--cc=phil.ross@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).