From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH try 5] wine: New package
Date: Thu, 29 Jan 2015 22:46:22 +0100 [thread overview]
Message-ID: <20150129214622.GA4213@free.fr> (raw)
In-Reply-To: <54C2C70E.3020700@dawncrow.de>
Andre, All,
On 2015-01-23 23:11 +0100, Andr? Hentschel spake thusly:
> Adds new package: wine
>
> Wine is a compatibility layer capable of running Windows applications on Linux.
>
> Signed-off-by: Andr? Hentschel <nerv@dawncrow.de>
> ---
> I hope i addressed all the comments in the correct manner
> try 2: Fix issue spotted by baruch
> try 3: Added comments, added hash file, fixed X11 check, depend on internal toolchain, added bison and flex to host dependencies
> try 4: instead of depending on internal toolchains add the expected tuple via --host
> try 5: Added 64-bit check for host-wine and restricted wine build to x86 for now. Also added more comments
>
> package/Config.in | 1 +
> package/wine/Config.in | 23 ++++
> package/wine/wine.hash | 2 +
> package/wine/wine.mk | 278 +++++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 304 insertions(+)
>
> diff --git a/package/Config.in b/package/Config.in
> index 5f6ebc2..db2c75a 100644
> --- a/package/Config.in
> +++ b/package/Config.in
> @@ -1015,6 +1015,7 @@ menu "Miscellaneous"
> source "package/snowball-init/Config.in"
> source "package/sound-theme-borealis/Config.in"
> source "package/sound-theme-freedesktop/Config.in"
> + source "package/wine/Config.in"
This is a minor comment, but I would have expected to see Wine in either
of those sub-menus, instead of "Miscellanous":
- Audio and video applications
- Graphic libraries and applications
I think it would fit nicely alongside X.org.
But this is really, really minor! ;-)
> endmenu
>
> menu "Networking applications"
> diff --git a/package/wine/Config.in b/package/wine/Config.in
> new file mode 100644
> index 0000000..38036d4
> --- /dev/null
> +++ b/package/wine/Config.in
> @@ -0,0 +1,23 @@
> +config BR2_PACKAGE_WINE
> + bool "wine"
> + depends on BR2_INET_IPV6
> + depends on BR2_TOOLCHAIN_HAS_THREADS
> + depends on BR2_TOOLCHAIN_USES_GLIBC
> + # Wine only builds on certain architectures
> + depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
> + # Wine has much CPU specific code and mostly makes sense on x86
> + depends on BR2_i386
Well, x86_64 is not the same as i386 in Buildroot. So this makes Wine
really available only on i386 (the 32-bit variant).
Is that what you really wanted to do?
Otherwise, maybe change to:
depends on BR2_i386 || BR2_x86_64
> + help
> + Wine is a compatibility layer capable of running
> + Windows applications on Linux. Instead of simulating internal
> + Windows logic like a virtual machine or emulator,
> + Wine translates Windows API calls into POSIX calls on-the-fly,
> + eliminating the performance and memory penalties of other methods.
Formatting is a bit off. Try to get lines all about the same width.
> + http://www.winehq.org
> +
> +comment "wine needs a (e)glibc toolchain w/ IPv6, threads"
> + depends on BR2_HOSTARCH = "x86_64" || BR2_HOSTARCH = "x86"
> + depends on BR2_i386
> + depends on !BR2_INET_IPV6 || !BR2_TOOLCHAIN_HAS_THREADS
> + depends on !BR2_TOOLCHAIN_USES_GLIBC
> diff --git a/package/wine/wine.hash b/package/wine/wine.hash
> new file mode 100644
> index 0000000..7ffc45e
> --- /dev/null
> +++ b/package/wine/wine.hash
> @@ -0,0 +1,2 @@
> +# Locally computed
> +sha256 0f46dd29b278a3352206b49680f0ac3bfa107e65cb40cb4af51c137f0ebeb271 wine-1.6.2.tar.bz2
> diff --git a/package/wine/wine.mk b/package/wine/wine.mk
> new file mode 100644
> index 0000000..983c886
> --- /dev/null
> +++ b/package/wine/wine.mk
> @@ -0,0 +1,278 @@
> +################################################################################
> +#
> +# wine
> +#
> +################################################################################
> +
> +WINE_VERSION = 1.6.2
> +WINE_SOURCE = wine-$(WINE_VERSION).tar.bz2
> +WINE_SITE = http://source.winehq.org/git/wine.git/snapshot/
It looks like the official URL is on sourceforge, rather than using a
git snapshot, as seen on: https://www.winehq.org/download
Location Description
sourceforge.net Our official source release site.
source.winehq.org/git For the latest development version.
So:
WINE_SITE = http://downloads.sourceforge.net/project/wine/Source
> +WINE_LICENSE = LGPLv2.1+
> +WINE_LICENSE_FILES = COPYING.LIB
Adding the file LICENSE would be good, too. LICENSE.OLD is not
necessary, though.
> +WINE_INSTALL_TARGET = YES
Unneeded, that's the default.
> +WINE_DEPENDENCIES = host-wine
> +HOST_WINE_DEPENDENCIES = host-bison host-flex
So, you do not need host-bison or host-flex to build the target variant?
After looking at configure.ac, yes you do. So:
WINE_DEPENDENCIES = host-bison host-flex host-wine
should be enough, no need to specify HOST_WINE_DEPENDENCIES, they are
derived from the target dependencies, so will end up with the correct
value.
> +# Wine needs to enable 64-bit build tools on 64-bit host
> +ifeq ($(HOSTARCH),x86_64)
> + HOST_WINE_CONF_OPTS += --enable-win64
> +endif
> +
> +# Wine needs its own directory structure and tools for cross compiling
> +WINE_CONF_OPTS = \
> + --with-wine-tools=../host-wine-$(WINE_VERSION) \
> + --disable-tests \
> + --disable-win64 \
So, I've had a look at what --{en,dis}able-win64 means. From what I
understand, if you --enable-win64, you get a 64-bit-only build,
incapable of running win32 binaries. Conversely, if you --disable-win64,
you get a 32-bit-only build, incapable of running win64 binaries.
Right?
That's a bit unfortunate, since on a 64-bit target, it might well be
legit for a user to want to run win32 *and* win64 binaries. But it is
not possible to ahve Wine build both at the same time. Pity... :-(
> + --without-opengl
> +
> +# Wine needs the host tuple of the external toolchain for cross compiling,
> +# otherwise it calls e.g. non-existing i586-buildroot-linux-gnu-gcc while
> +# actually it should look for e.g. i686-pc-linux-gnu-gcc
> +ifeq ($(BR2_TOOLCHAIN_BUILDROOT),)
We prefer positive logic:
ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
> + WINE_CONF_OPTS += --host=$(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PREFIX))
> +endif
Sorry, I still do not understand what happens here...
I commented those lines, and I observed this:
[...]
checking for i586-buildroot-linux-gnu-gcc... /home/ymorin/dev/buildroot/O/host/usr/bin/i686-pc-linux-gnu-gcc
[...]
checking for i586-buildroot-linux-gnu-ar... /home/ymorin/dev/buildroot/O/host/usr/bin/i686-pc-linux-gnu-ar
checking for i586-buildroot-linux-gnu-ranlib... /home/ymorin/dev/buildroot/O/host/usr/bin/i686-pc-linux-gnu-ranlib
[...]
checking how to run the C preprocessor... /home/ymorin/dev/buildroot/O/host/usr/bin/i686-pc-linux-gnu-cpp
[...]
checking for i586-buildroot-linux-gnu-readelf... /home/ymorin/dev/buildroot/O/host/usr/bin/i686-pc-linux-gnu-readelf
[...]
... which seems pretty much what we would expect.
Oh... Then it fails at build time, because of that fscking wrapper to
gcc. Damn.
Ok, so here it goes:
- wine uses a wrapper around gcc
- at configure time, it uses the value from --host and passes it as-is
to the gcc wrapper
- the gcc wrapper uses that variable to generate the gcc name
and we end up with errors like:
../../../host-wine-1.6.2/tools/winegcc/winegcc -b i586-buildroot-linux-gnu [...]
winebuild: cannot find suitable name lister
Bummer... :-(
But I found an alternative that I like a bit more:
# Wine uses a wrapper around gcc, and uses the value of --host to
# construct the filename of the gcc to call.
# But for external toolchains, we may have a discrepancy between the
# tuple, GNU_TARGET_NAME, that we construct from our internal
# variables, and the gcc prefix for the external toolchain.
# So, we have to iverride whatever the gcc wrapper believes what the
# reall gcc is named, and force the tuple of the external toolchain,
# not the one we compute in GNU_TARGET_NAME.
ifeq ($(BR2_TOOLCHAIN_EXTERNAL),y)
WINE_CONF_OPTS += TARGETFLAGS="-b $(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PREFIX))"
endif
This allows us to keep our stndard --host value, and just overrides the
-b option passed to the gcc wrapper.
Care to test that on your side, please?
[--SNIP--]
Ok, tested with ths defconfig, and the few tweaks I mentioned above.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2015-01-29 21:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 22:11 [Buildroot] [PATCH try 5] wine: New package André Hentschel
2015-01-29 21:46 ` Yann E. MORIN [this message]
2015-01-29 22:52 ` Yann E. MORIN
2015-02-18 21:34 ` André Hentschel
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=20150129214622.GA4213@free.fr \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.