Hello.

I will try to explain the problem...

In a multi-arch system (64 bit system that can run 32 bit apps too) FreeBSD 64, there is problem if a fpc 32 bit application was compiled with smart link (-XX).

This because FreeBSD call *ld-elf32.so.1* for 32 bit applications, in place of *ld-elf.so.1* in his multi-arch sytsem.

On mono-arch system (32 bit or 64 bit), FreeBSD call ld-elf.so.1 (that for 32 or 64 bit).

So, to resume, with smart link (-XX) in a 32 bit FreeBSD app, the link would search first for *ld-elf32.so.1* and if not exist, search for * ld-elf.so.1*.

And it is not the case, with -XX, the program search only for *ld-elf.so.1*, even if it is on a multi-arch system.

Hope somebody has understood.

Thanks.

Fre;D

-----
Many thanks ;-)

fredvs wrote

Hope somebody has understood.

I didn't actually see a question in your post. Are you saying FPC is at fault or 64-bit FreeBSD is at fault? If the latter, I would raise the issue in their web forums.

I would have expected a 64-bit FreeBSD system to have different search paths, but consistent library naming. For example (this is just an example, I don't know if this really exists):

/compat/linux/lib <---|
/compat/linux/user/lib/ <---+- denotes 32-bit by default (could be other way round too)
/compat/linux/lib64/
/usr/local/lib/ <-- denotes 64-bit on 64-bit FreeBSD OS. /usr/local/lib32/ <-- 32-bit FreeBSD libraries

Regards,
Graeme

Hello Graeme.

Thanks for answer.

I do not know who is the guilty...

In FreeBSD 64 multi-arch all the libraries 64 bit are in /lib/ or /usr/lib/ or /usr/local/lib
and all 32 bit libraries are in /usr/lib32 or /usr/local/lib32.

But for ld-elf*.so both ld-elf.so and ld-elf32.so are in same directory /libexec/.

I have try to put ld-elf32.so in /usr/lib32 or /usr/local/lib32 but it does not work.

It is clear that the smart link links to the wrong ld-elf but I do not know who or what is the cause.

It seems to me that fpc is not 100 % white in that history.

Fre;D

-----
Many thanks ;-)

Re-hello.

Note that in FreeBSD 64 multi-arch, the Linuxator is working perfectly, for Linux 64 and Linux 32, even with smart-linking 32 bit too.

Fre;D

-----
Many thanks ;-)

Hello.

Once again (like always) fpc is whiter than white.

FreeBSD has decided to stop FreeBSD 32 bit and that smart-link problem is known but they do not want to fix it because of stopping FreeBSD 32 bit development.

It is extremely sad and I do not understand why to stop 32 bit development.

Fre;D

-----
Many thanks ;-)

fredvs wrote

It is extremely sad and I do not understand why to stop 32 bit development.

But they just recently added support for RaspberryPi. Does that mean FreeBSD on RaspberryPi will now also discontinue? If so, there goes my idea of using RPi's as small stand-alone servers. :-/

Regards,
Graeme

Am 07.10.2016 17:19 schrieb "Graeme Geldenhuys" <

: On 2016-10-07 14:38, fredvs wrote: > It is extremely sad and I do not understand why to stop 32 bit

development.

But they just recently added support for RaspberryPi. Does that mean FreeBSD on RaspberryPi will now also discontinue? If so, there goes my idea of using RPi's as small stand-alone servers. :-/

Probably they merely want to kick out x86 32-bit support.

Regards,
Sven

In our previous episode, Graeme Geldenhuys said:

But they just recently added support for RaspberryPi. Does that mean FreeBSD on RaspberryPi will now also discontinue? If so, there goes my idea of using RPi's as small stand-alone servers. :-/

Well, that would probably only involve current, and stable branches would cover existing targets for several years. Fred's post seems to mainly be about biarchs though, and that is a completely different story.

Fred's post seems to mainly

Marco van de Voort wrote

Fred's post seems to mainly be about biarchs though, and that is a completely different story.

Sadly no.
No more biarch because no more FreeBSD32.

Fre;D

-----
Many thanks ;-)

Graeme Geldenhuys wrote

there goes my idea of using RPi's as small stand-alone servers. :-/

Pi 3 does feature a 64 Bit CPU. (AFAIK, no 64 Bit Linux for same, yet. BSD: no idea)

-Michael

fredvs wrote

FreeBSD has decided to stop FreeBSD 32 bit

I just saw the FreeBSD 11.0 release announcement. In the "Availability" list, i386 is still mentioned.

