# Build and install i386 ports on amd64 without chroots



## Maccraft123 (Jun 5, 2019)

As I am working on "proper" Wine WoW64 port, without chroot, we have to have 32bit program support.
Chroot isn't acceptable because normal user has to be able to build ports.
Any thoughts on this?
I am thinking of:
-/usr/ports32 tree
-/usr/ports/lib32 tree
-/usr/ports/X/Y for 64bit version and /usr/ports/X/lib32-Y for 64bit version(will make a mess)
-32BIT option in all ports(as a consequence 32bit and 64bit versions of programs can't coexist(bad))
Myself I am a fan of /usr/ports32 because it is the cleanest solution
I am aiming for that feature to be in 12.1-RELEASE


----------



## SirDice (Jun 5, 2019)

Maccraft123 said:


> I am aiming for that feature to be in 12.1-RELEASE


Too soon. Schedule is already finalized. https://www.freebsd.org/releases/12.1R/schedule.html

Point your arrows on -CURRENT, that's where all the new developments happen. The ports tree is the least of the problems. What about /usr/local/lib for example? How's that supposed to be handled? And are you going to mix 32 bit and 64 bit binaries in /usr/local/bin? I suggest you do your suggestions on the mailing lists.


----------



## shkhln (Jun 5, 2019)

Maccraft123 said:


> Wine WoW64 port, without chroot








						⚙ D16830 USES=lib32: add support for lib32- companion ports
					






					reviews.freebsd.org


----------



## Maccraft123 (Jun 5, 2019)

SirDice said:


> Too soon. Schedule is already finalized. https://www.freebsd.org/releases/12.1R/schedule.html


I don't want to target 13-RELEASE because I would like to have it on my system as soon as possible. I'm just impatient.
Only thing keeping me from installing FreeBSD on desktop is just Wine WoW64 and DXVK.


SirDice said:


> What about /usr/local/lib for example? How's that supposed to be handled? And are you going to mix 32 bit and 64 bit binaries in /usr/local/bin?


We can do /usr/local/lib32, /usr/local/bin32
Installer option for lib32 could create these directories, and if ports are enabled, create /usr/ports32.
Prefix lib32 will be used for ports names, but directories would be copy-paste from 32bit ports tree.
CC options will have to be adjusted, -m32, USE_GCC would be broken, LDD_UNSAFE would use `ldd32`.


----------



## SirDice (Jun 5, 2019)

Maccraft123 said:


> I don't want to target 13-RELEASE because I would like to have it on my system as soon as possible. I'm just impatient.


If you want proper support you're going to have to lobby, make suggestions and have discussions with various developers. That takes time.


----------



## Maccraft123 (Jun 5, 2019)

SirDice said:


> If you want proper support you're going to have to lobby, make suggestions and have discussions with various developers. That takes time.


So I should develop it on 13-CURRENT?


----------



## SirDice (Jun 5, 2019)

Talk to the actual developers and port maintainers on the mailing lists. The multi-architecture idea has been floated around before.

And I'm fairly certain a /usr/ports32/ will get shot down. All versions on all architectures use one and the same ports tree. So the multi-architecture installation has to work from that one and only ports tree.


----------



## zirias@ (Jun 5, 2019)

And it's still unsolved, so I appreciate any attempt to suggest a good solution. Although probably, wine is indeed the only relevant usecase.


----------



## Maccraft123 (Jun 5, 2019)

> Talk to the actual developers and port maintainers on the mailing lists. The multi-architecture idea has been floated around before.


Imma just complete it and show you completed thing.


> And it's still unsolved, so I appreciate any attempt to suggest a good solution. Although probably, wine is indeed the only relevant usecase.


Qemu user emulation


----------



## shkhln (Jun 5, 2019)

SirDice said:


> Talk to the actual developers and port maintainers on the mailing lists. The multi-architecture idea has been floated around before.



I actually do not know of any compelling use cases for multiarch, other than installing libraries for cross compilation. Wine works perfectly fine with traditional multilib.


----------



## shkhln (Jun 5, 2019)

Zirias said:


> Although probably, wine is indeed the only relevant usecase.



Wine just needs _some_ maintainer attention. You can bring a complete solution tomorrow and it still won't help the situation.


----------



## Maccraft123 (Jun 5, 2019)

shkhln said:


> I actually do not know of any compelling use cases for multiarch, other than installing libraries for cross compilation. Wine works perfectly fine with traditional multilib.


But WoW64 doesn't compile perfectly fine and current thing is just ugly hack, not fix. I am making proper fix for it. I have to do other stuff, will be before 17:30 UTC


----------



## Maccraft123 (Jun 5, 2019)

shkhln said:


> Wine just needs some maintaner attention. You can bring a complete solution tomorrow and it still won't help the situation.


It will still be ugly hack, not proper fix.


----------



## shkhln (Jun 5, 2019)

Maccraft123 said:


> But WoW64 doesn't compile perfectly fine





Spoiler: builds just fine for me





```
% pkg info | grep lib32
lib32-alsa-lib-1.1.2_2         ALSA compatibility library
lib32-alsa-sndio-0.2           ALSA PCM sndio plugin
lib32-expat-2.2.6_1            XML 1.0 parser written in C
lib32-fontconfig-2.12.6,1      XML-based font configuration API for X Windows
lib32-freetype2-2.9.1          Free and portable TrueType font rendering engine
lib32-gettext-runtime-0.19.8.1_2 GNU gettext runtime libraries and programs
lib32-gmp-6.1.2_1              Free library for arbitrary precision arithmetic
lib32-gnutls-3.6.6             GNU Transport Layer Security library
lib32-jbigkit-2.1_1            Lossless compression for bi-level images such as scanned pages, faxes
lib32-jpeg-turbo-2.0.1         SIMD-accelerated JPEG codec which replaces libjpeg
lib32-lcms2-2.9                Accurate, fast, and small-footprint color management engine
lib32-libGLU-9.0.0_3           OpenGL utility library
lib32-libX11-1.6.7,1           X11 library
lib32-libXau-1.0.8_5           Authentication Protocol library for X11
lib32-libXcomposite-0.4.4_5,1  X Composite extension library
lib32-libXcursor-1.1.15_2      X client-side cursor loading library
lib32-libXdamage-1.1.4_5       X Damage extension library
lib32-libXdmcp-1.1.2_2         X Display Manager Control Protocol library
lib32-libXext-1.3.3_3,1        X11 Extension library
lib32-libXfixes-5.0.3_2        X Fixes extension library
lib32-libXi-1.7.9_2,1          X Input extension library
lib32-libXinerama-1.1.4_2,1    X11 Xinerama library
lib32-libXrandr-1.5.1_2        X Resize and Rotate extension library
lib32-libXrender-0.9.10_2      X Render extension library
lib32-libXxf86vm-1.1.4_3       X Vidmode Extension
lib32-libdrm-2.4.96,1          Userspace interface to kernel Direct Rendering Module services
lib32-libepoll-shim-0.0.20181229 epoll shim implemented using kevent
lib32-libffi-3.2.1_3           Foreign Function Interface
lib32-libidn2-2.0.5_1          Implementation of IDNA2008 internationalized domain names
lib32-libinotify-20180201_1    Kevent based inotify compatible library
lib32-libpciaccess-0.13.5      Generic PCI access library
lib32-libpthread-stubs-0.4     This library provides weak aliases for pthread functions
lib32-libtasn1-4.13_1          ASN.1 structure parser library
lib32-libunistring-0.9.10_1    Unicode string library
lib32-libunwind-20170615       Generic stack unwinding library
lib32-libxcb-1.13.1            The X protocol C-language Binding (XCB) library
lib32-libxml2-2.9.8            XML parser library for GNOME
lib32-libxshmfence-1.2_4       Shared memory 'SyncFence' synchronization primitive
lib32-mesa-libs-18.1.9_4       OpenGL libraries that support GLX and EGL clients
lib32-nettle-3.4.1_1           Low-level cryptographic library
lib32-openal-soft-1.19.1_1     Software implementation of the OpenAL specification
lib32-openssl-1.0.2q,1         SSL and crypto library
lib32-p11-kit-0.23.14          Library for loading and enumerating of PKCS#11 modules
lib32-png-1.6.36               Library for manipulating PNG images
lib32-sndio-1.5.0              Small audio and MIDI framework from the OpenBSD project
lib32-tiff-4.0.10              Tools and library routines for working with TIFF images
lib32-tpm-emulator-0.7.4_2     Trusted Platform Module (TPM) emulator
lib32-trousers-0.3.14_2        Open-source TCG Software Stack
lib32-vulkan-loader-1.1.82.0_3 Driver loader for the Vulkan graphics API
lib32-wayland-1.16.0_1         Wayland composite "server"
lib32-wine-devel-4.9,1         Microsoft Windows compatibility environment
lib32-xorg-macros-1.19.2       X.Org development aclocal macros
lib32-xtrans-1.3.5             Abstract network code for X
```






Maccraft123 said:


> I am making proper fix for it.



You still have to convince someone with commit rights to do something about it. That is the limitation here. Your approach has been attempted before and that work is pretty much in limbo.


----------



## Maccraft123 (Jun 5, 2019)

shkhln said:


> Spoiler: builds just fine for me
> 
> 
> 
> ...


How did you built these packages?


----------



## shkhln (Jun 5, 2019)

Maccraft123 said:


> How did you built these packages?



https://gist.github.com/shkhln/63e2af7893d0e8da43aece13d9906284, which is based on the aforementioned D16830 patch (and also linked in that thread, by the way). Please note, this patch is not at all thoroughly tested and is entirely unsupported.


----------



## Maccraft123 (Jun 6, 2019)

shkhln said:


> https://gist.github.com/shkhln/63e2af7893d0e8da43aece13d9906284, which is based on the aforementioned D16830 patch (and also linked in that thread, by the way). Please note, this patch is not at all thoroughly tested and is entirely unsupported.


Everything is entirely unsupported until it's in base.
The new ports tree can just use this flag by default, it will save some time.
New tree has to be made for compatibility with some automated builders, when it can be hard to modify Makefile before compiling.
With `portmaster` we can try to make flag like --lib32, or envar OVERRIDE_PORTS_TREE.
About this patch, lib32 approach can be applicable also to aarch64 and armv7


----------

