About FreeBSD multi-arch.

fredvs · Oct 9, 2016

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

;-)

Here is the full description from the FPC Programmers Manual.
Same definition ca be used for smart-linking C programs.
http://www.freepascal.org/docs-html/current/prog/progsu118.html#x126-1270001.3.35

That said and also that x86 CPU is nearly dead, IMO, it is not a reason to not try to make FreeBSD a efficient multi-arch system, keeping the still x86 CPU users alive.

Fre;D

ASX · Oct 10, 2016

fredvs said:
Here is the full description from the FPC Programmers Manual.
Same definition ca be used for smart-linking C programs.
http://www.freepascal.org/docs-html/current/prog/progsu118.html#x126-1270001.3.35

The "smartlinking" mentioned above is completely out of context, describe a technique to link smaller objects into an executable, to reduce the final size.

What's the problem your proposal is going to solve ? What's the problem in having a /libexec/ld-elf32.so ?

Code:

#include <stdio.h>
int main()
{       printf("Hello world!\n");
        return 0;
}

This is a C program, you can easily generate either a 64 bit executable or a 32bit executable, from a 64 bit host:

Code:

$ uname -p
amd64
$ cc hello.c -o hello64
$ cc -m32 hello.c -o hello32
$ file hello64 hello32
hello64: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 10.3, not stripped
hello32: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 10.3, not stripped
$ ./hello64
Hello world!
$ ./hello32
Hello world!

Please have a look at the output of file command above, specifically at "interpreter", and may be take a look at rtld(1)

May be "the multiarch problem" is already solved, isn't it ?

fredvs · Oct 10, 2016

The "smartlinking" mentioned above is completely out of context, describe a technique to link smaller objects into an executable, to reduce the final size.

This "technique" also link some needed libraries, indeed to reduce the final size.

What's the problem your proposal is going to solve ? What's the problem in having a /libexec/ld-elf32.so ?

Because with smart-linking, one of the link will point to /libexec/ld-elf.so in place of /libexec/ld-elf32.so

This is a C program, you can easily generate either a 64 bit executable or a 32bit executable, from a 64 bit host:

Yes, as motioned earlier, there is no problem to run no-smart-linked 32 bit program, even if it was compied with fpc.
The problem occurs only with smart-link.
Note that with the Linuxator multi-arch, 32 bit smart-linked programs can run.

May be "the multiarch problem" is already solved, isn't it ?

For smart-linked program, no, sorry.

Fre;D

marino · Oct 10, 2016

i don't have a 32-bit freebsd handy.
For somebody that does, can they run this command against any C program? readelf -a <program> | grep interpreter
e.g. readelf -a /bin/ls | grep interpreter or any locally compiled test program as well.

On amd64 it returns "[Requesting program interpreter: /libexec/ld-elf.so.1]"

I suspect on i386 it returns "[Requesting program interpreter: /libexec/ld-elf32.so.1]" I also suspect there's a ld-elf.so.1 on i386 that is a symlink/hardlink to ld-elf32.so.1

That's how you can compile a C program on FreeBSD32 and have it run on FreeBSD amd64 with 32-bit compatibility libraries installed.

and if so, that simply means that FPC's "smart linking" is using the wrong (OLD) interpreter name, in other words, FPC needs to be fixed.
There's no problem with "multiarch", fredvs just assumed it so because FPC isn't behaving as he expects.

ondra_knezour · Oct 10, 2016

fredvs said:
But all that discussion has no sense because it seems that FreeBSD decided to stop to maintain FreeBSD 32 bit.

https://lists.freebsd.org/pipermail/freebsd-questions/2016-September/273741.html

ASX · Oct 10, 2016

marino@ said:
i don't have a 32-bit freebsd handy.
For somebody that does, can they run this command against any C program? readelf -a <program> | grep interpreter
e.g. readelf -a /bin/ls | grep interpreter or any locally compiled test program as well.

On amd64 it returns "[Requesting program interpreter: /libexec/ld-elf.so.1]"

From an i386 live DVD:

Code:

% uname -p
i386
% readelf -a /bin/ls | grep interpreter
      [Requesting program interpreter: /libexec/ld-elf.so.1]
