Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update compilation.yml #9

Closed
wants to merge 1 commit into from
Closed

Update compilation.yml #9

wants to merge 1 commit into from

Conversation

AKuHAK
Copy link
Contributor

@AKuHAK AKuHAK commented Apr 20, 2022

Typos fixed

@@ -43,5 +45,5 @@ jobs:
automatic_release_tag: "latest"
title: Development build
files: |
iopmod-modules-${{ github.sha }}
iopmod-modules.tar.gz
Copy link
Owner

@frno7 frno7 Apr 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose that we sprinkle the file name with tags such as ubuntu and x86-64. Alternatively, much better, we could build statically linked tools. Such tools would work with all Linux/x86-64 variants (Fedora, Arch, Debian, Slackware, Gentoo, and so on and so forth), as they are independent of libraries and only use Linux kernel system calls.

Sadly, the tools still won’t work for people on POWER and RISC-V and other free architectures. Unless we apply the Gentoo crossdev package again, not only for the R3000 modules, but for these as well... :-)

@frno7
Copy link
Owner

frno7 commented Apr 21, 2022

@AKuHAK, with commit 0707601, try make LDFLAGS=-static V=1 tool to obtain statically linked tools. :-) Do ldd tool/iopmod-info and it’d print not a dynamic executable, meaning it has no library dependencies, as opposed to a dynamically linked tool that’d have something like

	linux-vdso64.so.1 (0x00007fffa0d70000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fffa0af0000)
	/lib64/ld64.so.2 (0x00007fffa0d90000)

which generally makes it incompatible with many distributions, due to other library versions being installed than the ones required. The statically linked tools use Linux kernel system calls directly instead, since libc and so on are built-in.

Note that static linking is incompatible with the sanitation checks, so the combination LDFLAGS=-static S=1 yields cc: error: cannot specify -static with -fsanitize=address. Pick one, or compile both separately with a make clean inbetween. :-)

In commit frno7/gentoo.overlay@cde495d I’ve also made a new Gentoo package sys-firmware/iopmod, having the static USE flag. Unmask the latest HEAD version, and install it like so:

% echo '=sys-firmware/iopmod-9999 **' >/etc/portage/package.accept_keywords/iopmod
% USE=static emerge -v sys-firmware/iopmod

We could combine this with the sys-devel/crossdev package to supply various flavours of architectures other than x86-64.

Perhaps a modules USE flag could be added to compile the IRX files too.

@frno7
Copy link
Owner

frno7 commented Apr 23, 2022

@AKuHAK, with commit frno7/gentoo.overlay@17665bd it’s now possible to do

USE="modules -tools" mipsr5900el-unknown-linux-gnu-emerge -v sys-firmware/iopmod

to have the modules installed in

/usr/mipsr5900el-unknown-linux-gnu/lib/firmware/ps2

It’s possible to cross-compile with the modules and tools USE flags combined as well (the details are explained in frno7/gentoo.overlay@17665bd), although for most purposes this shouldn’t be necessary, since one typically doesn’t need the tooling for the R5900.

@frno7 frno7 force-pushed the main branch 12 times, most recently from ca1a75c to 27e2d87 Compare May 1, 2022 10:16
@frno7
Copy link
Owner

frno7 commented May 1, 2022

Merged. Thanks for your contribution, @AKuHAK! https://github.com/frno7/iopmod/actions now supplies modules, as well as statically linked tools for ppc64le, AArch64, and x86_64. :-)

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants