Solved Minimal xorg-minimal

I am trying to build x11/xorg-minimal and it is taking up too much disk space. ~ 3.7GB

Part of the problem is LLVM. It is a dependency of graphics/mesa-dri and it brings in llbd and llvm and clang && python && perl and all kind of things a mesa library should not need.
I am sure there is some core component of llvm that mesa-dri requires.

How can I build a lighter weight llvm? I see a flavor llvm-lite and that sounds promising. Can anybody comment on best use case for it?

I really only want x-forwarding from the remote x-server running off MFS. Do I even need mesa-dri for that?? Headless xorg?

To hack in the "lite" LLVM version I would have to modify the port mesa-dri Makefile and USES ?? Anybody try this?
 
Can anybody help me understand how the flavors of xorg-server are used? xorg flavor being the default.
  • xorg: xorg-server
  • xnest: xorg-nestserver
  • xephyr: xephyr
  • xvfb: xorg-vfbserver
Anybody using Xephyr or xvfb setups?
 
mesa-dri depend on:
  • graphics/spirv-tools
  • devel/spirv-llvm-translator
The default xorg-server is xorg

To get all dependencies of a port run make all-depends-list. Or if the port is already installed pkg info -r package (if you add the option -o the output is more verbose).
To get all flavors of a port and the default flavor run make -V FLAVORS -V FLAVOR. This is true for all of ports with flavor except for drivers like graphics/gpu-firmware-*-kmod, they have a default flavor but all flavors will be built. Packages and components of some languages (Python and some others I do not remember now) the flavors depends on language version installed.

The description of all xorg-server flavor is:
Code:
x11-servers
    xorg-server 21.1.20,1 [xorg-server 21.1.20,1] installed automatic
        X.Org X server and related programs
        xorg 21.1.20,1 [xorg-server 21.1.20,1] installed automatic
            X.Org X server and related programs
            Description     : This package contains Xvfb, a virtual framebuffer X server.
                             
                              See also: https://www.x.org/
        xnest 21.1.20,2 [xorg-nestserver 21.1.20,2]
            X.Org X server and related programs
            Description     : This package contains Xnest, a nesting X Server that displays on an X Server.
        xephyr 21.1.20,1 [xephyr 21.1.20,1]
            X.Org X server and related programs
            Description     : Xephyr is a kdrive server that outputs to a window on a pre-existing
                              'host' X display. Think Xnest but with support for modern extensions
                              like composite, damage and randr.
        xvfb 21.1.20,1 [xorg-vfbserver 21.1.20,1]
            X.Org X server and related programs
            Description     : This package contains Xvfb, a virtual framebuffer X server.
                             
                              See also: https://www.x.org/
 
Thanks for your help.
I was trying to put together something like TinyCore where they have a FLTK desktop in 30MB. I would take 1.25GB xorg-minimal but thats not going to happen...

I am going to mark this solved. Any further comments are welcome.
 
Wayland Protocols. Yes in Xorg Minimal....

I was trying for a 2GB Poudriere Image with 600MB base and rest for my x11 packages..