% ls -l /libexec/ld-elf*
-r-xr-xr-x  1 root  wheel  104732 Mar 25  2016 /libexec/ld-elf.so.1

My 32 bit binary, compiled and linked on amd64

Code:

$ uname -p
amd64
$ readelf -a hello32 | grep interpreter
      [Requesting program interpreter: /libexec/ld-elf.so.1]

The interpreter however is loaded by the kernel, as stated in rtld(1), in fact I removed /libexec/ld-elf32.so.1 and when running the 32bit binary:

Code:

# ./hello32
ELF interpreter /libexec/ld-elf.so.1 not found, error 8
Abort
# ls -l /libexec/ld-elf.so.1
-r-xr-xr-x  1 root  wheel  128544 Mar 25  2016 /libexec/ld-elf.so.1

To me it means that the amd64 kernel remap "ld-elf.so.1" to "ld-elf32.so.1" when running a i386 executable, and no difference exists between an executable built on i386 or an amd64.

fredvs, please post an example of what is not working for you.

marino · Oct 10, 2016

Thanks for checking. I was trying to figure out how that mechanism actually worked. I didn't review the man page.
Presumable one could review the kernel code to figure out how the kernel determines it's a 32-bit program and thus select the right rtld. FPC might be missing writing key ELF information.

fredvs · Oct 10, 2016

ASX said:
fredvs, please post an example of what is not working for you.

OK, but, please, do not persist to demonstrate that a no-smart-linked 32 bit program can be run on a multi-arch system.
I know this and I have explain it already lot and lot and lot of time in this thread.

For the example, it is for ALL the programs compiled and linked with smart-linking (with fpc ---> -XX parameter).

Here what append when trying to run a FreeBSD 32 bit smart-linked application on a multi-arch system.

After debugging, it appears that "no found, error 8" is caused because ld-elf.so.1 is wrong elf (it is 64 bit and not 32 bit).

A trick that works is to rename ld-elf32.so.1 into ld-elf.so.1 but then you will not be able to run 64 bit application anymore.

Fre;D

fredvs · Oct 10, 2016

marino@ said:
FPC might be missing writing key ELF information.

Yes, it could be the easier solution ---> it is not me, it is him.
I think that fpc is whiter than white in that story.

Fre;D

fredvs · Oct 10, 2016

ondra_knezour said:
https://lists.freebsd.org/pipermail/freebsd-questions/2016-September/273741.html

Ha, other sound of the bell ?

I prefer this one.

Question: What will append to wine (Windows emulator) if no more 32 bit libraries ?

Fre;D

ASX · Oct 10, 2016

fredvs said:
OK, but, please, do not persist to demonstrate that a no-smart-linked 32 bit program can be run on a multi-arch system.

Actually, the thread title is about FreeBSD multi-arch, nothing in your first post refer to FPC, except may be the word "smartlink".

My answer where about to demonstrate that FreeBSD multiarch is working despite a different filesystem structure and the ld-elf32.so placement doesn't prevent multiarch to work as expected.

It wasn't absolutely clear to me you were referring to a FPC issue, like emerged lately.

marino@ said:
Presumable one could review the kernel code to figure out how the kernel determines it's a 32-bit program and thus select the right rtld. FPC might be missing writing key ELF information.

It seems to me that your second sentence implicitly answer your doubts in the first sentence.

marino · Oct 10, 2016

fredvs said:
Yes, it could be the easier solution ---> it is not me, it is him.
I think that fpc is whiter than white in that story.

I am really having a hard time comprehending you. Can you remain with straight statements instead of metaphors?

I think you are upset that I think FPC is wrong here and you're saying we're brushing aside the problem. The fact is, FPC probably is wrong here. The solution would be the fix the FPC problem. If you don't like that, I'm sorry.

ljboiler · Oct 10, 2016

marino@ said:
I am really having a hard time comprehending you. Can you remain with straight statements instead of metaphors?

My guess is that it's the online translator fredvs uses that writes the metaphors, not Fred himself.

fredvs · Oct 11, 2016

> nothing in your first post refer to FPC, except may be the word "smartlink".

My first post:

fredvs said:
....
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

