# About FreeBSD multi-arch.



## fredvs (Oct 4, 2016)

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


----------



## fredvs (Oct 6, 2016)

Hello.

No comment ?

Fre;D


----------



## ljboiler (Oct 6, 2016)

What is "smart link", please?


----------



## Remington (Oct 6, 2016)

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.


----------



## kpa (Oct 6, 2016)

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.


----------



## fredvs (Oct 7, 2016)

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.



That is extremely sad.

Fre;D


----------



## fredvs (Oct 7, 2016)

kpa said:


> since support for i386 is waning already


That is extremely sad.

Fre;D


----------



## Remington (Oct 7, 2016)

Any particular reasons why you need lib32?


----------



## fredvs (Oct 7, 2016)

Remington said:


> That will require re-working FreeBSD to include both 32 and 64


Yes and it is done in polYdev (https://forums.freebsd.org/threads/53085/).

Fre;D


----------



## fredvs (Oct 7, 2016)

Remington said:


> Any particular reasons why you need lib32?


polYdev, the multi-arch, multi-os operating system.

Fre;D


----------



## Remington (Oct 7, 2016)

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@.


----------



## fredvs (Oct 7, 2016)

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@.


It would be a honor and I would do it with great pleasure (it FreeBSD maintains to still develop FreeBSD32, of course).

Fre;D


----------



## SirDice (Oct 7, 2016)

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.





> 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.


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.


----------



## Remington (Oct 7, 2016)

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.


----------



## Remington (Oct 7, 2016)

Would it be possible to become a lib32 port committer and create /usr/local/lib32 instead of messing around with the base system?


----------



## kpa (Oct 7, 2016)

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?



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.


----------



## fredvs (Oct 7, 2016)

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
> ...



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

Fre;D


----------



## fossette (Oct 8, 2016)

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.


----------



## fredvs (Oct 8, 2016)

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.


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 (Oct 8, 2016)

fredvs said:


> Sorry but the only real multi-arch design is the one used by other Unix system (Huh, yes , like Linux).



https://www.perkin.org.uk/posts/multiarch-package-support-in-smartos.html


> Ever since the release of Solaris 7 back in 1998, Solaris has had the ability to run both 32-bit and 64-bit binaries on the same machine. Even now, 15 years later, with much of the world 64-bit only, there are still reasons to retain 32-bit support: ...


----------



## fredvs (Oct 9, 2016)

marino@ said:


> https://www.perkin.org.uk/posts/multiarch-package-support-in-smartos.html


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


----------



## marino (Oct 9, 2016)

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)


----------



## Phishfry (Oct 9, 2016)

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.


----------



## marino (Oct 9, 2016)

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.



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.


----------



## ANOKNUSA (Oct 9, 2016)

ljboiler said:


> What is "smart link", please?



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.





Phishfry said:


> Arm 32 bit builds(armv6) are different than an i386 build.



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?


----------



## 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 ?


```
#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:


```
$ 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:

```
% 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

```
$ 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:

```
# ./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
> ...



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)

```
-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).




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

default build:

```
$ 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:

```
$ 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:

