About FreeBSD multi-arch.

fredvs

fredvs

Before all, I want to thank the FreeBSD team for this great feature: FreeBSD 64 bit is able to run and compile 32 bit applications.

Now a few impressions...

About FreeBSD multi-arch...

In FreeBSD 64 bit, to run a FreeBSD-64 bit app, the system uses /libexec/ld-elf.so.1 (that library is, of course, 64 bit).

In FreeBSD 32 bit, to run a FreeBSD-32 bit app, the system uses also /libexec/ld-elf.so.1 (and here that library is, of course, 32 bit).

But for FreeBSD multi-arch 64+32 bit, the system uses in same directory /libexec/ :
ld-elf.so.1 to run a 64 bit FreeBSD app and ld-elf32.so.1 to run a FreeBSD 32 bit application.

So, if a application was compiled on FreeBSD 32 with smart link, one of the smart-link will point to /libexec/ld-elf.so.1 (that must be 32 bit).

But with FreeBSD multi-arch, smartlink will not work because it will point to /libexec/ld-elf.so.1 in place of /libexec/ld-elf32.so.1

Why not use then (sorry, but other Unix os do it with success) the build-in multi-arch shema (that uses FreeBSD and works perfectly) ?:

/lib/libexec/ld-elf.so.1 ===> for 64 bit app
/lib32/libexec/ld-elf.so.1 ===> for 32 bit app

In that case, a 32 bit FreeBSD app with smart-link could work on a multi-arch system.

It is not criticism but a proposition to make life more confortable.

Fre;D
 
That will require re-working FreeBSD to include both 32 and 64 bit but I doubt it'll happen as it'll be a waste of time, money, support and lack of interests. Many Linux distros ceased supporting 32 bit OS and FreeBSD might discontinue 32-bit support in the near future. I know it's possible to download 32-bit libraries and install it in 64-bit FreeBSD but that is all I know.
 
It's not going to go away as long as there is a need to build 32-bit i386 ports on an amd64 system (for example with ports-mgmt/poudriere), the compatibility is what makes it possible. What is not going to happen probably is the ability to install i386 packages alongside with the amd64 packages, this would require a major rework of the ports system and since support for i386 is waning already it's not going to happen.
 
Remington said:
That will require re-working FreeBSD to include both 32 and 64 bit but I doubt it'll happen as it'll be a waste of time, money, support and lack of interests. Many Linux distros ceased supporting 32 bit OS and FreeBSD might discontinue 32-bit support in the near future. I know it's possible to download 32-bit libraries and install it in 64-bit FreeBSD but that is all I know.
Click to expand...

That is extremely sad.

Fre;D
 
You could apply to be a committer and tester to include lib32 in current 64-bit FreeBSD. That's something you will have to discuss with wblock@.
 
Remington said:
You could apply to be a committer and tester to include lib32 in current 64-bit FreeBSD. That's something you will have to discuss with wblock@.
Click to expand...
It would be a honor and I would do it with great pleasure (it FreeBSD maintains to still develop FreeBSD32, of course).

Fre;D
 
Don't get your hopes up too high, it's going to take a lot of effort from you before you'll even be asked to become one.
Access is granted to individuals who contribute a significant amount of code in the form of features or bug fixes.
Click to expand...
Only those that are contributing on a regular basis or have an extreme depth of knowledge of a subsystem will be asked to join the ranks of committer.
Click to expand...
https://wiki.freebsd.org/BecomingACommitter

I would suggest starting by signing up for the various mailing lists and participating in the discussions. Also sign up on the bugtracker and see if you can fix some of the issues by supplying patches. This is something anyone can do, you don't need to be a committer for that.
 
Yup. FreeBSD doesn't want committers who will work for one year and suddenly disappear leaving a broken OS.

Other option is to work with an experienced committer who have deep knowledge of lib subsystem so it won't break the OS.
 
Would it be possible to become a lib32 port committer and create /usr/local/lib32 instead of messing around with the base system?
 
Remington said:
Would it be possible to become a lib32 port committer and create /usr/local/lib32 instead of messing around with the base system?
Click to expand...

The biggest parts of the 32-bit compatibility are in the kernel behind the COMPAT_FREEBSD32 kernel config(5) option, the rest is just the 32-bit dynamic loader and the 32-bit shared libraries that are quite trivial to produce. Moving the libraries to a port doesn't make it any easier to work on the compatibility layer.
 
SirDice said:
Don't get your hopes up too high, it's going to take a lot of effort from you before you'll even be asked to become one.


https://wiki.freebsd.org/BecomingACommitter

I would suggest starting by signing up for the various mailing lists and participating in the discussions. Also sign up on the bugtracker and see if you can fix some of the issues by supplying patches. This is something anyone can do, you don't need to be a committer for that.
Click to expand...

Huh, I never dreamed about this I only answered that if I could help, I will do it with pleasure.

Fre;D
 
Looks like you put lots of effort and energy in the polYdev project, Fre;D. Congratulations!