IMO, fpc is right and the FreeBSD multi-arch design with double-name in place of directory-search-path is wrong.
In My Opinion, of course.
And fpc will say to the FreeBSD-linker to follow your way, I do not have doubt about this .

Last thing, by the way, did you try to smart-link some of your programs (---gc-sections option)?
Smart-linking is done by the linker and the linker is the same for C or fpc ===> ld

If smart-link 32 bit works (out-of-the-box) for C programs in multi-arch FreeBSD, you win.

But, no, ok, I stop the fight.

Fre;D

[EDIT] Fixed ld -X option ==> ld --gc-sections

marino · Oct 11, 2016

fredvs said:
IMO, fpc is right and the FreeBSD multi-arch design with double-name in place of directory-search-path is wrong.
In My Opinion, of course.

Your understanding of the multi-arch functionality is wrong.
It has already been explained to you earlier. (see kernel, see ELF headers)

The multi-arch works and FPC is producing a bad library (apparently). Of course, that would be FPC's fault, it's the thing linking the program (with the help of ld according to you)

If smart-link 32 bit works (out-of-the-box) for C programs in multi-arch FreeBSD, you win.

This makes absolutely no sense. "smart-link" is a term for FPC. It's not a generic term. You can't "smart-link" a C-program.

You can compile C programs on FreeBSD32 and run them on FreeBSD amd64 without modification, which is what ASX@ confirmed earlier. So I guess that mean "we" win.

fredvs · Oct 11, 2016

marino@ said:
This makes absolutely no sense. "smart-link" is a term for FPC. It's not a generic term. You can't "smart-link" a C-program.

This is a option that you give to the linker.
And yes, you can "smart-link" a C program that uses ld linker.

http://sourceware.org/binutils/docs-2.16/ld/Options.html

fredvs · Oct 11, 2016

marino@ said:
You can compile C programs on FreeBSD32 and run them on FreeBSD amd64 without modification, which is what ASX@ confirmed earlier.

I knew that and it was not the subject of my first post.

But I said that I stop to fight so, have a good night.

Fre;D

marino · Oct 11, 2016

Code:

-X
--discard-locals
Delete all temporary local symbols. For most targets, this is all local symbols whose names begin with L.

That one?

from what I understand of FPC smart-link and this description, they are not the same thing, at all.

fredvs · Oct 11, 2016

marino@ said:
from what I understand of FPC smart-link and this description, they are not the same thing, at all.

Hum, from my earlier post:

fredvs said:
;-)
Here is the full description from the FPC Programmers Manual.
Same definition ca be used for smart-linking C programs.
http://www.freepascal.org/docs-html/current/prog/progsu118.html#x126-1270001.3.35

@marino, I like you but I would like you more if you buy new glasses.

marino · Oct 11, 2016

I read that link the first time. That has NOTHING to do with discarding local symbols, which has very little impact on final link size, especially when symbol maps are used.

Try to find somebody that agrees that smart-linking and -X are the same thing, I challenge you.

ASX · Oct 11, 2016

fredvs said:
IMO, fpc is right and the FreeBSD multi-arch design with double-name in place of directory-search-path is wrong.

I should have stopped here, really.

related to my request for an example of what is not working:

fredvs said:
For the example, it is for ALL the programs compiled and linked with smart-linking (with fpc ---> -XX parameter).

Code:

$ cat hello.pp
program hello;
begin
        writeln ('Hello world')
end.

default build:

Code:

$ fpc hello.pp
Free Pascal Compiler version 3.0.0 [2016/09/27] for x86_64
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: FreeBSD for x86-64
Compiling hello.pp
Linking hello
4 lines compiled, 0.5 sec
$ ls -l hello
-rwxr-xr-x  1 as  1001  204696 Oct 11 09:55 hello

smartlinked build:

Code:

$ fpc -XX hello.pp
Free Pascal Compiler version 3.0.0 [2016/09/27] for x86_64
Copyright (c) 1993-2015 by Florian Klaempfl and others
Target OS: FreeBSD for x86-64
Compiling hello.pp
Linking hello
4 lines compiled, 0.2 sec
$ ls -l hello
-rwxr-xr-x  1 as  1001  31032 Oct 11 09:55 hello

