hovercats / kiss-somethingsomethingstatic Goto Github PK

Currently, to be able to build velox, I had to rebuild several packages with
shared libs. This is not what we want.

It complains about several missing references, however, pointing to them doesnt
seem to do much. I need to investigate further.
It does look very much like when I built DWM statically.

In the mean time, to get velox to build we need to build some packages with
shared libs.

• swc
• wld
• fontconfig
• libffi
• libpng
• libxml2
• expat
• pixman

These will have to be built with shared libs, untill we find a fix for this.

Building dmenu is roughly the same sitation as with st (see issue #7).
However, as opposed to st, dmenu however didnt build for me when I check
earlier.
Similarly to st, I also belive dmenu may be outdated (this needs to verified if
its the case). Which needs fixing aswell. Either by finding another port, or
creating a port myself.

Build a static mpv with framebuffer backend.

ok, so I really want to have mpv (or something similar, we could also use ffplay
from ffmpeg, and avoid dealing with mpv altogether.).
Initially mpv uses waf buildsystem, which is python based. Im somewhat trying to
avoid this, but we will see what we end up.
In any case, Ill use this issue to keep track of required packages for building mpv

[] mpv
[] alsa-lib
- alsa-lib has some bugs when building static libs, making the build fail.
- I need to investiagate this further.
- Im also curious about if we can use tinyalsa instead.
[x] ffmpeg
- ffplay is enabled, but Ive yet to manage to make it play anything
- Complains about sdl cant be initialized
- and questions if DISPLAY variable is set.
[x] lame
[x] libass
[x] libogg
[x] libvorbis
[x] libvpx
[x] libwebp
[x] linux-headers
[x] libressl
[x] nasm
[x] opus
[x] pkgconf
[x] x264
[x] x265
[x] xvidcore
[x] freetype-harfbuzz
[x] python
[x] wayland
[x] wayland-protcols
[] mesa
- We're trying to get around this.
- I know people run mpv inside framebuffer, so I know its possible to run
off of FB. I just need to do more research on how to accomplish this.

It seems that we have no way of copying, or pasting anything atm.
This causes abit of frustration when dealing with things one would normally
copy/paste, like links or similar stuff.
St does not appear to have any keybindings for copy/pasting either.
wl-clipboard also segfaults on me, rendering it useless.

Building the kernel, more often than not requires libelf.
However, we're trying to get around this.
According to Oasis linux's wiki, one
needs libelf's library and header if you enable ORC unwinder.
I personally, have tried to enable guess unwinder, and framepointer unwinder to
no avail.

log:

/usr/bin/ld:
/usr/lib/gcc/x86_64-pc-linux-musl/11.2.0/../../../../lib/libelf.a(elf_compress.o):
in function `__libelf_compress':
(.text+0x116): undefined reference to `deflateInit_'
/usr/bin/ld: (.text+0x12c): undefined reference to `deflateEnd'
/usr/bin/ld: (.text+0x19a): undefined reference to `deflateEnd'
/usr/bin/ld: (.text+0x1cf): undefined reference to `deflateEnd'
/usr/bin/ld: (.text+0x28a): undefined reference to `deflate'
/usr/bin/ld: (.text+0x2b2): undefined reference to `deflateEnd'
/usr/bin/ld: (.text+0x30a): undefined reference to `deflateEnd'
/usr/bin/ld: (.text+0x36f): undefined reference to `deflateEnd'
/usr/bin/ld: (.text+0x39d): undefined reference to `deflateEnd'
/usr/bin/ld: (.text+0x3e3): undefined reference to `deflateEnd'
/usr/bin/ld:
/usr/lib/gcc/x86_64-pc-linux-musl/11.2.0/../../../../lib/libelf.a(elf_compress.o):
in function `__libelf_decompress':
(.text+0x4c3): undefined reference to `inflateInit_'
/usr/bin/ld: (.text+0x4ed): undefined reference to `inflate'
/usr/bin/ld: (.text+0x510): undefined reference to `inflateReset'
/usr/bin/ld: (.text+0x51e): undefined reference to `inflateEnd'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:59: /usr/src/linux-5.14.12/tools/objtool/objtool] Error 1
make[1]: *** [Makefile:69: objtool] Error 2
make: *** [Makefile:1371: tools/objtool] Error 2
make: *** Waiting for unfinished jobs....

having libelf's shared libs, will fix the issue, but we dont want these shared
libs.

Update: Its come to my attention that the requirement for libelf, lies not ONLY
with using ORC unwinder or not, but also wether or not you have an intel gpu/cpu.
If, like me, you have amd/radeon, you will have to use libelf.
However, this doesnt answer the underlaying question, about how to build linux
against a static libelf. Ill be investigating this further.

toybox currently needs bash to build.
this is subject to change later on, once toysh is done, but for now it needs
bash.
however, theres a patch to change that, I just havent gotten around fixing it
yet, as the patch is for a older state of toybox, so it needs to be updated to
fit 0.8.7

When booting with toybox mount, mount will error out (non-fatally) on resource
being busy.

Seeing as the error isnt fatal, a simple exit will get us back on track.
Now, afaik toybox mount is considered complete, and we can either pester the
devs about this, or find a way around it.

edit: I did some testing on this, and the issue actually seems to pop up when
running mount -a, and not remounting it as I initially thought.
adding a || true after mount -a will make shell bypass the error, and give
us the login prompt despite the error.

The issue does not persist with util-linux's mount.
So for those whose bothered by it can just go ahead and switch to that instead.
I also dont belive ubase's mount have this issue either.

Im thinking we could possibly try to get shell to instead ignore this error
instead of erroring out on it. though this will probably give us issues if
other errors occurs.

Reference #18

Shutdown and reboot does work, but our current method will ignore everything
and just instantly shutdown/reboot.
This is indeed the quickest way of shutting down, but not the safest.
Properly unmounting drives etc is prefered, and thus what we will be going for.

Reference #18

Building linux, or its headers will fail, and complain about fixdep is
missing.
Fixdep exists in the kernel tree, in scripts/basic/, so its not missing.
I figured we could just compile fixdep beforehand, but no. it still fails and
complains about the same issue

edit: if we add 'HOSTCC=$CC -static' to linux-headers' buildscript, I was able
to build headerfiles without the precence of libc.so.
however, linux still did not build for other unknown reasons.
oasis recommends using 'HOSTCC=$CC\ -static', but I cant build neither with
this. Its small, but its progress none the less.

The source for our st build hasnt recieved any updates in a rather long time.
We need to fix this.

We could either find a new one, or port it ourselves.
Im probably going to try the latter, by just referencing the source we already
have, and see if I cant hack together a port from the newest release.

use sndio instead of alsa-lib.
sndio does not support this nativaly, but patches are already available.

Ive gotten snio to build previously, but not statically yet.

Same situation as ST. needs updating, and Ill probably see if I cant port it
myself from the most recent release.
Unless someone already have the work done, which is unlikely, and I dont bother
trying to look for it either.

Ill edit in info later. Just wanted to throw this up there.

while our current st buildscript does build, its not configured statically yet.
I didnt have the time to check into this last time, so I havent gotten much
further than creating this issue tbh.

Since the removal of baseinit package, Ill be adding new ones to baselayout.
Ill be taking notes from Oasis linux's scripts, however, these will however
currently be written in sh instead of rc like Oasis'.

This should however not interefere with KISS' already great ability to switch
out your systems init, core, or service manager as people please.

[x] rc.init
* Just your regular bootscript
* toybox mount will non-fatally error out on not being able to mount /
* hitting ctrl + d will bypass this and give you the login prompt
* root partition may or may not have properly mounted at this point, and
may need remounting manually.
[x] rc.shutdown
* Same as above, but for shutting dowm
* neither shutdown nor reboot does currently work
* toybox's reboot utility works
* ive only gotten it to work with -f option yet.
* so needs more looking into.
* see #21
[x] rc.local
* For misc user configuration

As per 0.34.0 release, we're stuck with the python based waf build system.
With this buildsystem, we can pass -enable-static-build, and to your suprise,
not have a completely static build. itll still link to libc.so.
This is not enough. We want libc to be statically linked into mpv aswell.
Also; passing CFLAGS/LDFLAGS=-static like we usually do, does nothing, if not
make the build fail after configuring.

Also also; as per Nov. 14, 2021, support for the meson buildsystem were added, which
brings some new possibilites.
By using meson, and a few seds into build/build.ninja, I was able to build a
static mpv binary. Albeit, with no sound.

To get sound working again with meson system, I had to not link it statically,
aswell as build alsa-libs' shared libs.
Without these shared libs, I cant get any sound regardless of using waf or meson.
It does however not matter if alsa-libs' aserver bin is built statically or
not.

When using meson, I havent been able to build the manpage either, which Im sure
some may appreciate if where there.
We could just bundle a premade one instead, and save everyone the time it
takes to compile the manpage aswell, with both buildsystems.

I will have to investigate this further, and Ill probably update this post
with my findings if neccessary.

For a while, Ive been wanting to switch to netbsd-curses, from ncurses, as its a
simpler implementation of the curses libs. Its for the most part drop-in, with
only a handfew packages requiring intervention on our hand.

Ive been playing with this on X11 before, without much hassles at all really.
However, now its giving me issues. More specifically, vim is giving me issues.

Upon launching vim, the terminal turns to a white background instead of
having your terminals default background color (which is probably not
white..)

This does not happen on other editors Ive tested.

• neovim
• vis
• nano

Neither is affected by using either ncurses, or netbsd-curses, which is strange.

Im not really sure whats the issue here, I initially thought it had somehing
todo with the terminfo files lacking, as Ive had issues with it earlier on st.
But including those from ncurses does nothing at all.

So currently, we stopped python at v3.9.6. Which is the latest version before
they dropped support for libressl iirc.
Latest is as of writing this 3.10.2, and we have a patch that should work, I
just havent been able to build python with it, but iirc, it fails due to some
modules doesnt build. Ill have to look more into this.

edit: managed to build 3.9.9 right ootb.
This mean, that as of 3.10 and up, python will need patching, to be able to
build with libressl.

edit2: 3.10.0 builds fine. but had to remove 2 parser modules, which seems to
have been removed upstream. python also complained about not being able to
select a cypher. So I added some flags specifying them.
3.10.1 also built fine.

3.10.2 needs to have the patch adjusted.