Committer needed: x11/nvidia hybrid graphics and legacy system fixes
x11/nvidia-hybrid-graphics: xorg rc script broken since 88b0ae2bb9c6 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266245 x11/nvidia-xconfig: add compatible version with legacy driver https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266247
Re: lang/llvm15 -- Why is flang being built?
On 1/30/23 13:37, Brooks Davis wrote: On Mon, Jan 30, 2023 at 09:17:07PM +0300, Gleb Popov wrote: On Mon, Jan 30, 2023 at 7:59 PM Steve Kargl wrote: % flang15 -o z a.f90 error: /usr/ports/devel/llvm15/work/llvm-project-15.0.7.src/flang/lib/Optimizer/CodeGen/Target.cpp:312: not yet implemented: target not implemented % flang-new15 -o z a.f90 error: /usr/ports/devel/llvm15/work/llvm-project-15.0.7.src/flang/lib/Optimizer/CodeGen/Target.cpp:312: not yet implemented: target not implemented Inspection of Target.cpp shows that the word "FreeBSD" does not appear anywhere. -- Steve This was fixed shortly after the release, but Flang itself still isn't capable of producing working executables. It should probably be turned off for now. I'll turn it off by default in llvm15 and the upcoming llvm16. -- Brooks with llvm-devel 16.0.d20230109 : % /usr/local/llvm-devel/bin/flang -o orbit orbit.f90 -O3 -Wall -Wextra -Werror -L/usr/local/llvm-devel/lib -lFortran_main -lFortranRuntime -lFortranDecimal -lm produces a working executable for me, with results agreeing within 1ULP with those of the executable compiled by devel/flang (expired). Performance is reasonable (though inferior, but this is only one test). Thus basic executable functionality, and at least one real world program work. I do not see a reason to omit flang from upcoming llvm16. Theron
Getting lib32 porting effort unstuck
WINE requires 32-bit libraries for many programs. The current system
used by the WINE port is to require the user to run a helper script
which uses pkg to fetch and install i386 packages to the home
directory. It is not ideal.
The WINE project's promised WoW64 thunks for 32-bit processes to use
64-bit libs has been in "almost there but not quite" status for years.
The motivation to maintain 32-bit libs for WINE remains.
Several proposals have been made for 32-bit library ports:
- A single i386-libs port uses a chroot to build many libraries from
ports tree which are then installed/packaged as one port. Unacceptable
since a port must not require root to build.
https://reviews.freebsd.org/D14721
- Create i386- slave ports of all required libraries. Filling the ports
tree with ~100 arch-specific additional ports seems unacceptable.
https://github.com/shkhln/freebsd-lib32-companion-ports
- Add -i386 flavor to all required library ports. Clutters ports'
Makefiles and may conflict with existing FLAVORS uses. Not using
FLAVORS as intended. https://reviews.freebsd.org/D16830
- Write a single i386-libs port. Each library is built as a separate
package as a FLAVOR of i386-libs. Unconventional usage of FLAVORS.
All reviews and efforts on this seem to be dead as a result of
uncertainty over whether the implementations are acceptable within the
existing ports framework.
For thoroughness, some of the ideas previously discussed which are
surely unworkable and don't deserve any further consideration:
- Create an amd64-lib32 repository that may be used by pkg alongside
amd64 repository. Completely outside of normal dependency mechanisms
and leaves direct users of ports tree without a simple procedure to
build i386 libs.
- Ports overlay
- Have an i386-libs metaport do evil variable manipulation of port
framework dependency recursion to create i386- variants on the fly.
Maintenance headache and incompatible with poudriere. Procedure for
rebuilding specific ports is non-obvious to the user.
Single i386-libs port with each library built as a FLAVOR seems to be
the least bad option. However any work on it, even a minimal working
review, is a waste of time if this particular usage of FLAVORS is dead
on arrival to portmgr@.
WINE port Makefile example:
LIB_DEPENDS= ...
${LOCALBASE}/lib32/libfontconfig.so:emulators/i386-libs@x11-fonts__fontconfig
emulators/i386-libs/Makefile:
PORTNAME= i386-libs
CATEGORIES= emulators
MASTER_SITES=
DISTFILES=
LIB32_PORTS= \
x11/libXrender \
x11/libX11 \
x11-fonts/fontconfig \
security/gnutls \
print/freetype2 \
graphics/vulkan-loader \
graphics/libGLU \
devel/sdl20 \
graphics/mesa-libs \
(... many more ...)
FLAVORS= meta ${LIB32_PORTS:S,/,__,} # category/portname ->
category__portname
# ${FLAVOR}_*_DEPENDS to be derived from a ${MAKE} -V into referenced port.
# emulators/i386-libs is not a slave port.
Considering the lack of better options and the situation that FLAVORS is
the only currently supported mechanism for a single port to build
several packages, will the slightly unconventional use of FLAVORS be
acceptable provided the port conforms to quality standards in all other
aspects?