Both executable worked:
[CODE$ ./hello
Hello world][/CODE]

However they are identified slightly differently:

Code:

$ fpc hello.pp
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 10.1, stripped
$ fpc -XX hello.pp
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), statically linked, stripped

It is evident that using the -XX option, the executable is missing some information that instead is present in the default build, whether this is relevant or not remain to be seen.

Now it would be interesting to see the same results for an i386 build, apparently fpc need some add on to build different arch, which I was unable to locate, this is my first time with fpc.

fredvs, may be you can fill the gap ?

fredvs · Oct 11, 2016

ASX said:
It is evident that using the -XX option, the executable is missing some information that instead is present in the default build, whether this is relevant or not remain to be seen.

Now it would be interesting to see the same results for an i386 build, apparently fpc need some add on to build different arch, which I was unable to locate, this is my first time with fpc.

You will shout.

First you try demonstrate something with fpc 64 bit that has absolutely no problem, even smartlinked.

You just demonstrated here that fpc is NOT guilty.
fpc compiles and creates perfect objects, 100% FreeBSD compatible.

fpc uses to link their objects, ld, the linker from official FreeBSD package.

But ld (that comes from Linux) was not totally well adapted to FeeBSD, keeping some Linuxism (like that Linux-multiarch-architecture for -X parameter).

In place of trying to accuse fpc, you should thank him to have found a ld bug ---> ld -X (that can affect C programs too).

Fre;D

marino · Oct 11, 2016

You obviously didn't understand that he demonstrated that FPC produced a faulty executable [1].
-X is not equal to smart-link, no matter how many times you invent that fact.
ASX did what you did not: he produced a test case to prove his point. All we have is your inaccurate opinion on the matter.

By the way, do you realize that I'm on the fpc@freebsd.org team? One of two people that maintain FPC?

[1] Re-reading, he proved FPC with -XX executable has missing information. It's likely (not yet proven) that this missing information is preventing multi-arch from working.

fredvs · Oct 12, 2016

marino@ said:
You obviously didn't understand that he demonstrated that FPC produced a faulty executable [1].
-X is not equal to smart-link, no matter how many times you invent that fact.
ASX did what you did not: he produced a test case to prove his point. All we have is your inaccurate opinion on the matter.

By the way, do you realize that I'm on the fpc@freebsd.org team? One of two people that maintain FPC?

[1] Re-reading, he proved FPC with -XX executable has missing information. It's likely (not yet proven) that this missing information is preventing multi-arch from working.

Promise, it is my last post on this forum.

OK, I recognize one mistake.

-XX fpc parameter (smartlink) sent --gc-sections option to ld (and not -X, like I writed before).

But I maintain that this --gc-sections option of ld produce bad link and this for all the compilers that use ld in FreeBSD 32 bit.

Re-reading, he proved FPC with -XX executable has missing information. It's likely (not yet proven) that this missing information is preventing multi-arch from working.

Yes, he prove something about fpc 64 bit that everybody knows.
The subject here was smart-linked 32 bit apps in FreeBSB 64 bit multi-arch.

All what you and him really prove, is that you do not have any multi-arch FreeBSD for testing.

You shout loud, that is true and your (pseudo) knowledge does not impress me.

Last thing. What you have done with fpc-pkg is making only one thing: fpc unusable.
Same for the pkg Lazarus : unusable.

And bye, I go back in my little opened world.

Fre;D

ASX · Oct 12, 2016

fredvs said:
OK, I recognize one mistake.

That would have been a good start ...

All what you and him really prove, is that you do not have any multi-arch FreeBSD for testing.

By any chance are you implying we are not using "polydev" ?

You shout loud, that is true and your (pseudo) knowledge does not impress me.

Last thing. What you have done with fpc-pkg is making only one thing: fpc unusable.
Same for the pkg Lazarus : unusable.

What is impressive here is something else ...

About FreeBSD multi-arch.

fredvs

ASX

Guest

fredvs

marino

ondra_knezour

ASX

Guest

marino

fredvs

fredvs

fredvs

ASX

Guest

marino

ljboiler

fredvs

marino

fredvs

fredvs

marino

fredvs

marino

ASX

Guest

fredvs

marino

fredvs

ASX

Guest