Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On Sat, 3 Nov 2012, David Naylor wrote: # Executive Summary Over the past years I have been maintaining the wine-fbsd64 port (see http://mediafire.com/wine_fbsd64 for more). The port itself effectively does static linking (it bundles all the libraries wine needs) with scripts to bootstrap the environment to easily use wine from FreeBSD/amd64. There is also a script to install the i386 nVidia graphic drivers so that wine has access to nVidia accelerated graphics from FreeBSD/amd64. I would like to propose this port gets included in the port's collection and would like to get feedback, your comments please :-). I would say, go ahead and send-pr the port (without the nVidia parts for now). If nobody else bites within two weeks of you sending it, share the number with me, and I'll give it a try. I am sure that, once in, there will be many aspects we'll get feedback on and further tweaks and improvements, but it seems this is relatively widely used and useful, so let's make it port of the ports collection and jointly take it from there. - Can only be compiled in an i386 environment, but the resulting package is *intended* for amd64 (although works fine in an i386 environment) - If, somehow, there is a recursive calling of wine programs then LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration. - The pkgng ports cannot be installed in an i386 environment as they are labelled for amd64. My primary question at this point, and to this group, is how to actually name such a port? It probably makes sense to focus on wine-devel, initially, but given that it's really the 32-bit version that is intended for the 64-bit OS, how to best reflect that? wine-devel-fbsd64 as per the current name? wine-devel-32on64?...?? Gerald ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On 29 Dec 2012 2:03 AM, Gerald Pfeifer ger...@pfeifer.com wrote: On Sat, 3 Nov 2012, David Naylor wrote: # Executive Summary Over the past years I have been maintaining the wine-fbsd64 port (see http://mediafire.com/wine_fbsd64 for more). The port itself effectively does static linking (it bundles all the libraries wine needs) with scripts to bootstrap the environment to easily use wine from FreeBSD/amd64. There is also a script to install the i386 nVidia graphic drivers so that wine has access to nVidia accelerated graphics from FreeBSD/amd64. I would like to propose this port gets included in the port's collection and would like to get feedback, your comments please :-). I would say, go ahead and send-pr the port (without the nVidia parts for now). If nobody else bites within two weeks of you sending it, share the number with me, and I'll give it a try. I am sure that, once in, there will be many aspects we'll get feedback on and further tweaks and improvements, but it seems this is relatively widely used and useful, so let's make it port of the ports collection and jointly take it from there. Thanks, I shall do when I get back from holidays. Might have a surprise up my sleeve :-) - Can only be compiled in an i386 environment, but the resulting package is *intended* for amd64 (although works fine in an i386 environment) - If, somehow, there is a recursive calling of wine programs then LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration. - The pkgng ports cannot be installed in an i386 environment as they are labelled for amd64. My primary question at this point, and to this group, is how to actually name such a port? It probably makes sense to focus on wine-devel, initially, but given that it's really the 32-bit version that is intended for the 64-bit OS, how to best reflect that? wine-devel-fbsd64 as per the current name? wine-devel-32on64?...?? I think there is precedent for the naming. Consider Linux ports, those ports take the prefix linux- to indicate the architecture so I propose i386-wine-devel to indicate a port that has binaries from the i386 architecture. Regards, ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64): I accidentally sent message a second time
Finger slip, I sent a fairly long message on this subject by a finger error that I saw just one or two seconds later. Sorry! Tom ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
from David Naylor naylor.b.da...@gmail.com:
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each ${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added them to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the environment to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32, lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile, only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The port
itself works flawlessly however there have been some reports about some flaws
in the 32-bit compatibility layer of the kernel (although I cannot remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
It would be nice to have wine-fbsd64 as a port, but that might unfortunately
deprive the user of certain flexibility.
Also, nVidia support should be an option, since users with other graphics
cards might have no use for it.
I would really prefer to build the i386 FreeBSD system as a separate part,
including kernel,
since some users, myself included, might want to run an actual FreeBSD i386,
especially on an older computer. So one could build this FreeBSD i386 on a
USB stick or USB hard drive, and then be able to run wine on an i386 system.
Would wine-fbsd64 be a separate port, or would it be wine built on i386, as
the page http://wiki.freebsd.org/Wine suggests? It would be nice to be able
to run Wine
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
First, I want to thank the Wine developers for a job/life/sanity saving
piece of code.
I need both 32 and 64 versions. It would be nice if the ports had a
wine-32 and wine-64 just to make
life simple for us non-intensive Ports users. Just a comment.
On 11/07/12 01:45, Thomas Mueller wrote:
from David Naylor naylor.b.da...@gmail.com:
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each ${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added them to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the environment to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32, lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile, only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The port
itself works flawlessly however there have been some reports about some flaws
in the 32-bit compatibility layer of the kernel (although I cannot remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
It would be nice to have wine-fbsd64 as a port, but that might unfortunately
deprive the user of certain flexibility.
Also, nVidia support should be an option, since users with other graphics
cards might have no use for it.
I would really prefer to build the i386 FreeBSD system as a separate part,
including kernel,
since some users, myself included, might want to run an actual FreeBSD i386,
especially on an older computer. So one could build this FreeBSD i386 on a
USB stick or
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On 7 November 2012 13:57, Patrick Powell papow...@astart.com wrote:
First, I want to thank the Wine developers for a job/life/sanity saving
piece of code.
I need both 32 and 64 versions. It would be nice if the ports had a
wine-32 and wine-64 just to make
life simple for us non-intensive Ports users. Just a comment.
Ports does have a wine-32 port-- it's called emulators/wine. This
will be an *additional* port for amd64.
Chris
On 11/07/12 01:45, Thomas Mueller wrote:
from David Naylor naylor.b.da...@gmail.com:
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively
does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There
is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection
and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port
needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the
port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each
${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added
them to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and
added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the
environment to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to
itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine
is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32,
lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile,
only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting
package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they
are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The
port
itself works flawlessly however there have been some reports about some
flaws
in the 32-bit compatibility layer of the kernel (although I cannot
remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available
from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
It would be nice to have wine-fbsd64 as a port, but that might
unfortunately
deprive the user of certain flexibility.
Also, nVidia support should be an option, since users with other graphics
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On Saturday, 3 November 2012 22:47:56 Jan Beich wrote: David Naylor naylor.b.da...@gmail.com writes: The post-package-script (run only if WITH_PKGNG is defined): - Amends the package so the arch label to 64bit WITH_PKGNG is checked too early. The port fails to fix arch on 10.0 without the variable being set explicitly in make.conf. http://svn.freebsd.org/changeset/ports/305637 I am aware of the change for FreeBSD 10 however didn't realise the port failed. Thanks, I'll try find a fix (although that code is the ugliest hack of the port). To produce the package on an amd64 system do the following: # (cd /usr/ports/emulators/; patch -p0 /path/to/diff) # make -C /usr/src world DESTDIR=/i386 TARGET=i386 # mount -t devfs devfs /i386/dev # mkdir /i386/usr/ports # mount -t nullfs /usr/ports /i386/usr/ports # chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes This is probably easier to manage when using poudriere e.g. # poudriere jails -c -j 10i386 -v HEAD -a i386 -m allbsd # patch -Efsp0 -i /path/to/diff -d /poudriere/ports/default/ports/emulators # poudriere bulk -j 10i386 emulators/wine-fbsd64 I will add this to the wiki (when it gets created). Thanks signature.asc Description: This is a digitally signed message part.
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On Wednesday, 7 November 2012 11:45:11 Thomas Mueller wrote: from David Naylor naylor.b.da...@gmail.com: Hi List, # Executive Summary Over the past years I have been maintaining the wine-fbsd64 port (see http://mediafire.com/wine_fbsd64 for more). The port itself effectively does static linking (it bundles all the libraries wine needs) with scripts to bootstrap the environment to easily use wine from FreeBSD/amd64. There is also a script to install the i386 nVidia graphic drivers so that wine has access to nVidia accelerated graphics from FreeBSD/amd64. I would like to propose this port gets included in the port's collection and would like to get feedback, your comments please :-). P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the discussion. # Conclusion It is based completely off the main port and uses the hack to, effectively, use static linking (or bundling of libraries). In a sense it is a complete, yet quite stable and encompassing, hack. - David ;-) It would be nice to have wine-fbsd64 as a port, but that might unfortunately deprive the user of certain flexibility. To what flexibility do you refer to? Nothing stops the user from building the port herself and for those who prefer a binary with most options switched on (as is with what I provide) that can still be provided (and possibly in an automated manor via a pkgng repository). Also, nVidia support should be an option, since users with other graphics cards might have no use for it. I think I fail to explain how the nVidia support works: it is a simple script that downloads the corresponding i386 drivers (user land libGL stuff) for the amd64 package. If there is no amd64 package installed it cannot know which i386 version to download, also, when installing it does not download any files, only installing the drivers if the distfile is already available on the system. So, there are three cases (on installation): 1) The user has no amd64 package installed (nothing is done) 2) The user has amd64 package installed but no i386 distfile available (nothing is done) 3) The user has amd64 package installed and i386 distfiles available (user land libGL stuff is extracted and placed in $LOCALBASE/lib32) In case 2, the user is advised to run the script manually to download and install the i386 distfiles. In cases 1, 2 and 3 the user is advised to run the script manually whenever there is a change (or installation) to the amd64 package. I would really prefer to build the i386 FreeBSD system as a separate part, including kernel, since some users, myself included, might want to run an actual FreeBSD i386, especially on an older computer. So one could build this FreeBSD i386 on a USB stick or USB hard drive, and then be able to run wine on an i386 system. I think an easy way to achieve this is to modify the FreeBSD32 compatibility to work similar to the linux compatibility, namely: have a super-imposed shadow file-hierarchy at /compat/i386 (similar to /compat/linux). This way the i386 packages can be installed into /compat/i386 and when called can easily find the correct libraries. Then, create an alias: pkg-i386 = chroot env UNAME_p=i386 UNAME_m=i386 MACHINE=i386 /compat/i386 pkg and with the correct i386 repo specified it is trivial to install i386 programs and with a modified PATH: PATH=$PATH:/compat/i386/usr/local/bin:/compat/i386/usr/local/sbin the programs will integrate seamlessly. However, to my knowledge, there are few ports that are i386 only (such as wine) and maybe it is easier to use a similar hack to the wine-fbsd64 port to cater for the fringe cases??? P.S. I really would like to see FreeBSD be broken into packages and integrated into the ports tree, just my crazy ideas though... Would wine-fbsd64 be a separate port, or would it be wine built on i386, as the page http://wiki.freebsd.org/Wine suggests? It would be nice to be able to run Wine on i386 as well as amd64. The answer is yes to both your questions. It can only be built on i386 but is a separate port. The reason for the separate port is to allow extra stuff to happen so that it can be run on amd64 as well. The package can be run on both i386 and amd64. Regards signature.asc Description: This is a digitally signed message part.
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On Sunday, 4 November 2012 13:31:46 Chris Rees wrote:
I think this is very interesting... but I'm not 100% convinced the
best place for this is in the ports tree. However, it would improve
visibility for it, with a good IGNORE message.
Ideally, FreeBSD should have an automagical method of supporting i386 packages
on an amd64 system. Please see my reply to Thomas Muller for my thoughts on
this topic.
We have a problem however; we can't include bsd.port.pre.mk in a slave
port.
The solution I can think of is;
post-package-script:
if [ ${PKG_BIN:T} = pkg ]; then \
${XZ_CMD} -dc ${PKGFILE} | \
${SED} -e s/^\(arch: freebsd:.*:x86\):32/\1:64/ | \
${XZ_CMD} ${WRKDIR}/${PKGNAME}.txz; \
${MV} ${WRKDIR}/${PKGNAME}.txz ${PKGFILE}; \
fi
Thanks, I've added that to the port and will test it later :-)
Thanks
signature.asc
Description: This is a digitally signed message part.
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
from David Naylor naylor.b.da...@gmail.com:
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each ${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added them to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the environment to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32, lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile, only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The port
itself works flawlessly however there have been some reports about some flaws
in the 32-bit compatibility layer of the kernel (although I cannot remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
It would be nice to have wine-fbsd64 as a port, but that might unfortunately
deprive the user of certain flexibility.
Also, nVidia support should be an option, since users with other graphics
cards might have no use for it.
I would really prefer to build the i386 FreeBSD system as a separate part,
including kernel,
since some users, myself included, might want to run an actual FreeBSD i386,
especially on an older computer. So one could build this FreeBSD i386 on a
USB stick or USB hard drive, and then be able to run wine on an i386 system.
Would wine-fbsd64 be a separate port, or would it be wine built on i386, as
the page http://wiki.freebsd.org/Wine suggests? It would be nice to be able
to run Wine
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On 4 November 2012 11:16, Thomas Mueller muelle...@insightbb.com wrote:
from David Naylor naylor.b.da...@gmail.com:
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each
${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added them
to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the environment to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32, lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile, only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The port
itself works flawlessly however there have been some reports about some flaws
in the 32-bit compatibility layer of the kernel (although I cannot remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
It would be nice to have wine-fbsd64 as a port, but that might unfortunately
deprive the user of certain flexibility.
Also, nVidia support should be an option, since users with other graphics
cards might have no use for it.
I would really prefer to build the i386 FreeBSD system as a separate part,
including kernel,
since some users, myself included, might want to run an actual FreeBSD i386,
especially on an older computer. So one could build this FreeBSD i386 on a
USB stick or USB hard drive, and then be able to run wine on an i386 system.
Would wine-fbsd64 be a separate port, or would it be wine built on i386, as
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
On 11/04/12 21:31, Chris Rees wrote:
On 4 November 2012 11:16, Thomas Mueller muelle...@insightbb.com wrote:
from David Naylor naylor.b.da...@gmail.com:
Hi List,
# Executive Summary
Over the past years I have been maintaining the wine-fbsd64 port (see
http://mediafire.com/wine_fbsd64 for more). The port itself effectively
does
static linking (it bundles all the libraries wine needs) with scripts to
bootstrap the environment to easily use wine from FreeBSD/amd64. There is
also a script to install the i386 nVidia graphic drivers so that wine has
access to nVidia accelerated graphics from FreeBSD/amd64.
I would like to propose this port gets included in the port's collection and
would like to get feedback, your comments please :-).
P.S. I'm not subscribed to the list, so please ensure I'm cc'ed in the
discussion.
# Details of the Port
Please see attached for the actual port.
## Port Preamble
This port is a slave port to emulators/wine(-devel). The master port needed
to be modified (already done):
- to conditionally set USE_LDCONFIG (if USE_LDCONFIG32 was not set)
- to allow the library directory to be changed (see WINELIBDIR)
- to allow configure arguments to be appended
## Port Targets
The port itself does the following in the preamble:
- specifies the pkg(de)install script to handle nVidia driver patching
- overrides ACTUAL-PACKAGE-DEPENDS (all depends are bundled with the port)
- defined the library directory to ${PREFIX}/lib32
- defined the binary directory to ${PREFIX}/bin32
- patches the PLIST to refer to lib32 (not lib)
- defined USE_LDCONFIG32 appropriately
The post-install-script target:
- Installs the files/binbounce file in ${PREFIX}/bin for each
${PREFIX}/bin32
file (hard linked)
- Finds all linked library, copies them to ${PREFIX}/lib32, and added them
to
the plist
- Finds all dlopen'ed libraries, copies them to ${PREFIX}/lib32, and added
them to the plist
- Installs the nVidia patch file
- Run the (PRE-|POST-)INSTALL script
The post-package-script (run only if WITH_PKGNG is defined):
- Amends the package so the arch label to 64bit
## Port scripts (in files/)
The binbounce file does the following to transparently fix the environment
to
allow seamless running of the wine programs:
- determines the location of the TARGET (follows symbolic links to itself)
- fixes LD_LIBRARY_PATH if in an i386 environment (so lib32, lib32/wine is
found)
- fixes LD_32_LIBRARY_PATH if in an amd64 environment (so lib32,
lib32/wine,
/usr/lib32)
- fixes PATH (so bin32 is found)
- passes execution to the counterpart in bin32
The patch-nvidia.sh file does the following:
- Downloads the nVidia distfile for i386 (iff nVidia amd64 driver is
installed)
- Installs the required libraries into ${PREFIX}/lib32
- When run from the install script it does _not_ download the distfile,
only
installs the libraries iff the distfiles are already downloaded.
# Shortcomings of the port
The following are shortcomings that I am aware of:
- Can only be compiled in an i386 environment, but the resulting package is
*intended* for amd64 (although works fine in an i386 environment)
- If, somehow, there is a recursive calling of wine programs then
LD_(32_)LIBRARY_PATH and PATH will continue to grow with every iteration.
- The pkgng ports cannot be installed in an i386 environment as they are
labelled for amd64.
# Testing
The ports published on mediafire have been tested by many users. The port
itself works flawlessly however there have been some reports about some
flaws
in the 32-bit compatibility layer of the kernel (although I cannot remember
the specifics now).
To produce the package on an amd64 system do the following:
# (cd /usr/ports/emulators/; patch -p0 /path/to/diff)
# make -C /usr/src world DESTDIR=/i386 TARGET=i386
# mount -t devfs devfs /i386/dev
# mkdir /i386/usr/ports
# mount -t nullfs /usr/ports /i386/usr/ports
# chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes
The package wine-fbsd64-1.5.16,1.txz (in pkgng format) will be available
from
/usr/ports/packages/All/
# Conclusion
It is based completely off the main port and uses the hack to,
effectively, use static linking (or bundling of libraries). In a
sense it is a complete, yet quite stable and encompassing, hack.
- David ;-)
It would be nice to have wine-fbsd64 as a port, but that might unfortunately
deprive the user of certain flexibility.
Also, nVidia support should be an option, since users with other graphics
cards might have no use for it.
I would really prefer to build the i386 FreeBSD system as a separate part,
including kernel,
since some users, myself included, might want to run an actual FreeBSD i386,
especially on an older computer. So one could build this FreeBSD i386 on a
USB stick or USB hard drive, and then be able to run wine on an i386 system.
Would wine-fbsd64 be a separate port, or would it
Re: wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)
David Naylor naylor.b.da...@gmail.com writes: The post-package-script (run only if WITH_PKGNG is defined): - Amends the package so the arch label to 64bit WITH_PKGNG is checked too early. The port fails to fix arch on 10.0 without the variable being set explicitly in make.conf. http://svn.freebsd.org/changeset/ports/305637 To produce the package on an amd64 system do the following: # (cd /usr/ports/emulators/; patch -p0 /path/to/diff) # make -C /usr/src world DESTDIR=/i386 TARGET=i386 # mount -t devfs devfs /i386/dev # mkdir /i386/usr/ports # mount -t nullfs /usr/ports /i386/usr/ports # chroot make -C /usr/ports/emulators/wine-fbsd64 package WITH_PKGNG=yes This is probably easier to manage when using poudriere e.g. # poudriere jails -c -j 10i386 -v HEAD -a i386 -m allbsd # patch -Efsp0 -i /path/to/diff -d /poudriere/ports/default/ports/emulators # poudriere bulk -j 10i386 emulators/wine-fbsd64 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
