Post AZ6PhusNqKN4AFf1fc by zirias@techhub.social
(DIR) More posts by zirias@techhub.social
(DIR) Post #AZ6PhqxuNqPi2EDNj6 by zirias@techhub.social
2023-08-18T06:36:54Z
0 likes, 2 repeats
Finally, my #Linux-native #GNU toolchain for #FreeBSD's #Linuxulator works for C and C++ on #aarch64, #amd64 and #i386 π₯³ I guess that's a good time to actually announce the ongoing project!https://lists.freebsd.org/archives/freebsd-ports/2023-August/004263.html
(DIR) Post #AZ6Phrsyxe4EtEuxge by zirias@techhub.social
2023-08-18T20:33:17Z
0 likes, 0 repeats
And now, we have a working #Linux #bash running in #FreeBSD's #linuxulator Which also finally makes the "ldd" script installed by #glibc work πOk, enough for today πhttps://github.com/Zirias/zfbsd-ports/blob/linux/shells/linux-bash/Makefile
(DIR) Post #AZ6PhsgG0RTzM3yJUW by zirias@techhub.social
2023-08-19T20:04:48Z
0 likes, 0 repeats
Today's progress: #GNU #coreutils and glibc's localedata seem to work fine in #FreeBSD's #Linuxulator, in addition to bash.Still, coreutils is not complete yet, it *should* use hash functions from #OpenSSL, so, time to port that for #Linux (tomorrow).
(DIR) Post #AZ6PhtLNXYNNPbD9aS by zirias@techhub.social
2023-08-19T09:52:01Z
0 likes, 1 repeats
Time for cleanup after identifying two "interesting" issues:1.) #FreeBSD ports come with a Templates/config.site file which is normally used by #GNU #autoconf, containing quite a lot of "cache variables" so autoconf can avoid running the actual tests. Nice, but completely wrong when targeting #Linux. So, add an empty "CONFIG_SITE=" variable to every linux port, and suddenly I can also remove some explicit cache variables again π 2.) I'm building the "native" toolchain for #Linuxulator --with-sysroot=/compat/linux, which makes sure the linker reliably finds startup files and system libs, without stuff from FreeBSD base interfering. BUT: This completely breaks when some explicit lib path to /usr/lib or /usr/lib64 is added (and many build systems will do that), because sysroot doesn't apply here. Therefore, add wrapper scripts around gcc and g++ filtering out any "-L/usr/lib" or "-L/usr/lib64" argument π with that, Linux #bash builds without any patches! π₯³ Now, waiting for builds.
(DIR) Post #AZ6PhtSp5sKZmgh6Bs by zirias@techhub.social
2023-08-20T20:55:27Z
0 likes, 0 repeats
Today's achievement: We now have #OpenSSL (and #GNU coreutils built using it), plus grep, sed, awk, make, groff *and* man-db in #FreeBSD's #Linuxulator userland.But there's a catch π It doesn't build with #poudriere any more. Can be patched, and I guess I should soon look into getting this fixed... (**edit**: See answer, somewhat working without a patch now!)For details, see here:https://lists.freebsd.org/archives/freebsd-ports/2023-August/004286.html
(DIR) Post #AZ6PhudUjgSfQ4h8Sm by zirias@techhub.social
2023-08-21T18:01:57Z
0 likes, 1 repeats
For the next iteration, support #Linux 5.15 on #FreeBSD versions supporting it ... doing this full rebuild again to test. π₯±
(DIR) Post #AZ6PhusNqKN4AFf1fc by zirias@techhub.social
2023-08-19T19:50:04Z
0 likes, 0 repeats
And I still have NO idea where these errors regarding the ELF program interpreter come from when building #gcc and its libstdc++. They do NOT appear in the build log, they are somehow just spit to the controlling terminal of #poudriere. And I didn't find anything not working in these packages so far ... π€―
(DIR) Post #AZ6PhvUJZIiE3tPJnE by zirias@techhub.social
2023-08-23T21:03:26Z
0 likes, 0 repeats
In case anyone tried and wondered why the branch is currently broken π I'm working on adding a new USES for this #Linuxulator userland. It should hide all the "crap" needed to build it, and also help with creating new ports, either *for* it (e.g. shared libs), or just using it.So I have to rework each and every port now, including test builds...Right now, I'm test-building "native" gcc ... for the third time π so, native toolchain almost complete again.I hope to get the branch into sane shape tomorrow!#Linux #FreeBSD #Linuxulator
(DIR) Post #AZ6PhvvbvoXxQYB7L6 by zirias@techhub.social
2023-08-21T07:09:09Z
0 likes, 0 repeats
Good news, I found a workaround without patching poudriere, my branch is updated!poudriere-testport will probably fail, but poudriere-bulk works this way.
(DIR) Post #AZ6PhwKQRYOcfVmw1A by zirias@techhub.social
2023-08-24T20:17:18Z
0 likes, 1 repeats
Userland built from source for #FreeBSD's #Linuxulator is making progress again (and yes, my branch builds and works again!)βοΈ Metaports "linuxsrc_base" for a minimal base userland and "linuxsrc-devtools" for minimal basic tools needed to build #Linux software (just C and C++ and some common tools)βοΈ Automatic selection of the Linux kernel version based on target FreeBSD version, overridable in DEFAULT_VERSIONS (but checked for compatibility of course)βοΈ A new "USES=linuxsrc" to do all the ugly "plumbing" needed for building Linux software using FreeBSD #ports, offering different configurations.Guess now I could start adding some optional packages and try to get some *real* Linux application working π https://github.com/Zirias/zfbsd-ports/blob/linux/Mk/Uses/linuxsrc.mk
(DIR) Post #AZ6PhwSvvvCZ5tljHM by zirias@techhub.social
2023-08-19T21:05:13Z
0 likes, 0 repeats
Leisure Suit GNU looking for program interpreter in several wrong places πI *think* I'll "solve" that the way many #Linux distributions seem to do it nowadays -- add two symlinks: /lib -> usr/lib and lib64 -> usr/lib64.It's a horrible mess, but after already doing the same for bin and sbin, well ... maybe it's the "sane" solution π
(DIR) Post #AZ6Phxkh9N0H5H5QbQ by zirias@techhub.social
2023-08-25T18:10:18Z
0 likes, 0 repeats
Spent this day (besides work, hehe) simplifying a few ports and hunting down a few bugs and now, it all builds fine on all supported target systems (#FreeBSD {13.2,14.0}/{aarch64,amd64,i386}). Yay.So, just tried to create a *very* first port in "dist" mode (installed to Linuxulator prefix, but not part of the "base" system).Well, I guess the "interesting" issues just begin π https://lists.freebsd.org/archives/freebsd-current/2023-August/004433.html
(DIR) Post #AZ6PhyFtHNxOe1gLE8 by zirias@techhub.social
2023-08-20T11:38:24Z
0 likes, 0 repeats
Added these symlinks.#glibc needs some "convincing" to install *everything* to /usr, but it works.It solves the issue on #aarch64 and #i386 (which both install the program interpreter to /lib by default).It does NOT solve the issue on #amd64, where the program interpreter is installed to /lib64, but *something* during #GCC build insists on finding it in /usr/lib instead. π€―Trying a hack with a hardlink now (after learning that glibc's ldconfig just deletes symlinks to the program interpreter).