I tried calming LLVM in base without using a /poudriere.d/src.conf and keep base pure and just strip files.
excluded.files
Code:
usr/src
usr/lib/debug
usr/lib32
usr/tests
nxb-bin
usr/bin/cc
usr/bin/lldb-server
usr/bin/ld.lld
usr/bin/c++
usr/bin/lldb
usr/bin/llvm-objdump
usr/bin/llvm-nm
usr/bin/llvm-ar
usr/lib/clang/*
usr/lib/dtrace/*
usr/share/*
#usr/local/share/* keep termcap in /misc
rescue/*
usr/local/lib/python3.11/*

I may have went to deep. This is for my GPSD build. nox11 Appliance Build. PYSERIAL=OFF
 
Sorry to have switched topics. I started with a small appliance concept and was working on something bigger. Too big it appears.

Even though I set GPSD port options to PYSERIAL=OFF the port still has a dependency with USES=PYTHON even though the port only needs PYTHON to build. Not runs.
I have yet to figure out how to solve that. Maybe add another FLAVOR. Just for that one port option. That seems excessive.
gpsd@lite
211MB for an un-needed python on a nicely written C codebase.
Maybe this should just be my personal patch. I dunno.
 
Its very ricy but since the FreeBSD port of Xorg has gained cruft over the years, untill it gets cleaned up I tend to use a script similar to the one I posted here. It at least localises the mess into /opt/X11R7

Its very ricy, but now I go a little further and use ldd (and objdump) to pull in just the needed libs, i.e llvm (rather than all the extra junk the libs recursively pull in).

Not ideal but Xorg isn't complex, its just badly packaged upstream these days. But I am optimistic that Xlibre and the porters might help shift some of the clutter in the near future.
 
Thank You kpedersen for replying. I did not want to bug you; but you do know the skinny.

Just an idea from a non programmable person. Static compile the whole mess.
Wouldn't that just pluck out the needed libraries and make one big ball of yarn?
Is that not valid approach? For embedded non-upgradable setup for running FLTK apps.

I have yet to try applying simple make.conf stripping on xorg-minimal & friends.
It seems pointless to delete examples and info when the 8K pound elephant in the room is.......5 compilers and wayland ect. ect..
 
Not ideal but Xorg isn't complex, its just badly packaged these days.
Indeed or fratricide. I never heard of a competitor hosting their supposed replacement.

Lets say I follow the crowd. Wayland and labwc.
Would it fit on 2GB image.....
 
Check the first build dependency. graphics/mesa-dri
That drags in the entire LLVM which depends on Python & Perl.

I know BUILD dependency is not needed for runtime but its still there....
kpedersen mentioned glx and I didn't even scope that one. There is alot to consider.
So much so I give up. microSD for OS is stupid. xorg-minimal ridiculous.

While kpedersen's approach of separating X11 is admirable I thought about just placing the files needed to run Xorg in an overlay. Not installing.
Trying to figure out every file actually needed. That is not going to work..
 
What I really was aiming for is an X-Forwarding Server with xorg-minimal.

No rendering driver should be needed for headless Xorg. With X-Forwarding all the rendering is done on client side. Right?
Reading about Xephyr was interesting. X on X is a concept I had not heard of.
 
Hmm, with the following:

X-forwarding server <------> Laptop

The X-forwarding server needs i.e xauth, xcalc, libX11 and very little else. Then from your laptop (running a proper X11 display, you can use:

$ ssh -X xforwardserver xcalc

So you don't need any window manager on your X-forwarding server itself.
 
OK I decided to drill down on my xorg-minimal image. It is the only package installed.

I created a 4.7GB image and flashed it to a 8GB SATADOM.
The installation only takes ~3.1GB and 1.7GB of that is LLVM

Code:
@mbm:/usr/local # df -h
Filesystem            Size    Used   Avail Capacity  Mounted on
/dev/ufs/mbm-usb-x    4.6G    3.1G    1.1G    74%    /
devfs                 1.0K      0B    1.0K     0%    /dev
Code:
@mbm:/usr/local # du -sh * | sort -h | tail -n10
140K    etc
516K    libdata
3.6M    libexec
 19M    include
 23M    bin
 37M    sbin
252M    share
448M    lib
1.7G    llvm19

Of that all software all I need is this I think:
libLLVM.so.19.1
Code:
@mbm:/usr/local/llvm19/lib # du -sh * | sort -h | tail -n10
 19M    libLLVMAMDGPUCodeGen.a
 24M    libMLIRSPIRVDialect.a
 24M    libclangAST.a
 25M    libMLIRTestDialect.a
 34M    libclangSema.a
 36M    libclang.so.19.1.7
 58M    clang
 64M    libMLIR.so.19.1
 67M    libclang-cpp.so.19.1
118M    libLLVM.so.19.1

So I am going to try and exclude everything but the dependency needed for graphics/mesa-dri. See what that does. I might have to allow the spirv stuff too.

If I can cut alot of LLVM this becomes feasible.
 
Well I was able to create a 1200m image working with some trimming.
This includes x11/xorg-minimal and x11/xterm for minimal x11-forwarding.

Code:
@mbm:~ # df -h
Filesystem            Size    Used   Avail Capacity  Mounted on
/dev/ufs/mbm-usb-x    1.1G    994M     46M    96%    /
devfs                 1.0K      0B    1.0K     0%    /dev

My excluded.files did not seem to be ignoring some directories so I added them to the post-script.sh

Code:
rm -rf ${WORLDDIR}/usr/local/include
rm -rf ${WORLDDIR}/usr/include
rm -rf ${WORLDDIR}/usr/local/lib/python3.11
rm -rf ${WORLDDIR}/usr/local/lib/*.a
rm -rf ${WORLDDIR}/usr/local/llvm19/bin
rm -rf ${WORLDDIR}/usr/local/llvm19/lib/*.a
rm -rf ${WORLDDIR}/usr/local/llvm19/share
rm -rf ${WORLDDIR}/usr/local/llvm19/include
rm -rf ${WORLDDIR}/usr/local/llvm19/share
rm -rf ${WORLDDIR}/usr/bin/cc
rm -rf ${WORLDDIR}/usr/bin/lldb-server
rm -rf ${WORLDDIR}/usr/bin/ld.lld
rm -rf ${WORLDDIR}/usr/bin/c++
rm -rf ${WORLDDIR}/usr/bin/lldb
rm -rf ${WORLDDIR}/usr/bin/llvm-objdump
rm -rf ${WORLDDIR}/usr/bin/llvm-nm
rm -rf ${WORLDDIR}/usr/bin/llvm-ar
rm -rf ${WORLDDIR}/usr/lib/clang
rm -rf ${WORLDDIR}/usr/lib/dtrace
#
rm -rf ${WORLDDIR}/usr/obj
#
rm -rf ${WORLDDIR}/usr/local/lib/perl5

That really did the trick.
I am still using base and GENERIC kernel so I could cut much more.
 
I was hoping to display GPIO values in an FLTK application that can be viewed via x11-forwarding.

My concept is a dashboard that you can view multiple GPIO boards output graphically.

Each Minnowboard a node and use a central server for collecting and display.

The method is not the best and I should probably be using snmp and a central server for collecting values and displaying. But I am just learning so anything goes.
 

This is not exactly on topic but if I wanted to build something from ports and lets say that whatever I'm trying to build relies on another package or library. If the dependency is available as a binary pkg does the ports system use that or does it build the dependency too? I was attempting to build ghostty but it looked like it was going to build all of the dependencies so I bailed. (i5 NUC 13) Is there a way to instruct ports to use binary dependencies if they're available in the repos?
 
This is not exactly on topic but if I wanted to build something from ports and lets say that whatever I'm trying to build relies on another package or library. If the dependency is available as a binary pkg does the ports system use that or does it build the dependency too? I was attempting to build ghostty but it looked like it was going to build all of the dependencies so I bailed. (i5 NUC 13) Is there a way to instruct ports to use binary dependencies if they're available in the repos?
Yes, ports expect dependencies to be build from source too, but you can install only the missing dependencies by running
make install-missing-packages
target.
 
Back
Top