Difference between revisions of "FreeBSD"

From Free Pascal wiki
Jump to navigationJump to search
(FreeBSD page created)
 
(47 intermediate revisions by 10 users not shown)
Line 1: Line 1:
= FREEBSD bleeding edge notes =
+
= FreeBSD bleeding edge notes =
  
 
This page is mainly a scratchpad where I will try to keep FreeBSD specific  
 
This page is mainly a scratchpad where I will try to keep FreeBSD specific  
issues noted. Some of them may apply to NetBSD/OpenBSD too, an also Darwin is sharing a lot of the generic BSD.
+
issues noted. Some of them may apply to NetBSD/OpenBSD, too. Darwin is also sharing a lot of the generic BSD.
  
 
FreeBSD is the most mature of the BSD ports, though Darwin is rapidly catching up.  
 
FreeBSD is the most mature of the BSD ports, though Darwin is rapidly catching up.  
  
== FreeBSD 5.x ==
+
== Supported FreeBSD versions (11.x..12.x)  ==
  
While afaik not available publically ( mailed the script to the lang/fpc porter), there is some support for FreeBSD 5.x now. (5.x means 5.2 and later, 5.0, 5.1)
+
FreeBSD is currently targeted at versions 11.x .. 12.x.
  
Actually there are two changes for 5.x:
+
=== Required kernel options for non GENERIC kernels ===
* the startup code is different due to the addition of an ABI tag, and
 
