Porting Slackware LoongArch process shared(stage1-4)
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
The `loongarch64` might be the most helpful (accepted?). Today I ran into a Python 'meta-module' "oldest-supported-numpy" as build-requirement for some packages. In the "META" file they use that:
The `loongarch64` might be the most helpful (accepted?).
If you export ARCH=loong64, packages based on libtool/configure script (bash, glibc, gcc, etc...) won't build (unsupported architecture) unless you remove the "--build" parameter from "configure". Other build scripts based on cmake or meson/ninja don't care about "$ARCH" environment.
So, you have three options:
1. Remove the "--build=$ARCH-slackware-linux" (the script will autodetect the architecture)
2. Add a specific entry for "loong64" in the statements:
Code:
case $ARCH in
arm*) TARGET=$ARCH-slackware-linux-gnueabi ;;
loong64) TARGET=loongarch64-slackware-linux ;;
*) TARGET=$ARCH-slackware-linux ;;
esac
3. Leave "$ARCH" environment as "loongarch64", set a new environment (SLACKARCH?) to "loong64" and update the "makepkg $TMP/$PKGNAME-$VERSION-$SLACKARCH-$BUILD.txz" on every build script.
However, my suggestion is to set loongarch64 as ARCH: it leaves mostly untouched Slackware build scripts, and I don't think that 4 characters more will consume so many disk space.... ;-)
The `loongarch64` might be the most helpful (accepted?). Today I ran into a Python 'meta-module' "oldest-supported-numpy" as build-requirement for some packages. In the "META" file they use that:
If you export ARCH=loong64, packages based on libtool/configure script (bash, glibc, gcc, etc...) won't build (unsupported architecture) unless you remove the "--build" parameter from "configure". Other build scripts based on cmake or meson/ninja don't care about "$ARCH" environment.
So, you have three options:
1. Remove the "--build=$ARCH-slackware-linux" (the script will autodetect the architecture)
2. Add a specific entry for "loong64" in the statements:
Code:
case $ARCH in
arm*) TARGET=$ARCH-slackware-linux-gnueabi ;;
loong64) TARGET=loongarch64-slackware-linux ;;
*) TARGET=$ARCH-slackware-linux ;;
esac
3. Leave "$ARCH" environment as "loongarch64", set a new environment (SLACKARCH?) to "loong64" and update the "makepkg $TMP/$PKGNAME-$VERSION-$SLACKARCH-$BUILD.txz" on every build script.
However, my suggestion is to set loongarch64 as ARCH: it leaves mostly untouched Slackware build scripts, and I don't think that 4 characters more will consume so many disk space.... ;-)
Later, I want to transplant my good Slackware-LoongArch system to provide you with use, I expressed my ARCH idea, and listen to everyone's opinions, finally I choose ARCH=loong64 iso: https://github.com/slackwarecn/slack...eases/tag/v0.3
I bet the work you're doing is very helpful; before you started this thread I never had heard of this new architecture until I cam across "loongarch64" in a fake-python module that relieves some programmers from checking a pile of conditionals but interferes with building from source on Slackware.
My post was not intended to undermine your work, on the contrary. Assuming it is still in early stages, it might be more pragmatic to go along with what the "world out there" is using and see whether settling on a common term is possible. I would guess that this would prevent tons of headaches with respect to adapting/calling scripts in the future.
As it stands, the referred python-package would guess a wrong arch when your box is advertising itself has "loong64" and this would force slackware-users/maintainers to come up with a patch to make it all happen.
Democracy is a great good but sometimes changing course from the one voted for can help to deal with problems that happen to turn up. Even when a 'minority' suggests this other direction. When this change seems reasonable, why not? Have another vote on this if needed. That's how a proper democracy would operate.
As it stands, the referred python-package would guess a wrong arch when your box is advertising itself has "loong64" and this would force slackware-users/maintainers to come up with a patch to make it all happen.
Hi, Rob
I didn't quite understand the problem you mentioned，didn't find this problem when I was Slackware-LoongArch bootstrap-build. Could you please send me the repeating steps，thanks
Now Archlinux Debian Gentoo and my Slackware are both using ARCH=loong64, haven't seen this problem. I really hope to continue the discussion with you to make Slackware LoongArch more useful!
Hi Pujin, see post #33 and the links. I'm no expert and not using this architecture (no need to compile for it) and if those distributions you mention use the same stick to it ;-). Possibly the developer of that python-module is the one that needs to change definitions or add alternatives. Is loongarch64 used by ubuntu?
Now Archlinux Debian Gentoo and my Slackware are both using ARCH=loong64
We have to distinguish between the arch assigned to the package name, that could be anything you want (loong, loong64, loongarch, loongarch64, etc.) and the target tuples, that should always start with loongarch64-* (for Slackware, loongarch64-slackware-linux), otherwise most of the packages won't build.
Quote:
Originally Posted by shipujin
haven't seen this problem.
Slackware build scripts are based on the $ARCH environment variables: if this variables is not exported, it will be assumed as `uname -m`. Most of Slackware packages set also by default the name of package as $PKGNAME-$VERSION-$ARCH-$BUILD.txz, so by default you will have "loongarch64" as the "arch" name. If you want to have "loong64", you can follow one the 3 options I already said in post #34, or you can also simply rename the package after building it.
But there are 2 other problems:
1) LIBDIRSUFFIX is set to "64" only for x86_64. For architectures that could have dual word-size (32/64 bit), it will be a good practice to set "64" as LIBDIRSUFFIX for the 64bit variant.
2) Some packages that use libtool/configure/config.guess/config.sub scripts were not updated to support loongarch64 architecture. You should copy the system config.guess/config.sub scripts before running "configure".
For example, the build script for "acl" package should be fixed in this way:
In your repository: https://github.com/slackwarecn/slackware-loongarch64/
I did not see any change to the this build script, so I suppose you manually modify the script while building, that maybe is not the best practice for an automated (or semi-automated) building process.
The Slackware unofficial porting for loongarch64 I maintain (https://bonslack.org/bonslack_loongarch64-current/) already has the Slackware build scripts "patched" to support loongarch64 and other architectures. The patching process is mostly automated by the "fix_flags_libdir.{pl,sh}" scripts you can find here: https://bonslack.org/source-current/scripts/
To avoid more "patching" to Slackware build scripts, I leave ARCH as loongarch64. But, if you prefer to have "loong64" in the package name, you can simply run "rename -- -loongarch64- -loong64- slackware/*/*".
Hi Pujin, see post #33 and the links. I'm no expert and not using this architecture (no need to compile for it) and if those distributions you mention use the same stick to it ;-). Possibly the developer of that python-module is the one that needs to change definitions or add alternatives. Is loongarch64 used by ubuntu?
Thanks for those links.
Hi, Rob
Now I know your problem， you said *.SlackBuild added ARCH=loong64 support,
Here I am using python-sane as an example to add ARCH=loong64 support
Code:
diff --git a/source/l/python-sane/python-sane.SlackBuild b/source/l/python-sane/python-sane.SlackBuild
index 851c90cb2..6e0174a72 100755
--- a/source/l/python-sane/python-sane.SlackBuild
+++ b/source/l/python-sane/python-sane.SlackBuild
@@ -32,6 +32,7 @@ if [ -z "$ARCH" ]; then
case "$( uname -m )" in
i?86) export ARCH=i586 ;;
arm*) export ARCH=arm ;;
+ loongarch64) export ARCH=loong64 ;;
# Unless $ARCH is already set, use uname -m for all other archs:
*) export ARCH=$( uname -m ) ;;
esac
@@ -57,6 +58,9 @@ elif [ "$ARCH" = "s390" ]; then
elif [ "$ARCH" = "x86_64" ]; then
SLKCFLAGS="-O2 -fPIC"
LIBDIRSUFFIX="64"
+elif [ "$ARCH" = "loong64" ]; then
+ SLKCFLAGS="-O2 -fPIC"
+ LIBDIRSUFFIX="64"
fi
TMP=${TMP:-/tmp}
In your repository: https://github.com/slackwarecn/slackware-loongarch64/
I did not see any change to the this build script, so I suppose you manually modify the script while building, that maybe is not the best practice for an automated (or semi-automated) building process.
Hi lucabon,
You're looking at the wrong branch, the master branch is origin(current.git), and the ARCH=loong64 branch is LoongArch-20221012
And it wasn't you who reasoned like you did,my Slackware-LoongArch is also built automatically
Recently, I am updating LoongArch-20230213, and xfce, mate and other desktops will come recently
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
