- Package:
- fp-compiler
- Source:
- fpc
- Description:
- Free Pascal - compiler dependency package
- Submitter:
- Roland Stigge
- Date:
- 2025-02-02 23:48:02 UTC
- Severity:
- normal
Hi, the package m-tx in Debian now needs fpc for building (the alternative p2c doesn't work anymore with the new code). However, p2c produces a statically linked executable (causing lintian to complain). Even -XD (and also -Xc) don't help: ================================================================= $ make fpc -XD -g -B -vn -So prepmx Free Pascal Compiler version 2.2.0 [2008/03/15] for i386 Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Linux for i386 Compiling prepmx.pas Compiling control.pas Compiling utility.pas Compiling strings.pas utility.pas(124,34) Warning: range check error while evaluating constants Compiling globals.pas Compiling preamble.pas Compiling mtxline.pas Compiling notes.pas Compiling files.pas Compiling multfile.pas Compiling status.pas Compiling lyrics.pas Compiling mtx.pas Compiling analyze.pas Compiling uptext.pas Linking prepmx 4342 lines compiled, 0.9 sec 1 warning(s) issued $ file prepmx prepmx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped ================================================================= Is this intended behaviour of fpc? What's wrong here? Thanks in advance! bye, Roland
Hi Roland, AFAIK fpc does not support creating shared libraries. You can add a lintian override file to your package. Cheers, Torsten
--- Please enter the report below this line. --- Using FPC 2.2.0, it is possible, but still tricky to create a DLL executable. This will be fixed in next releases hopefully. Here is a brief example showing how to create a DLL executable. You can either change your make files or wait for -XD to be fixed. This is planned for future releases, but may take time. [mazen@aziz:tmp]$fpc -XD -Cn dynprog Hint: End of reading config file /home/mazen/.fpc.cfg Free Pascal Compiler version 2.2.0 [2008/03/16] for i386 Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Linux for i386 Compiling dynprog.pas Compiling dynlib.pas Closing script ppas.sh 21 lines compiled, 0.1 sec 2 hint(s) issued [mazen@aziz:tmp]$ppumove dynlib PPU-Mover Version 2.1.1 Copyright (c) 1998-2007 by the Free Pascal Development Team Processing dynlib.ppu... Done. Linking dynlib.o Done. [mazen@aziz:tmp]$fpc -XD dynprog.pas Hint: End of reading config file /home/mazen/.fpc.cfg Free Pascal Compiler version 2.2.0 [2008/03/16] for i386 Copyright (c) 1993-2007 by Florian Klaempfl Target OS: Linux for i386 Compiling dynprog.pas Linking dynprog 5 lines compiled, 0.2 sec 2 hint(s) issued [mazen@aziz:tmp]$file dynprog dynprog: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped [mazen@aziz:tmp]$./dynprog ./dynprog: error while loading shared libraries: libdynlib.so: cannot open shared object file: No such file or directory [mazen@aziz:tmp]$LD_LIBRARY_PATH=$PWD ./dynprog Hello from DynFunc [mazen@aziz:tmp]$ Debian Release: lenny/sid 500 unstable ftp.fr.debian.org --- Package information. --- Depends (Version) | Installed ==================================-+-================== fp-units-rtl (= 2.2.0-dfsg1-5) | 2.2.0-dfsg1-5
Hi Mazen, but that means we have to change all the fp-units-* packages to ship shared libraries. Do you plan such a change or do we wait for the next release? Cheers, Torsten
Hi Torsten, Le lundi 24 mars 2008 à 21:15 +0100, Torsten Werner a écrit : No, I don't think so. Indeed, the current implementation of DLL is not 100% safe. Many problems are known and this explains in part why -XD is not working. At the moment, DLL support is actively discussed in the FPC core team mailing list. The main goal is to clarify FPC policy for shared objects and packages. This should lead to a decision very shortly but implementation will be in 2.3.x (trunk) which means that we have to wait until 2.4.0 at least to have full DLL support working. Cheers, Mazen,
Hi Torsten, Le lundi 24 mars 2008 à 21:15 +0100, Torsten Werner a écrit : No, I don't think so. Indeed, the current implementation of DLL is not 100% safe. Many problems are known and this explains in part why -XD is not working. At the moment, DLL support is actively discussed in the FPC core team mailing list. The main goal is to clarify FPC policy for shared objects and packages. This should lead to a decision very shortly but implementation will be in 2.3.x (trunk) which means that we have to wait until 2.4.0 at least to have full DLL support working. Cheers, Mazen,
Hi, okay, then it is as always in Debian: let's wait. ;-) Thank you for the explaination, Torsten
Am 13.04.2010 06:55, schrieb Raphael Geissert: Hello, I think raising the severity of the bug to a RC-one would be a good idea, because this prevents packages built with fpc to get uploaded into the archive. Another possible solution would be, to allow again the embedded-zlib, until this bug has been fixed. What do you Joerg?
Patrick Matthäi <pmatthaei@debian.org> writes:
That bug looks unrelated to embedded-zlib. It's about statically linking
with Pascal libraries included in FPC.
The problem with embedded-zlib appears to be a false positive in Lintian.
It seems to be triggering on the string:
"Seek in deflate compressed stream failed."
although I don't see how that would match the regex that Lintian is using.
I can't find any other occurance of "inflate" or "deflate" in the strings
for easymp3gain, though.
You should override this Lintian tag for right now until we can figure out
what's going on.
This bug was fixed a long time ago in FPC. The Lintian error mentioned was a bug in Lintian itself.
The issue is still present in fpc 2.4.0-2. fpc doesn't link dynamically.
There is some confusion regarding this bug report so let me clear a few things up. Freepascal does not by default link dynamically against pascal code. There has been some experimental suport in the compiler for a while but I don't think anyone has ever seriously worked through the distro-level implications. For dynamic linking to make sense there really needs to be a commitment to ABI stability. A simple pascal program does not use any C libaries (static or dynamic) at all. The freepascal run time library makes system calls directly to the kernel. Freepascal programs that use C libaries can and do dynamically link against those C libaries. On the zlib issue. Freepascal ships (and afaict various pascal programs use) paszlib which is a pascal translation of zlib. It would probablly be good if there was an option to use the C zlib library instead as I doubt that the pascal translation is getting much in the way of security support.
Dear Customer, USPS courier was unable to contact you for your parcel delivery. Review the document that is attached to this e-mail! Thanks, Micheal Dickinson, USPS Senior Operation Agent.
Dear Customer, Your item has arrived at December 23, but our courier was not able to deliver the parcel. You can find more details in this e-mail attachment! With thanks and appreciation, Chris Massey, Chief Operation Agent.
Dear Customer, We can not deliver your parcel arrived at December 30. Postal label is enclosed to this e-mail. Please check the attachment! Yours truly, Bernard Cole, USPS Parcels Delivery Agent.
Hi, This issue is know fixed. User needs to use fpc @hardening -B -vn -So prepmx to compile the program and it should generate dynamically linked program.
This ticket can be closed now.