About your 32-64bit link question, perhaps that a special ld-elf32.so.1 library could be added to the FreeBSD 32-bit build, and that one just redirects to the actual ld-elf.so.1 32-bit library. New 32-bit applications would just need to make sure to use ld-elf32.so.1 if they care about bit-size compatibility, and the kernel wouldn't even need to be changed. This solution looks simple to me (from afar). What do the dev.team think about that?

Dominique.
 
fossette said:
Looks like you put lots of effort and energy in the polYdev project, Fre;D. Congratulations!

About your 32-64bit link question, perhaps that a special ld-elf32.so.1 library could be added to the FreeBSD 32-bit build, and that one just redirects to the actual ld-elf.so.1 32-bit library. New 32-bit applications would just need to make sure to use ld-elf32.so.1 if they care about bit-size compatibility, and the kernel wouldn't even need to be changed. This solution looks simple to me (from afar). What do the dev.team think about that?

Dominique.
Click to expand...
Hello Dominique and thanks for your advice.

Yes, this is a other solution adding ld-elf32.so.1 (or changing the name of original ld-elf.so.1) in a 32 bit system and each 32 bit application must be re-compiled and smart link point to ld-elf32.so.1.

The code of the linker will be something like:
if application is 32bit then smart-link ld-elf32.so.1 else smart-link ld-elf.so.1.
But here also, all the applications must be recompiled...

Sorry but the only real multi-arch design is the one used by other Unix system (Huh, yes , like Linux).
And yes, that would ask (honestly not lot of) some change in FreeBSD code.
/lib/libexec/ld-elf.so.1 ===> for 64 bit app
/lib32/libexec/ld-elf.so.1 ===> for 32 bit app


PS: Only my 0.2 cents opinion.

Fre;D
 
marino@ said:
https://www.perkin.org.uk/posts/multiarch-package-support-in-smartos.html
Click to expand...
Yes marino@, Linux is not the only one.
And I have checked SmartOS doc and they also use the "/lib32 + /lib64" design-way for multi-arch (all 32 bit libraries in /lib32 and all 64 bit libraries in /lib64).

The problem with FreeBSD-multiarch, like explained in my first post, is that FreeBSD do not use the "/lib32 + /lib64" multiarch design-way for one library : ld-elf.so.1.
FreeBSD opted to add ld-elf32.so.1 in same directory as ld-elf.so.1. ----> /libexec/.

But all that discussion has no sense because it seems that FreeBSD decided to stop to maintain FreeBSD 32 bit.
And I find it absolutely extremely sad and I think to all the people who use FreeBSD 32 for their RaspberryPi.

Fre;D
 
many platforms have already dropped i386 and the rest are coming sooner rather than later. It's only a matter of time.
The number of people that think "it's extremely sad" are far outnumbered by the people that don't care at all (including developers)
 
I sympathize with your 32 bit concerns but Arm 32 bit builds(armv6) are different than an i386 build. Just check the kernconf files.

I too am worried about dropping 32 bit Intel support. There are many embedded product still in use with 32 bit CPU's.

Infact the last Intel 32 bit processor was the Atom N270 released in Q2-2008. I don't see where FreeBSD needs more than 4GB ram in most embedded platform instances, so I see no advantage to 64 bit whatsoever.
 
Phishfry said:
I too am worried about dropping 32 bit Intel support. There are many embedded product still in use with 32 bit CPU's.
Click to expand...

but no new ones are being produced (or production will end very soon). The existing ones can continue to use older releases of FreeBSD (or another other OS) or if somebody *must* have the latest, I'm sure NetBSD and OpenBSD will continue to support it longer than anyone.
 
ljboiler said:
What is "smart link", please?
Click to expand...

I'm guessing it's an imaginary technology, the invention of which would be necessary to put this "simple" idea into practice.

fredvs said:
And I find it absolutely extremely sad and I think to all the people who use FreeBSD 32 for their RaspberryPi.
Click to expand...
Phishfry said:
Arm 32 bit builds(armv6) are different than an i386 build.
Click to expand...

And here we come to it. 32-bit instructions are not unique to x86, and the decision to stop supporting 32-bit x86 CPUs---a dying technology---is perfectly reasonable. AMD64 will be the standard on desktops and laptops for the next decade or so, until it is superseded by ARM64 or some comparable super-efficient RISC architecture. Low-powered embedded devices have been steering toward 32-bit ARM for years now, and mobile devices are almost exclusively ARM, though some are 64-bit while most are 32-bit.

I own a Samsung Galaxy Tab 3 Android tablet. It was a gift, but the person who gave it to me got it for very, very little money. Turns out the reason for that is that it was discontinued quickly on account of having an Atom i386 CPU in it, which means it eats up battery life, generates more heat than a tablet should, and a fair amount of software in the Google Play Store doesn't run on it and projects like Cyanogenmod won't even touch it. A comparable ARM tablet would get me more software, a better operating system and better battery life. Should I complain to the relevant projects, or buy a new, objectively superior tablet once support finally dies?
 
You must log in or register to reply here.
Back
Top