wine/i386 for FreeBSD/amd64 port (aka wine-fbsd64)

Da Rock freebsd-ports at herveybayaustralia.com.au
Sun Nov 4 14:11:12 UTC 2012


On 11/04/12 21:31, Chris Rees wrote:
> On 4 November 2012 11:16, Thomas Mueller <mueller23 at insightbb.com> wrote:
>> from David Naylor <naylor.b.david at 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 on i386 as well as amd64.
> It would be a separate port, as he has explained :)
>
> 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.
>
> 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
I could be way off here, but is it possible to have an i386 port like
the linux stuff? Might solve a few issues with this... and then the wine
port could be built to use it. It is what I'm currently using anyway.



More information about the freebsd-ports mailing list