* (after 5.2) libkse becomes the new scheduler in 5-CURRENT.
 
  
I'll try to keep 4.x working till my provider, Stack doesn't use 4.x anymore on
+
The FreeBSD pkg installation and compilation from /usr/ports both include FPC compiler binaries which core dump on FreeBSD 11.2, 11.3 and 12.0 as follows:
its shell machines.
 
  
=== 5.x startup code ===
+
<syntaxhighlight lang="bash">
The first can be fixed for 1.0.10 (lang/fpc port) by running
+
$ truss ./work/ppcx64-3.0.4-freebsd
[http://www.stack.nl/~marcov/fixfpc this shell script] if you have 5.x, which takes the prefix where FPC is installed as optional parameter. (tested on 5.2)
+
sigaction(SIGFPE,{ 0x4224f0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
 +
sigaction(SIGSEGV,{ 0x4224f0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
 +
sigaction(SIGBUS,{ 0x4224f0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
 +
sigaction(SIGILL,{ 0x4224f0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
 +
ioctl(1,TIOCGETA,0x7fffffffe4a0)        = 0 (0x0)
 +
ioctl(2,TIOCGETA,0x7fffffffe4a0)        = 0 (0x0)
 +
ioctl(1,TIOCGETA,0x7fffffffe4a0)        = 0 (0x0)
 +
ioctl(2,TIOCGETA,0x7fffffffe4a0)        = 0 (0x0)
 +
compat6.mmap()                           ERR#78 'Function not implemented'
 +
SIGNAL 12 (SIGSYS) code=SI_KERNEL
 +
process killed, signal = 12 (core dumped)
 +
</syntaxhighlight>
  
There is no such script for 1.9.x yet, but creating it should not be hard, and I hope to have it running with 1.9.4, maybe even integrate it into the makefiles
+
'''Solution'''
  
=== libkse/libpthreads ===
+
Use a GENERIC kernel, or for FreeBSD 11.x ensure the following kernel options are uncommented in your KERNCONF file:
  
The second is only fixed in CVS (and therefore will only be available in 1.9.4 and later). This functionality is barely tested though, but adding parameter -Xf to the commandline of the compiler (when linking) or to fpc.cfg should use libpthreads instead of libc_r.
+
options      COMPAT_FREEBSD6        # Compatible with FreeBSD6
 +
options      COMPAT_FREEBSD7        # Compatible with FreeBSD7
 +
options      COMPAT_FREEBSD10        # Compatible with FreeBSD10
  
For this to work there must be at least one header set that has
+
''Note 1: COMPAT_FREEBSD7 was necessary otherwise the kernel would fail to build once COMPAT_FREEBSD6 was included.''
{$linklib c}
+
''Note 2: COMPAT_FREEBSD11 is also be required for FreeBSD 12.0.''
{$linklib pthreads}
 
  
and there should be no direct use of {$linklib c_r} anymore, the compiler
+
It seems the FPC binaries are calling some very old FreeBSD system calls dating back some 14 years.
transforms the library list automatically depending on -Xf.
 
  
The best way to this is by simply use "USES systhrds"
+
=== FPC 3.3.1 (trunk) ===
 +
 
 +
FreeBSD 12.0 is unable to compile the source for FPC 3.3.1.
 +
 
 +
'''Solution'''
 +
 
 +
The workaround is to install a trunk snapshot from ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/ and install it over the existing FPC 3.0.4 (sort of - I kept the sources and lib directories separate, but mostly overwrote the /usr/local/bin files only saving a few by soft linking eg, ln -s /usr/local/lib/fpc/3.3.1/ppcx64 /usr/local/bin/ppcx64).
  
 
== Ports tree ==
 
== Ports tree ==
  
FPC is currently available in both flavours in the ports tree
+
FPC is currently available as 3.0.4 in the ports tree, maintained by Alonso Cárdenas Márquez (acm@FreeBSD.org).
 +
 
 +
== Official FPC Installer ==
 +
Although the ports collection is brilliant, there are alternative methods of installing FPC too - installing from the official *.tar release packages.
 +
# Downloading the official *.tar release from [http://sourceforge.net/projects/freepascal/files/FreeBSD/ SourceForge.net]
 +
# Unpack the .tar package into a temporary directory
 +
#:<pre>tar xvf fpc-3.0.0.x86_64-freebsd10.tar</pre>
 +
# Run the setup program
 +
#:<pre>./install.sh</pre>
 +
# Follow the on-screen prompts
 +
 
 +
== Building FPC Trunk ==
 +
# Get the Trunk source code from SubVersion or the [[git_mirrors | Git mirrors]].
 +
# Make sure you have a fully working '''latest released FPC version''' installed. It is this compiler that will initially compile the Trunk FPC.
 +
# <pre>gmake build OPT="-Fl/usr/local/lib"</pre>
 +
# <pre>gmake install INSTALL_PREFIX=/data/devel/fpc-3.1.0/x86_64-freebsd FPC=/data/devel/fpc-3.1.0/src/compiler/ppcx64</pre>
 +
 
 +
'''Note:''' In the last command you reference the newly built compiler via the FPC= parameter.
 +
 
 +
== Issues ==
 +
 
 +
* gdb. After installing FreeBSD 10 and FPC, I found gdb version was 6.1.1. This will be found by Lazarus on first run as /usr/bin/gdb and it will make debugging impossible (at least with Lazarus 1.2.x and 1.3). The fix is to Install the latests gdb version by doing pkg install devel/gdb (mine complained that the latest gdb version (7.7.1) was already installed), the remedy is modifying the used debugger in Lazarus menu Tools->Options->Debugger, select from the list /usr/local/bin/gdb
 +
* make. On the first run Lazarus will find /usr/bin/make or simply make as the 'make' command. It will not work, install gmake (pkg install gmake) and change it in Lazarus menu Tools->Options->Environment->Files->Make path.
 +
* Remember that under FreeBSD, /home is a link to /usr/home, it is relevant when installing lazarus using pkg install lazarus, by default it will use a primary config path in /home/user/.lazarus but then at some point it starts mixing it as /usr/home/user/.lazarus which appears to cause problems on installing packages and rebuilding lazarus as a normal user, although this needs to be confirmed.
 +
 
 +
= Older versions of FPC and FreeBSD =
 +
== Support for older versions ==
 +
4.x is formally no longer supported, but the old code pretty much stayed put, the defaults just changed. The differences are pretty much startup code, threading, and some code under ifdef FREEBSD5:    (note, the best chance for this to work is with the code of 2.2.2)
 +
 
 +
* 4.x has other startup code than 7.x, get the old .as files from 2.0.0 or 2.0.2 (or from similar versions svn).  (I don't really remember what was different about them. It could only be the ABI number in the ELF ident), assemble them, and copy them over the existing ones.
 +
* Now bootstrap the compiler using OPT="-dFREEBSD4 -Xf"
 +
* copy sources + bootstrapped (static) compiler to 4.x
 +
* Bootstrap system (again with patched startup code and OPT="-Xf -dFREEBSD4"
  
* John Merryweather-Cooper maintains an independant 1.0.10 port as lang/fpc which was originally based on the binary 1.0. .tar.gz, but seems to be changing to source builder using lots of different modules right now.
+
Write your experiences here under this paragraph since this is all just theory till now. I do not have a fbsd4 to actually try anymore.
[http://www.freebsd.org/cgi/query-pr-summary.cgi?category=&severity=&priority=&class=&state=&sort=none&text=fpc&responsible=&multitext=&originator=&release= see here for current FPC ports/ PR status]
 
* I myself maintain the lang/fpc-devel port, which is a source based bootstrapping system for the 1.9.x series. (currently 1.9.2).  
 
  
The FPC 1.0/freebsd branch is considered legacy since I do all of the FreeBSD development, and have been working on 1.9 nearly exclusively since early 2003.
+
== COMPAT_ requirement of the port==
 +
I haven't really researched the issue, but somehow the port maintainers added a dependancy to COMPAT_5, probably because the source default puts the .note in cprt0.as to 504000 or so. This can be easily remedied by patching the cprt0.as file before building, and put the output of
  
Moreover 1.0.10 is probably is the last release of the 1.0 branch, though maybe there will be some additional releases for the m68k and other non-core platforms that haven't been ported to 1.9.x yet.
+
elfdump -n `which elfdump` |awk '/FreeBSD/{print $2}'
  
So 1.0 is considered legacy, and I advise people to use the 1.9 series as much as possible. While officially a beta, 1.9.x is except some crashes on faulty code occasionally in general a compiler in better shape. The same goes for the 1.9.x rtl.
+
in the .long line  AFTER a .string "FreeBSD" line in cprt0.as.
 +
 
 +
A script has been added to -trunk (fpc/rtl/freebsd/i386/identpatch.sh) that does this. If you have improvements, please communicate them back (''to where?'').
 +
 
 +
Note: The COMPAT_ dependency was removed with version 2.2.4 of freepascal, and the value of .long line into cprt0.as file is changed to ${OSVERSION} automatically.
 +
 
 +
See about ${OSVERSION} at:
 +
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-after-port-mk.html
  
When when critical problems arrive, I'm willing to make patches for 1.0.x, but I won't do any release engineering for a new 1.0.x releases anymore, let alone
 
official ports tree entries.
 
  
 
== FPC_USE_LIBC ==
 
== FPC_USE_LIBC ==
 +
Since jan 2004, most Unix ports of FPC can be recompiled with FPC_USE_LIBC, and in those cases the RTL will use libc functions as much as possible. This was mainly introduced for the Darwin port, and may also be used for e.g. Lazarus distributions. (Lazarus links its apps to libc anyway, because of gtk)
  
Since jan 2004, most Unix ports of FPC can be recompiled with FPC_USE_LIBC, and in those cases the RTL will use libc functions as much as possible. This was mainly introduced for the Darwin port, and may also be used for e.g. Lazarus distributions. (Lazarus links its apps to libc anyway, because of gtk)
 
  
 
== Unix RTL, 1.0.x/1.9.x RTL compability ==
 
== Unix RTL, 1.0.x/1.9.x RTL compability ==
 
 
The 1.0.x rtl was essentially a linux only hackish rtl. The rtl was rewritten in
 
The 1.0.x rtl was essentially a linux only hackish rtl. The rtl was rewritten in
version 1.9.x (and this still continues), and unfortunately, compatibility had to be broken.
+
version 1.9.x/2.x (and this still continues), and unfortunately, compatibility had to be broken.
  
 
For reasons and discussion, see [http://www.stack.nl/~marcov/unixrtl.pdf Unix Rtl Doc]
 
For reasons and discussion, see [http://www.stack.nl/~marcov/unixrtl.pdf Unix Rtl Doc]
 +
 +
= See also =
 +
*[[Portal:FreeBSD|FreeBSD Portal]]
 +
*[[FreeBSD specific Release Engineering]]
 +
 +
[[Category:Unix]]
 +
[[Category:FPC]]
 +
[[Category:FreeBSD]]
 +
[[Category:BSD]]

Revision as of 15:44, 26 January 2020

FreeBSD bleeding edge notes

This page is mainly a scratchpad where I will try to keep FreeBSD specific issues noted. Some of them may apply to NetBSD/OpenBSD, too. Darwin is also sharing a lot of the generic BSD.

FreeBSD is the most mature of the BSD ports, though Darwin is rapidly catching up.

Supported FreeBSD versions (11.x..12.x)

FreeBSD is currently targeted at versions 11.x .. 12.x.

Required kernel options for non GENERIC kernels

The FreeBSD pkg installation and compilation from /usr/ports both include FPC compiler binaries which core dump on FreeBSD 11.2, 11.3 and 12.0 as follows:

$ truss ./work/ppcx64-3.0.4-freebsd
sigaction(SIGFPE,{ 0x4224f0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
sigaction(SIGSEGV,{ 0x4224f0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
sigaction(SIGBUS,{ 0x4224f0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
sigaction(SIGILL,{ 0x4224f0 SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
ioctl(1,TIOCGETA,0x7fffffffe4a0)         = 0 (0x0)
ioctl(2,TIOCGETA,0x7fffffffe4a0)         = 0 (0x0)
ioctl(1,TIOCGETA,0x7fffffffe4a0)         = 0 (0x0)
ioctl(2,TIOCGETA,0x7fffffffe4a0)         = 0 (0x0)
compat6.mmap()                           ERR#78 'Function not implemented'
SIGNAL 12 (SIGSYS) code=SI_KERNEL
process killed, signal = 12 (core dumped)

Solution

Use a GENERIC kernel, or for FreeBSD 11.x ensure the following kernel options are uncommented in your KERNCONF file:

options       COMPAT_FREEBSD6         # Compatible with FreeBSD6
options       COMPAT_FREEBSD7         # Compatible with FreeBSD7
options       COMPAT_FREEBSD10        # Compatible with FreeBSD10
Note 1: COMPAT_FREEBSD7 was necessary otherwise the kernel would fail to build once COMPAT_FREEBSD6 was included.
Note 2: COMPAT_FREEBSD11 is also be required for FreeBSD 12.0.

It seems the FPC binaries are calling some very old FreeBSD system calls dating back some 14 years.

FPC 3.3.1 (trunk)

FreeBSD 12.0 is unable to compile the source for FPC 3.3.1.

Solution

The workaround is to install a trunk snapshot from ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/ and install it over the existing FPC 3.0.4 (sort of - I kept the sources and lib directories separate, but mostly overwrote the /usr/local/bin files only saving a few by soft linking eg, ln -s /usr/local/lib/fpc/3.3.1/ppcx64 /usr/local/bin/ppcx64).

Ports tree

FPC is currently available as 3.0.4 in the ports tree, maintained by Alonso Cárdenas Márquez (acm@FreeBSD.org).

Official FPC Installer

Although the ports collection is brilliant, there are alternative methods of installing FPC too - installing from the official *.tar release packages.

  1. Downloading the official *.tar release from SourceForge.net
  2. Unpack the .tar package into a temporary directory
    tar xvf fpc-3.0.0.x86_64-freebsd10.tar
  3. Run the setup program
    ./install.sh
  4. Follow the on-screen prompts

Building FPC Trunk

  1. Get the Trunk source code from SubVersion or the Git mirrors.
  2. Make sure you have a fully working latest released FPC version installed. It is this compiler that will initially compile the Trunk FPC.
  3. gmake build OPT="-Fl/usr/local/lib"
  4. gmake install INSTALL_PREFIX=/data/devel/fpc-3.1.0/x86_64-freebsd FPC=/data/devel/fpc-3.1.0/src/compiler/ppcx64

Note: In the last command you reference the newly built compiler via the FPC= parameter.

Issues

  • gdb. After installing FreeBSD 10 and FPC, I found gdb version was 6.1.1. This will be found by Lazarus on first run as /usr/bin/gdb and it will make debugging impossible (at least with Lazarus 1.2.x and 1.3). The fix is to Install the latests gdb version by doing pkg install devel/gdb (mine complained that the latest gdb version (7.7.1) was already installed), the remedy is modifying the used debugger in Lazarus menu Tools->Options->Debugger, select from the list /usr/local/bin/gdb
  • make. On the first run Lazarus will find /usr/bin/make or simply make as the 'make' command. It will not work, install gmake (pkg install gmake) and change it in Lazarus menu Tools->Options->Environment->Files->Make path.
  • Remember that under FreeBSD, /home is a link to /usr/home, it is relevant when installing lazarus using pkg install lazarus, by default it will use a primary config path in /home/user/.lazarus but then at some point it starts mixing it as /usr/home/user/.lazarus which appears to cause problems on installing packages and rebuilding lazarus as a normal user, although this needs to be confirmed.

Older versions of FPC and FreeBSD

Support for older versions

4.x is formally no longer supported, but the old code pretty much stayed put, the defaults just changed. The differences are pretty much startup code, threading, and some code under ifdef FREEBSD5: (note, the best chance for this to work is with the code of 2.2.2)

  • 4.x has other startup code than 7.x, get the old .as files from 2.0.0 or 2.0.2 (or from similar versions svn). (I don't really remember what was different about them. It could only be the ABI number in the ELF ident), assemble them, and copy them over the existing ones.
  • Now bootstrap the compiler using OPT="-dFREEBSD4 -Xf"
  • copy sources + bootstrapped (static) compiler to 4.x
  • Bootstrap system (again with patched startup code and OPT="-Xf -dFREEBSD4"

Write your experiences here under this paragraph since this is all just theory till now. I do not have a fbsd4 to actually try anymore.

COMPAT_ requirement of the port

I haven't really researched the issue, but somehow the port maintainers added a dependancy to COMPAT_5, probably because the source default puts the .note in cprt0.as to 504000 or so. This can be easily remedied by patching the cprt0.as file before building, and put the output of

elfdump -n `which elfdump` |awk '/FreeBSD/{print $2}'

in the .long line AFTER a .string "FreeBSD" line in cprt0.as.

A script has been added to -trunk (fpc/rtl/freebsd/i386/identpatch.sh) that does this. If you have improvements, please communicate them back (to where?).

Note: The COMPAT_ dependency was removed with version 2.2.4 of freepascal, and the value of .long line into cprt0.as file is changed to ${OSVERSION} automatically.

See about ${OSVERSION} at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-after-port-mk.html


FPC_USE_LIBC

Since jan 2004, most Unix ports of FPC can be recompiled with FPC_USE_LIBC, and in those cases the RTL will use libc functions as much as possible. This was mainly introduced for the Darwin port, and may also be used for e.g. Lazarus distributions. (Lazarus links its apps to libc anyway, because of gtk)


Unix RTL, 1.0.x/1.9.x RTL compability

The 1.0.x rtl was essentially a linux only hackish rtl. The rtl was rewritten in version 1.9.x/2.x (and this still continues), and unfortunately, compatibility had to be broken.

For reasons and discussion, see Unix Rtl Doc

See also