https://www.freebsd.org/releases/11.0R/announce.html

Regards,
Graeme

Thanks Graeme.

To know what is sent to the linker, there is the -s parameter.

# fpc -XX -s test.pas

This will compile the object and create a script file for the linker. Here the script with -XX parameter:

/usr/bin/ld -b elf32-i386-freebsd -m elf_i386_fbsd *--gc-sections* -s -L. -0 ./test ./link.res

If seems to me then that *--gc-sections* has to do with smart-link too.

From site https://sourceware.org/binutils/docs/ld/Options.html:

--gc-sections
--no-gc-sections
Enable garbage collection of unused input sections. It is ignored on targets that do not support this option. The default behaviour (of not performing this garbage collection) can be restored by specifying `--no-gc-sections' on the command line. Note that garbage collection for COFF and PE format targets is supported, but the implementation is currently considered to be experimental.
`--gc-sections' decides which input sections are used by examining symbols and relocations. The section containing the entry symbol and all sections containing symbols undefined on the command-line will be kept, as will sections containing symbols referenced by dynamic objects. Note that when building shared libraries, the linker must assume that any visible symbol is referenced. Once this initial set of sections has been determined, the linker recursively marks as used any section referenced by their relocations. See `--entry' and `--undefined'.

This option can be set when doing a partial link (enabled with option `-r'). In this case the root of symbols kept must be explicitly specified either by an `--entry' or `--undefined' option or by a ENTRY command in the linker script.

___________________

There, in FreeBSD forum, they do not agree.

https://forums.freebsd.org/threads/57931/page-3

Fre;D

-----
Many thanks ;-)

I feel so lonely.

Nobody in the world to confirm (or not) that *--gc-sections* option is added to ld when -XX is used ?

Did I do something wrong against fpc community ?

If yes I apologize a lot and a lot and a lot.

Fre;D

-----
Many thanks ;-)

fredvs wrote

I feel so lonely.

I'm told this can help: http://www.tinder.com

No, simply probably no-one knows the answer or the few knowledgable people didn't see your message.

Michael.

Thanks Michael.

No, simply probably no-one knows the answer or the few knowledgable people didn't see your message.

OK I agree the problem is complicated it is the reason why I ask this to fpc
+ freebsd forum.

But here I ask something simple : What option is added to linker when -XX parameter is used?

If you do:

fpc -s -XX test.pas, in the ppas.sh produced, *--gc-sections* option is added to ld option.

So it seems that garbage collection must be enabled to do a smartlink.

And if this is right, using garbage collection in FreeBSD 32 bit produce code not usable in Multi-arch.

There in FreeBSD forum, they cannot admit that fpc uses *--gc-sections* option in ld when fpc -XX is used.

Fre;D

-----
Many thanks ;-)

fredvs wrote

So it seems that garbage collection must be enabled to do a smartlink.

I'm not sure I follow you. From what I understand from the FPC documentation, is that FPC (when smartlinking is enabled) generates multiple object files per unit, trying to make a object file per procedure.

It is then the linkers job to link only the object files that are needed (and really used in the application) to make the executable. How the linker does that is beyond my knowledge.

There in FreeBSD forum, they cannot admit that fpc uses *--gc-sections* option in ld when fpc -XX is used.

I guess showing them the content of the ppas.sh file is all that they should need as proof. The alternative (if you know exactly what the problem is), is to modify the ld linker yourself and see if it then works on your system. If so, send them a patch.

Some developers are harder to convince about potential problems or bugs. The FreeBSD developers are definitely not the only ones.

Regards,
Graeme

Yeh, the cavalry finally arrives, I am saved. ;-)

it is then the linkers job to link only the object files that are needed (and really used in the application) to make the executable.

Yes, yes, yes and re-yes.

I guess showing them the content of the ppas.sh file is all that they should need as proof.

Huh, it is already one week (7 days) that I repeat it on each answer.

Some developers are harder to convince about potential problems or bugs.

Yes but here it is different. Did you see that they do not want that I answer any more?

Sincerely, if it was for one of my project, I never will fight and accept to be insulted in each of their answer, this more than a week.

But here it is about the honor of fpc who was accused to produce bad code.

The alternative (if you know exactly what the problem is), is to modify the ld linker yourself and see if it then works on your system.

Yep or prove that a gcc or clang or llvm compiler that use ld + --gc-sections produce binary not usable in multi-arch.

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

Thanks Graeme, I was beginning to think that I was in a nightmare without
end.

Fre;D

-----
Many thanks ;-)

fredvs wrote

In a multi-arch system (64 bit system that can run 32 bit apps too) FreeBSD 64, there is problem if a fpc 32 bit application was compiled with smart link (-XX).

Just curious. If you don't compile with Smart-Linking enabled, does your binary then run fine?

Is only Smart-Linking causing the problem?

Regards,
Graeme

Doesn't it use function-sections nowadays?

Martin

procedure.

> Doesn't it use function-sections nowadays?

It depends on the target. Most targets indeed used section based smartlinking while AFAIK targets like go32v2 use the file based approach.

Regards,
Sven

Just curious. If you don't compile with Smart-Linking enabled, does your

binary then run fine?

Yes, without Smart-linking, a 32 bit fpc application runs fine in a multi-arch 64 bit system.

With Smart-linking a 32 bit application runs fine only in a mono-arch 32 bit.

Fred.

-----
Many thanks ;-)

Oops, I did not see this...

Is only Smart-Linking causing the problem?

Yes,,,, I agree it is only a detail, all the rest is working perfectly.

And I will survive, even with smart-link 32 bit not working in one of my system. ;-)

Thanks a lot for helping.

@fpc-team: Why not register the concept of "smart-linking", nobody knows that word in other language.
IMO, it would be good to add in wikipedia a article about "smartlink" and not forget to say that the concept of "smart-linking" comes from fpc.

Fre;D

-----
Many thanks ;-)

fredvs wrote

@fpc-team: Why not register the concept of "smart-linking", nobody knows that word in other language. IMO, it would be good to add in wikipedia a article about "smartlink" and not forget to say that the concept of "smart-linking" comes from fpc.

it does not... smart linking originated with the TopSpeed team which Borland picked up many years back... sadly, they later let the TopSpeed team go but smartlinking originated way back long ago...

Well, it does not come from FPC, in fact the Borland compiler back to at least Turbo/Borland Pascal 7.0 supported that feature. (Don't know if Turbo Pascal 6.0 might have already supported it because I skipped it "back then" and went from 5.5 straight to 7.0...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Umm, that is very weird.

Maybe if you supply two small binaries, each with their ppas.sh script and accompanied *.o and *.a files, then maybe the clever developers of FreeBSD's ld linker can figure out what is the difference (causing the issue)?

Regards,
Graeme

Maybe if you supply two small binaries

Maybe or, better, supply two clean new glasses to those two "developers".

Sorry Graeme but I am tired to fight.

The honor of fpc is saved, the problem is or *ld* or FreeBSD multi-arch design.

Many thanks Graeme for your opened mind and your impressing clarity.

Fre;D

-----
Many thanks ;-)

fredvs wrote

Many thanks Graeme for your opened mind and your impressing clarity.

Tell that to my wife.... she would disagree! ;-)

Regards,
Graeme

In our previous episode, fredvs said:

Do you see differences between ppas.sh and link.res with and without smartlinking ohter than --gc-sections?

If you compile without smartlinking but with -s and add --gc-sections to the ppas.sh file yourself, what happens then?

(rationale: maybe smartlinking taking a different path in t_bsd, finding a different ELF interpreter, linking C etc?)

Does it matter if you import unit "cmem" into your test program?

Hello Marco.

Huh, I decided to forget FreeBSD but ok I will re-install it and test your propositions.

Write you later.

Fre;D

-----
Many thanks ;-)

fredvs wrote

Huh, I decided to forget FreeBSD...

NNNNNNOOOOOOOOOooooooo! ;-)

Regards,
Graeme

Hello Marco.

Do you see differences between ppas.sh and link.res with and without smartlinking ohter than --gc-sections?

For link.res => no differences.
For ppas.sh => only "--gc-section" was added.

If you compile without smartlinking but with -s and add --gc-sections to the ppas.sh file yourself, what happens then?

1) Compiling => ok, objects created.
2) Linking: after adding--gc-sections to the ppas.sh, I did:

# cd /usr/test
# sh ppas.sh

=> "Linking ./test

# ./test

=> "ELF interpreter /usr/libexec/ld-elf.so.1 not found, error 8

Does it matter if you import unit "cmem" into your test program?

uses
cmem, cthreads, classes;

Compiling and linking with --gc-sections: ok.

# ./test

=> "ELF interpreter /usr/libexec/ld-elf.so.1 not found, error 8

-------------------------

Checkmate ;-)

Fre;D

-----
Many thanks ;-)