Lazarus
Installation => General => Topic started by: erick on August 13, 2019, 08:03:16 pm
-
I've been working for hours trying to get Lazarus+FreeBSD to work together. The system has to be for FreeBSD 12.0, I don't have a choice.
FPCUPDELUXE doesn't work because it complains of no SVN (svn works fine on the system from the command line). Too bad, that was my preferred way.
FreeBSD pkg system installs Lazarus 2.0.0 and FPC 3.0.4-2 But it complains about no source when you start up Lararus. So I added the source code from that release from sourceforge, but then in complains there is no packages directory.
Merely creating a packages directory does not work.
I need to build projects with Mormot and others with Indy10, both of which are coming from Delphi heritage.
I dont' have an example of what the required 'packages' part is, if it is a file or a directory or what. And reading scads of posts, I haven't found someone who explains it.
Thanks for any hints you can provide.
-
Fpcupdeluxe should work.
Would be good to know more details about the error, so it can be improved to work on your system too.
-
fpcupdeluxe fails with:
fpcupdeluxe: ERROR: FPCNativeInstaller (CheckAndGetTools): Could not find SVN executable. Please make sure it is installed.
While the command line version works fine:
root@maggot2:~ # svn
Type 'svn help' for usage.
-
I also tried using WGET / LibCURL for download, but no effect on the SVN error
-
Okay, creating a symbolic link to svn in the local directory gets me farther.
...
Executing: svn update rtl --non-interactive --trust-server-cert --quiet /root/fpcupdeluxe/fpc300bootstrap/rtl (working dir: /root/fpcupdeluxe/fpcsrc)
fpcupdeluxe: ERROR: FPCNativeInstaller (BuildModule: FPC): Error (SVN) getting sources for intermediate bootstrap compiler. Error: -2
Not sure where to go from there.
Thanks
Erick
-
@erick, using this version https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/1.6.2y2/fpcupdeluxe-x86_64-freebsd (https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/1.6.2y2/fpcupdeluxe-x86_64-freebsd) should fix the SVN issue and allow you download the source but compilation and building is another problem you will encounter due to fpc linker issues in freebsd.
-
So does that mean there is no solution for FPC and FreeBSD?
I don't need the GUI, but packages are pretty important. I tried 2.0.0 IDE + 3.0.4 with fpupdeluxe which others had success with, but I get linker errors.
Erick
-
@erick, exactly the same error I get with both trunk and stable in freebsd 12.0
-
I successfully installed the FreeBSD port /usr/ports/editors/lazarus on FreeBSD 12.0 with a simple 'make install' using a GENERIC kernel or fixing my custom kernel as below. This gave me a working Lazarus 2.0 and fpc 3.0.4.
Without the options below (included in a GENERIC kernel by default), the build failed with a core dump when trying to run the bootstrap compiler
options COMPAT_FREEBSD32 # Compatible with i386 binaries
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options COMPAT_FREEBSD6 # Compatible with FreeBSD6
options COMPAT_FREEBSD7 # Compatible with FreeBSD7
options COMPAT_FREEBSD9 # Compatible with FreeBSD9
options COMPAT_FREEBSD10 # Compatible with FreeBSD10
Not all of the above options are probably essential, but it was easier to just enable them all rather than compiling multiple kernels. The actual core dumps seemed to be complaining about missing FreeBSD 6 (released 2005) calls. For example:
compat6.mmap() ERR#78 'Function not implemented'
SIGNAL 12 (SIGSYS) code=SI_KERNEL
process killed, signal = 12 (core dumped)
I don't believe I needed to install the source code for fpc separately.
-
Thanks so much, I will try this.
Erick
-
In fact I did have to install the FPC source code manually. You can find it in: /usr/ports/distfiles/freepascal/
As root,
cd /usr/local/share && mkdir fpsrc && tar xvzf /usr/ports/distfiles/freepascal/fpc-3.0.4.source.tar.gz
which will install the source in /usr/local/share/fpsrc/fpc-3.0.4 in case you want to later try a differemt version (eg trunk).
-
Excellent, I can no compile console apps. GUI apps, with absolutely nothing added give SIGSEGV, but I can survive without GUI apps.
Thanks very much.
Erick
-
Arrgh, linking in libraries to the Lazarus system still fails. It's not at a usuable state yet. I'm not sure where the useful error messages go, or i'd report the problem.
-
Very strange. I can compile my latest multi-platform (Windows/macOS/FreeBSD/Ubuntu) Lazarus GUI application on FreeBSD 12.0 (patch level 9) without any errors and it works almost* as expected.
*SSL only worked on FreeBSD after upgrading to FPC trunk.
-
The Lazarus port was updated today (15/16 August depending on your timezone) to remove the FPC compiler's dependence on old FreeBSD system calls and to also install the FPC source automatically.
As root, portsnap auto should update your ports tree; then delete ~/.config, ~/.lazarus and pkg delete lazarus and fpc\*
You can then make install in /usr/ports/editors/lazarus again.
-
Unfortunately the old system calls are still present. Looks like you need to use the GENERIC kernel or include the following options in your custom kernel:
options COMPAT_FREEBSD6 # Compatible with FreeBSD6
options COMPAT_FREEBSD7 # Compatible with FreeBSD7 (or kernel does not compile)
FreeBSD10 may be necessary if running 11.x; FreeBSD11 may be necessary if running 12.x.
I've logged details on FreeBSD's bugzilla.
-
Fpcupdeluxe still not work on FreeBSD now :(
-
The Lazarus port was updated today (15/16 August depending on your timezone) to remove the FPC compiler's dependence on old FreeBSD system calls and to also install the FPC source automatically.
I don't see any RTL modifications for old syscalls in that post. They just hardcode some linker paths.
-
Question is: are the recommended calls available? YES.
Should the old calls maybe marked as deprecated? Yes. Should they still be there? Yes....as long as supported. It is still supported by FreeBSD.
@trev
You can't simply remove support for that, unless the OS itself removes it. That is not the case.
-
Question is: are the recommended calls available? YES.
Should the old calls maybe marked as deprecated? Yes. Should they still be there? Yes....as long as supported. It is still supported by FreeBSD.
@trev
You can't simply remove support for that, unless the OS itself removes it. That is not the case.
Sure, if you want to use 14 year old system calls, fine. FreeBSD is up to 12.1; FreeBSD 6 was released in November 2005. The only supported versions of FreeBSD are 11.3, 12.0 (until Feb 4, 2020) and 12.1. The rest are well and truly end of life.
FreeBSD 11 onwards have newer system calls to achieve the same result which work with the currently supported versions of FreeBSD and don't need old system call kernel compatibility code to be added.
-
It doesn't matter how old they are, just how long they were supported as main calls. So that seems to be up to FreeBSD10 if FreeBSD 11 introduced the new calls.
And since FreeBSD10 is not that long out support, if you support one set of system calls only, it is not that far off.
And if it is really that interesting to move from an AIXy calling convention that aligns parameters even in registers to save the zeroing of one register.
And of course the biannual rearrangement of the stat record with probably to make sure compatibility is certainly broken.
People that like that philosophy, probably also like submitting patches. I'm anxiously waiting.
-
As a sidenote.
FPC trunk works flawless on FBSD12 with -dFPC_USE_LIBC.
-
As a sidenote.
FPC trunk works flawless on FBSD12 with -dFPC_USE_LIBC.
You'd expect that also should suffer from stat differences?
-
The stat-structures are all updated and ok as far as I can see.
The sysfs calls are not ok.
So, using libc solves all.
-
I just tested on a clean FreeBSD 12.1 install with FPC trunk. I didn't touch the linker (still LLVM). I used the bootstrap compiler from fpc 3.0.4: x86_64-freebsd11-ppcx64
ppc1 has a segment violation while compiling system. Afaik it doesn't even reach the compiler code but already fails in the startup code or unit initializations.
-
That is reported by many FBSD users (@private).
For me, defining FPC_USE_LIBC solves.
-
I tested some more, turns out so you need to also set the linker to BFD.
Easiest is
0. edit compiler/targets/t_bsd.pas. Go to method TLinkerBSD.setdefaultinfo and set "linkerprogram" to "ld.bfd"
1. install binutils
2. execute EXPORT PATH=/usr/local/bin:$PATH
3 make with OPT=-dFPC_USE_LIBC
Note that 2 is not entirely safe, but is only needed once. If you use the result of such build as starting compiler, (2) is no longer necessary, since the source modification (0) is then live.
-
I tested some more, turns out so you need to also set the linker to BFD.
Easiest is
0. edit compiler/targets/t_bsd.pas. Go to method TLinkerBSD.setdefaultinfo and set "linkerprogram" to "ld.bfd"
1. install binutils
2. execute EXPORT PATH=/usr/local/bin:$PATH
3 make with OPT=-dFPC_USE_LIBC
Note that 2 is not entirely safe, but is only needed once. If you use the result of such build as starting compiler, (2) is no longer necessary, since the source modification (0) is then live.
Hi. I want to report to you that on DragonFlyBSD which is a FreeBSD derived distro, they default to the gold linker and fpc simple will fail to link anything. They also ship the ld.bfd linker but I don't know why fpc always pick the ld.gold version, though. As I know now, fpc is ld.bfd only, without support for any other linker, which I think is a pity :(
-
About 2 I think it's not necessary at all. FreeBSD by default put package installed binary into /usr/local/bin so you don't have to add it to PATH manually like on Linux. You should check the corresponding filesystem hierachy before you port your software to a different platform.
1. Did you test before you posted?
2. it is not about ADDING to the path, it is a matter of search order. Both /usr/bin and /usr/local/bin contain LD, and this line makes sure the /usr/local/bin one (ld.bfd) is found before the /usr/bin one (LLVM LLD)
-
About 2 I think it's not necessary at all. FreeBSD by default put package installed binary into /usr/local/bin so you don't have to add it to PATH manually like on Linux. You should check the corresponding filesystem hierachy before you port your software to a different platform.
1. Did you test before you posted?
2. it is not about ADDING to the path, it is a matter of search order. Both /usr/bin and /usr/local/bin contain LD, and this line makes sure the /usr/local/bin one (ld.bfd) is found before the /usr/bin one (LLVM LLD)
Sorry. I'm too careless :-[
-
As I know now, fpc is ld.bfd only, without support for any other linker, which I think is a pity :(
The gold linker simply does not support all features that FPC requires.
-
As I know now, fpc is ld.bfd only, without support for any other linker, which I think is a pity :(
The gold linker simply does not support all features that FPC requires.
What features? Then I can test better. I had some results, I believe. But not recently and I could have been mistaken.
There are quite a few options in gold...... If I know what is "missing" at least I can make sense of my "successes".... :(
-
It doesn't matter how old they are, just how long they were supported as main calls. So that seems to be up to FreeBSD10 if FreeBSD 11 introduced the new calls.
And since FreeBSD10 is not that long out support, if you support one set of system calls only, it is not that far off.
The mmap system call 197 was superseded (moved to COMPAT6) during the development of FreeBSD 8-CURRENT on 19 Apr 2015 is what I glean from https://github.com/freebsd/freebsd/commit/2254748ed0eebd8391a1bc331f3d54d0ddb1f69d#diff-05dd75694f9540a2575ae474ae31f6c4
-
The mmap system call 197 was superseded (moved to COMPAT6) during the development of FreeBSD 8-CURRENT on 19 Apr 2015 is what I glean from https://github.com/freebsd/freebsd/commit/2254748ed0eebd8391a1bc331f3d54d0ddb1f69d#diff-05dd75694f9540a2575ae474ae31f6c4
.
The last FreeBSD 8(.4) was released in june 2013, and the branch was EOL after that. The FreeBSD 10 series was also already "-STABLE"out by that date, and I doubt they would change something as fundamental as that.
So the first release version that would have changed would be FreeBSD11 in october 2016, about an year before FPC 3.0.4 (which was a fixed release).
-
As I know now, fpc is ld.bfd only, without support for any other linker, which I think is a pity :(
For reasons. A few weeks ago I tried gold (from binutils 2.33.1):
/usr/local/bin/gold: internal error in read_script_file, at script.cc:1638
First, they need proper error messages so I know what to fix in the linker script, then we can talk about supporting them.
-
As I know now, fpc is ld.bfd only, without support for any other linker, which I think is a pity :(
For reasons. A few weeks ago I tried gold (from binutils 2.33.1):
/usr/local/bin/gold: internal error in read_script_file, at script.cc:1638
First, they need proper error messages so I know what to fix in the linker script, then we can talk about supporting them.
I don't want to hijack this thread so I opened a new thread about DFBSD :-*