```
$ 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.
> 
> ...


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 ...


----------



## marino (Oct 12, 2016)

ASX@
--gc-sections isn't equivalent to "smart-linking" either.  I don't know fredvs is thinking here.  I guess he's just looking for descriptions in the man page that sort of, kind of sound like it's the same thing.

I cease to care though.  He's speaking with the _disdainful _authority of an expert while having no idea of what he's talking about.  It's  a bad combination.

I would have been interested in helping to identify and fix the smart link problem, perhaps with the help of the FPC developers, but not anymore.  I'll just wait for a patch (and ignore the cracks about FPC packages being "unusable" without any evidence nor PRs written against them)


----------



## ASX (Oct 12, 2016)

marino@  Thanks, I know what is "garbage collection" and that it is totally out of context, and it is part of the reasons why in my previous message I deliberately choose to not discuss technical aspects.



marino@ said:


> I would have been interested in helping to identify and fix the smart link problem



Yes, that was very clear, to me at least.


----------



## fredvs (Oct 13, 2016)

marino@ said:


> ASX@
> --gc-sections isn't equivalent to "smart-linking" either.



fpc -XX -s test.pas => (parameter -s makes a script for ld) =>`/usr/bin/ld -b elf32-i386-freebsd -m elf_i386_fbsd [U]--gc-sections[/U] -s -L. -0 ./test ./link.res`



marino@ said:


> ASX@
> I would have been interested in helping to identify and fix the smart link problem



No, the only thing you want was to prove that I was wrong.
And I am not, ld has a problem with --gc-sections .

Fre;D


----------



## ASX (Oct 13, 2016)

fredvs said:


> No, the only thing you want was to prove that I was wrong.


 Please, this is not going to help you in any way.
Luckily enough this is a *public* forum, with enough competent people to judge about.


----------



## fredvs (Oct 15, 2016)

ASX said:


> Luckily enough this is a *public* forum, with enough competent people to judge about.



=> https://forums.freebsd.org/threads/58060/


----------



## ASX (Oct 15, 2016)

fredvs said:


> => https://forums.freebsd.org/threads/58060/


So what ? What has that to do with your comment about marino@ intentions ?

By the way, because it seems you don't get it, FPC smartlinking is applied upon sources at compile stage, not at linking stage.

From the docs you linked before:
http://www.freepascal.org/docs-html/current/prog/progse30.html#x196-2010007.3

"Technically speaking, the *compiler* makes small assembler files *for each procedure and function* in the unit, as well as for all global defined variables (whether they’re in the interface section or not). It then assembles all these small files, and uses ar to collect the resulting object files in one archive."

It is also implied, that "smartlinking" refer to static-linking:
"Smartlinking and the creation of shared (or dynamic) libraries are mutually exclusive"

The ld --gc-sections flags has nothing to do with FPC smartlinking, nor exists a concept like "C program smartlinking", no matter how many time you write that.


----------



## fredvs (Oct 16, 2016)

ASX said:


> So what ? What has that to do with your comment about marino@ intentions ?
> 
> By the way, because it seems you don't get it, FPC smartlinking is applied upon sources at compile stage, not at linking stage.
> 
> ...



I am really tired.

Please, read what follow slowly.

`fpc -XX` (smart-linking) does what you explained but to do this, that *-XX *parameter also add `--gc-sections` option to the linker.

You may check it easily with the *-s* parameter of `fpc`.

It will create a ppas.sh file that you may use for the linker:

`fpc -XX -s test.pas` ==> ppas.sh ==>


```
#!/bin/sh
DoExitAsm ()
{ echo "An error occurred while assembling $1"; exit 1; }
DoExitLink ()
{ echo "An error occurred while linking $1"; exit 1; }
echo Linking ./test
OFS=$IFS
IFS="
"
/usr/bin/ld -b elf32-i386-freebsd -m elf_i386_fbsd --gc-sections -s -L. -o ./test ./link.res
if [ $? != 0 ]; then DoExitLink ./test; fi
IFS=$OFS
```

From the script:

`/usr/bin/ld -b elf32-i386-freebsd -m elf_i386_fbsd [B]--gc-sections[/B] -s -L. -o ./test ./link.res`

This because garbage collection must be enabled to do smartlinking.

One of the result of smartlinking (and it is mainly what wanted) is to (from doc) "This will result in a smaller binary".

All I want to prove is that `--gc-sections` option parsed to ld when smartlinking cause that a 32 bit application cannot run on a multi-arch system.

Please, we are no ennemies.

Fre;D


----------



## marino (Oct 16, 2016)

fredvs said:


> I am really tired.
> 
> Please, read what follow slowly.





> Please, we are no ennemies.



You say you "aren't enemies" but you're speaking in an insulting, condescending tone.

It doesn't matter if your understanding of how --gc-sections is lacking, because if ASX@ is like me, he's "tired" of this topic too.
You said you were not going to reply any more.  We've tried different approaches but you don't accept any of them, so that's fine, just let it die.  You can continue to believe we are all morons, that's fine with us.


----------



## fredvs (Oct 16, 2016)

marino@ said:


> but you're speaking in an insulting, condescending tone.



I apologize, really it is not wanted.
I seems like this maybe because I speak French.

OK, to let die the problem.

PS: But I will fix the `--gc-sections` problem of ld 32 bit for my own purpose then.

Fre;D


----------

