Re: [fpc-pascal] Profiling ARM targets
Thanks, I will give them a go. -b On Fri, Jan 10, 2014 at 10:36 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 10 Jan 2014, at 01:13, Bruce Tulloch wrote: What is the recommended way to profile FPC applications run on ARM targets Callgrind and cachegrind (both part of Valgrind) are probably the best options. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Profiling ARM targets
What is the recommended way to profile FPC applications run on ARM targets in light of the error message: Fatal: Option -pg is not, or not yet, supported on the current target platform when I try to compile for the ARM target? Regards, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Packaging shared libraries for OSX, recommendations?
On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: Under Mac OS X (and *BSD, and probably even most Linux distributions these days), you would put it under /usr/local/[lib,include,share]. Understood. So if we install our library, headers etc to /usr/local/[lib,include,share] is it true that like any UN*X, in OSX: - Command line programs *and* GUI apps will be able to use our library, - XCode will be able to find and access the headers and, - XCode App programmers can copy the .dylib file (from /usr/local/lib/libMyLib.dylib) to their project to include the library and avoid the need to redistribute our package? Presuming the answers are all yes, is packagemaker the tool we should be using to package the library for distribution? Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Packaging shared libraries for OSX, recommendations?
Okay, got it, thanks Jonas. -b On Mon, Jun 10, 2013 at 7:55 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 10 Jun 2013, at 11:41, Bruce Tulloch wrote: On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe jonas.ma...@elis.ugent.be* *wrote: Under Mac OS X (and *BSD, and probably even most Linux distributions these days), you would put it under /usr/local/[lib,include,share]**. Understood. So if we install our library, headers etc to /usr/local/[lib,include,share] is it true that like any UN*X, in OSX: - Command line programs *and* GUI apps will be able to use our library, There is no difference between the two as far as the dynamic linker is concerned. - XCode will be able to find and access the headers and, Yes. - XCode App programmers can copy the .dylib file (from /usr/local/lib/libMyLib.dylib) to their project to include the library and avoid the need to redistribute our package? The last part is incorrect. See e.g. http://qin.laya.com/tech_** coding_help/dylib_linking.htmlhttp://qin.laya.com/tech_coding_help/dylib_linking.htmland https://blogs.oracle.com/**dipol/entry/dynamic_libraries_**rpath_and_machttps://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_macfor more information. You need at least two versions of your library, or tell developers that want to include the library in their program to adapt the library's path with install_name_tool and compile/link against this modified version because otherwise their application will still insist on only looking for the /usr/local/lib version (which is why distributing a /usr/local/lib version is such a bad idea, because developers won't notice on their own machine if they make a mistake since that version can be used without them realising it) Presuming the answers are all yes, is packagemaker the tool we should be using to package the library for distribution? Yes. Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Packaging shared libraries for OSX, recommendations?
So just to be clear, if we create a framework designed for others to bundle with their own apps where our framework (for the library) looks like this: MyFramework.framework |-- MyFramework - Versions/Current/MyFramework |-- Headers - Versions/Current/Headers |-- Resources - Versions/Current/Resources `-- Versions |-- A | |-- MyFramework | |-- Headers | | |-- MyFramework.h | | `-- MyFramework.pas | `-- Resources | |-- English.lproj | | `-- Documentation | | `-- MyFrameworkAPI.html | `-- Info.plist `-- Current - A Xcode users of our library just include the framework binary (i.e. the dylib, also called MyFramework in this example) in their project. However, as part of our library build process we MUST use install_name_tool to modify the canonic path in the dylib to be relative to the executable location in the app bundle created by Xcode (when they build their app) and this relative location will always be as described in the linked examples you referred us to (i.e. @executable_path/../Frameworks/MyFramework). Have we understood this correctly? Can you give me some background on why it works this way? My understanding is that even if an app finds the dylib it needs in its own bundled Frameworks folder, ld refuses to load it because the dylib says its canonic home is somewhere else and this therefore requires the publisher of that dylib to modify the path to be where any app that uses it expects to locate the dylib even if said app already knows the location of the necessary dylib. This seems to be a rule (or bug?) which is apparently more inflexible than the standard UNIX way ld uses to locate libraries. Thanks for your pearls of wisdom on this strange (to us) topic :-) Cheers, Bruce. On Mon, Jun 10, 2013 at 7:55 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 10 Jun 2013, at 11:41, Bruce Tulloch wrote: On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe jonas.ma...@elis.ugent.be* *wrote: Under Mac OS X (and *BSD, and probably even most Linux distributions these days), you would put it under /usr/local/[lib,include,share]**. Understood. So if we install our library, headers etc to /usr/local/[lib,include,share] is it true that like any UN*X, in OSX: - Command line programs *and* GUI apps will be able to use our library, There is no difference between the two as far as the dynamic linker is concerned. - XCode will be able to find and access the headers and, Yes. - XCode App programmers can copy the .dylib file (from /usr/local/lib/libMyLib.dylib) to their project to include the library and avoid the need to redistribute our package? The last part is incorrect. See e.g. http://qin.laya.com/tech_** coding_help/dylib_linking.htmlhttp://qin.laya.com/tech_coding_help/dylib_linking.htmland https://blogs.oracle.com/**dipol/entry/dynamic_libraries_**rpath_and_machttps://blogs.oracle.com/dipol/entry/dynamic_libraries_rpath_and_macfor more information. You need at least two versions of your library, or tell developers that want to include the library in their program to adapt the library's path with install_name_tool and compile/link against this modified version because otherwise their application will still insist on only looking for the /usr/local/lib version (which is why distributing a /usr/local/lib version is such a bad idea, because developers won't notice on their own machine if they make a mistake since that version can be used without them realising it) Presuming the answers are all yes, is packagemaker the tool we should be using to package the library for distribution? Yes. Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC 2.7.1 | ARMHF/ARMV6 | Optimization breaks my code at -O2
What are the optimizations made between -O1 and -O2 on this target?
Are optimizations at this level materially different when comparing ARM to
x86 output targets?
I ask because enabling -O2 breaks my code on ARM but runs fine all the way
up to -O3 on x86.
It's no doubt something I'm doing wrong which -O2 is exposing so I thought
I'd ask if anyone can suggest what types of error are likely with building
with -O2.
Prima facie is looks like the object reference (this accessed via
register r0) is corrupt when execution enters this TACTOR_UPDATE (via an
Inherited call). The disassembly, cpu dump and this reference below show
this but it's not clear to me why or how.
Any suggestions welcome!
Thanks, Bruce.
(gdb) disass
Dump of assembler code for function TACTOR__UPDATE:
0x0006f450 +0:push{r4, r5, r6, r7, r8, r9, lr}
0x0006f454 +4:subsp, sp, #4
0x0006f458 +8:movr4, r0
0x0006f45c +12:movr5, r1
0x0006f460 +16:movr6, r2
0x0006f464 +20:movr0, #0
0x0006f468 +24:bl0x3b4a4 fpc_stackcheck
0x0006f46c +28:cmpr6, #7
0x0006f470 +32:bne0x6f504 TACTOR__UPDATE+180
0x0006f474 +36:ldrr0, [r4, #68]; 0x44
0x0006f478 +40:cmpr0, #0
0x0006f47c +44:beq0x6f4ec TACTOR__UPDATE+156
0x0006f480 +48:ldrr0, [r4, #100]; 0x64
0x0006f484 +52:cmpr0, r5
0x0006f488 +56:bne0x6f4ec TACTOR__UPDATE+156
0x0006f48c +60:ldrbr0, [r4, #86]; 0x56
0x0006f490 +64:cmpr0, #0
0x0006f494 +68:beq0x6f4ec TACTOR__UPDATE+156
0x0006f498 +72:movr7, #0
0x0006f49c +76:subr7, r7, #1
0x0006f4a0 +80:andr7, r7, #255; 0xff
0x0006f4a4 +84:addr7, r7, #1
0x0006f4a8 +88:andr7, r7, #255; 0xff
0x0006f4ac +92:andr0, r7, #255; 0xff
0x0006f4b0 +96:ldrr1, [r4, #68]; 0x44
0x0006f4b4 +100:movr2, #1
0x0006f4b8 +104:tstr1, r2, lsl r0
0x0006f4bc +108:beq0x6f4dc TACTOR__UPDATE+140
0x0006f4c0 +112:movr2, r7
0x0006f4c4 +116:movr1, r4
0x0006f4c8 +120:movr0, r4
0x0006f4cc +124:movr3, r4
0x0006f4d0 +128:ldrr3, [r3]
0x0006f4d4 +132:ldrr3, [r3, #256]; 0x100
0x0006f4d8 +136:blxr3
0x0006f4dc +140:cmpr7, #25
0x0006f4e0 +144:bcc0x6f4a4 TACTOR__UPDATE+84
0x0006f4e4 +148:movr0, #0
0x0006f4e8 +152:strr0, [r4, #68]; 0x44
0x0006f4ec +156:ldrr0, [r4, #104]; 0x68
0x0006f4f0 +160:cmpr0, r5
0x0006f4f4 +164:bne0x6f51c TACTOR__UPDATE+204
0x0006f4f8 +168:movr0, #0
0x0006f4fc +172:strr0, [r4, #60]; 0x3c
0x0006f500 +176:b0x6f51c TACTOR__UPDATE+204
0x0006f504 +180:cmpr6, #2
0x0006f508 +184:bne0x6f51c TACTOR__UPDATE+204
0x0006f50c +188:movr1, r5
0x0006f510 +192:movr0, r4
0x0006f514 +196:movr2, #0
0x0006f518 +200:bl0x6faac TACTOR__SUBSCRIBE
0x0006f51c +204:cmpr6, #6
0x0006f520 +208:bne0x6f570 TACTOR__UPDATE+288
0x0006f524 +212:movr0, r4
0x0006f528 +216:bl0x6f764 TACTOR__GETPARENT
0x0006f52c +220:cmpr5, r0
0x0006f530 +224:bne0x6f570 TACTOR__UPDATE+288
= 0x0006f534 +228:ldrbr0, [r5, #86]; 0x56
0x0006f538 +232:cmpr0, #0
0x0006f53c +236:beq0x6f558 TACTOR__UPDATE+264
0x0006f540 +240:movr0, r4
0x0006f544 +244:movr1, r4
0x0006f548 +248:ldrr1, [r1]
0x0006f54c +252:ldrr1, [r1, #240]; 0xf0
0x0006f550 +256:blxr1
0x0006f554 +260:b0x6f614 TACTOR__UPDATE+452
0x0006f558 +264:movr0, r4
0x0006f55c +268:movr1, r4
0x0006f560 +272:ldrr1, [r1]
0x0006f564 +276:ldrr1, [r1, #244]; 0xf4
0x0006f568 +280:blxr1
0x0006f56c +284:b0x6f614 TACTOR__UPDATE+452
0x0006f570 +288:movr0, r4
0x0006f574 +292:bl0x119614
CLASSES$_$TCOMPONENT_$__$$_GETCOMPONENTCOUNT$$LONGINT
0x0006f578 +296:cmpr0, #0
0x0006f57c +300:ble0x6f614 TACTOR__UPDATE+452
0x0006f580 +304:movr0, r4
0x0006f584 +308:bl0x119614
CLASSES$_$TCOMPONENT_$__$$_GETCOMPONENTCOUNT$$LONGINT
0x0006f588 +312:subsr7, r0, #1
0x0006f58c +316:bvc0x6f594 TACTOR__UPDATE+324
0x0006f590 +320:bl0x3b2c8 fpc_overflow
0x0006f594 +324:movr8, #0
0x0006f598 +328:cmpr7, r8
0x0006f59c +332:blt0x6f614 TACTOR__UPDATE+452
0x0006f5a0 +336:subr8, r8, #1
0x0006f5a4 +340:addr8, r8, #1
0x0006f5a8 +344:movr1, r8
0x0006f5ac +348:movr0, r4
(gdb) info reg
r0 0xe14
r1 0xb58af9803045783936
r2 0x00
r3 0xb2a70731760
r4 0xb5ad1e703048021616
r5
Re: [fpc-pascal] FPC 2.7.1 | ARMHF/ARMV6 | Optimization breaks my code at -O2
Thanks Nico, http://bugs.freepascal.org/view.php?id=24492 Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC cross compilation error: cannot find -lgcc
Hi Stephano, I have been having a number of problems that look similar to this in several ways. I'm trying to chase down what's going wrong and I'll let you know what I discover. First up I noticed in your log that the linker reports: /home/me/Programs/fpc/fpsrc/exported/2.7.1/rtl/linux/../unix/cthreads.pp:1032: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking AFAIK it should not be statically linked. Here's how I ran into the same problem: http://lists.freepascal.org/lists/fpc-pascal/2013-May/038242.html There may be a clue in your log: /home/me/Programs/fpc/fpsrc/exported/2.7.1/compiler/ppc fpmake.pp -n -Fu/home/me/Programs/fpc/fpsrc/exported/2.7.1/packages/fpmkunit/units_bs/i386-linux -Fu/home/me/Programs/fpc/fpsrc/exported/2.7.1/rtl/units/i386-linux -Xd -Xt -gl shows the -Xt switch is selected. I don't think it should be but Jonas would need to chime on on this. I'm looking into this apropos my builds of the RTL for cross targets. I also found that libgcc is not pulled into the link in some cases. In my case it depends on something in the crossroot (against which one's linking) at least in my case: http://lists.freepascal.org/lists/fpc-pascal/2013-May/038242.html Again, I don't know what's happening here but I want to find out. I've also discovered that the switch -XR used to to prefix search paths when cross compiling is problematic in some cases: http://lists.freepascal.org/lists/fpc-pascal/2013-May/038223.html I hope this helps. Bruce. On Sun, May 5, 2013 at 5:59 AM, patspiper patspi...@gmail.com wrote: On 12/04/13 00:11, patspiper wrote: On 12/04/13 00:08, patspiper wrote: On 11/04/13 23:25, Marco van de Voort wrote: In our previous episode, patspiper said: Cross compilation from Ubuntu 32 bit to Win32, WIn64, and Linux 64 works well with FPC 2.6.0. With FPC 2.7.1, any cross compilation yields a 'cannot find -lgcc' error. Linking what file generates that error when crosscompiling to win32 or win64? Below is the relevant part of the log for Win32 with FPC2.7.1 (fpmake.pp): make -C packages smart make[2]: Entering directory `/home/me/Programs/fpc/fpsrc/exported/2.7.1/packages' make -C fpmkunit bootstrap make[3]: Entering directory `/home/me/Programs/fpc/fpsrc/exported/2.7.1/packages/fpmkunit' /bin/mkdir -p units_bs/i386-linux /home/me/Programs/fpc/fpsrc/exported/2.7.1/compiler/ppc src/fpmkunit.pp -n -Fu/home/me/Programs/fpc/fpsrc/exported/2.7.1/rtl/units/i386-linux -Fu/home/me/Programs/fpc/fpsrc/exported/2.7.1/packages/paszlib -Fu/home/me/Programs/fpc/fpsrc/exported/2.7.1/packages/fcl-process -Fu/home/me/Programs/fpc/fpsrc/exported/2.7.1/packages/hash -FUunits_bs/i386-linux -Fu../paszlib/src -Fu../hash/src -Fi../paszlib/src -Fi../fcl-process/src/unix -Fu../fcl-process/src -Fi../fcl-process/src/linux -Fi../fcl-process/src/dummy -Xd -Xt -gl make[3]: Leaving directory `/home/me/Programs/fpc/fpsrc/exported/2.7.1/packages/fpmkunit' /home/me/Programs/fpc/fpsrc/exported/2.7.1/compiler/ppc fpmake.pp -n -Fu/home/me/Programs/fpc/fpsrc/exported/2.7.1/packages/fpmkunit/units_bs/i386-linux -Fu/home/me/Programs/fpc/fpsrc/exported/2.7.1/rtl/units/i386-linux -Xd -Xt -gl /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /home/me/Programs/fpc/fpsrc/exported/2.7.1/rtl/units/i386-linux/cthreads.o: In function `CTHREADS_$$_init': /home/me/Programs/fpc/fpsrc/exported/2.7.1/rtl/linux/../unix/cthreads.pp:1032: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/bin/ld: cannot find -lgcc fpmake.pp(33,1) Error: Error while linking fpmake.pp(33,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[2]: *** [fpmake] Error 1 make[2]: Leaving directory `/home/me/Programs/fpc/fpsrc/exported/2.7.1/packages' make[1]: *** [packages_smart] Error 2 Linux 64 with FPC2.6.3 fails while linking fpdoc.pp: /home/me/Programs/fpc/fpsrc/exported/2.6.3/compiler/ppcrossx64 -Px86_64 -XPx86_64-linux- -Xr -Fl/home/me/Programs/fpc/crossbinutils/lib//x86_64-linux -Ur -Xs -O2 -n -S2h -Fu/home/me/Programs/fpc/fpsrc/exported/2.6.3/rtl/units/x86_64-linux -Fu/home/me/Programs/fpc/fpsrc/exported/2.6.3/packages/fcl-base/units/x86_64-linux -Fu/home/me/Programs/fpc/fpsrc/exported/2.6.3/packages/iconvenc/units/x86_64-linux -Fu/home/me/Programs/fpc/fpsrc/exported/2.6.3/packages/fcl-xml/units/x86_64-linux -Fu/home/me/Programs/fpc/fpsrc/exported/2.6.3/packages/fcl-passrc/units/x86_64-linux -Fu/home/me/Programs/fpc/fpsrc/exported/2.6.3/packages/chm/units/x86_64-linux -FD/home/me/Programs/fpc/crossbinutils/bin -FE. -FUunits/x86_64-linux -Cg -Flinclude -Fl/etc/ld.so.conf.d/*.conf -Xd -Xt -gl -dx86_64 -dRELEASE fpdoc.pp /home/me/Programs/fpc/crossbinutils/bin/x86_64-linux-ld: warning: ./link.res contains output sections; did you forget -T?
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Not yet, but I will try this shortly -b On Fri, May 24, 2013 at 6:47 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 24 May 2013, at 07:31, Bruce Tulloch wrote: The key question for my ARM cross compile is why does it report: /usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/cthreads.o: In function `CTHREADS_$$_LOADPTHREADS$$BOOLEAN': cthreads.pp: (.text.n_cthreads_$$_loadpthreads$$boolean+0xc): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking when linking. I've checked the linker script and arguments and nowhere am I (or FPC) asking for a static link, so why is this message reported? What else can cause ld to attempt a static link? I don't know. Have you already tried with gcc? Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-building on from Linux/x86-64 to Linux/i386 (was: Win64 release of FPC 2.6.2 missing)
Yes, that's what thought, but why the difference between the cross
compiled squeeze/i386 case (which works) and the cross compiled
wheezy/i386 one (which does not)?
That is, both are cross builds, both are building the same code in the
same way, the only difference is the crossroot against which they're
built.
The link.res file differences between them seems moot:
*** /tmp/link-squeeze-i386-cross.res2013-05-24 19:23:25.0 +1000
--- /tmp/link-wheezy-i386-cross.res2013-05-24 19:19:29.0 +1000
***
*** 1,3
--- 1,7
+
SEARCH_DIR(/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/)
+ SEARCH_DIR(/usr/local/opt/chroot/i386-linux-wheezy/usr/local/lib/)
+ SEARCH_DIR(/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/)
+ SEARCH_DIR(/usr/local/opt/chroot/i386-linux-wheezy/lib/i386-linux-gnu/)
SEARCH_DIR(/home/bruce/.home/hg/lazarus/lcl/units/i386-linux/gtk2/)
SEARCH_DIR(/home/bruce/.home/hg/lazarus/lcl/units/i386-linux/)
SEARCH_DIR(/home/bruce/.home/hg/lazarus/components/lazutils/lib/i386-linux/)
***
*** 103,108
--- 107,114
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/i386-linux/gdbm/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/)
INPUT(
+ /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/crti.o
+
/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/crtbegin.o
test-interfaces.o
test-interfaces.or
/usr/local/lib/fpc/2.7.1/units/i386-linux/rtl/system.o
***
*** 374,379
--- 380,389
GROUP(
-lc
)
+ INPUT(
+
/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/crtend.o
+ /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/crtn.o
+ )
ENTRY(_start)
SECTIONS
{
That is, the wheezy case has four additional search paths and it has
four additional INPUT statement lines (adding crti.o, crtbegin.o,
crtend.o and crtn.o). These differences do not appear material. If the
INPUT lines are removed from the wheezy case and ppas.sh run, it still
does not link.
The native build is very similar too (see below), I can't see any
dependency differences that would explain why gcc is not pulled in for
the wheezy/i386 cross compile case but it IS pulled in for the
squeeze/i386 cross compile AND the wheezy/x86_64 native compile.
Something is affecting the linker's behaviour which is NOT in the
link.res script I think.
Bruce
*** /tmp/link-wheezy-x86_64-native-summary.res2013-05-24
19:36:41.0 +1000
--- /tmp/link-wheezy-i386-cross-summary.res2013-05-24
19:36:58.0 +1000
***
*** 1,15
! SEARCH_DIR(/lib64/)
! SEARCH_DIR(/home/bruce/.home/hg/lazarus/lcl/units/x86_64-linux/gtk2/)
! SEARCH_DIR(/home/bruce/.home/hg/lazarus/lcl/units/x86_64-linux/)
!
SEARCH_DIR(/home/bruce/.home/hg/lazarus/components/lazutils/lib/x86_64-linux/)
! SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/x86_64-linux/utmp/)
! SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/x86_64-linux/svgalib/)
! SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/x86_64-linux/lexyacc/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/)
INPUT(
! /usr/local/lib/fpc/2.7.1/units/x86_64-linux/rtl/cprt0.o
test-interfaces.o
test-interfaces.or
)
INPUT(
-ldl
--- 1,18
!
SEARCH_DIR(/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/)
! SEARCH_DIR(/usr/local/opt/chroot/i386-linux-wheezy/usr/local/lib/)
! SEARCH_DIR(/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/)
! SEARCH_DIR(/usr/local/opt/chroot/i386-linux-wheezy/lib/i386-linux-gnu/)
! SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/i386-linux/unixutil/)
! SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/i386-linux/libc/)
! SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/i386-linux/utmp/)
! SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/i386-linux/svgalib/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/)
INPUT(
! /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/crti.o
!
/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/crtbegin.o
test-interfaces.o
test-interfaces.or
+ /usr/local/lib/fpc/2.7.1/units/i386-linux/rtl/si_c21.o
)
INPUT(
-ldl
***
*** 29,39
GROUP(
-lc
)
ENTRY(_start)
SECTIONS
{
! PROVIDE (__executable_start = 0x040); . = 0x040 + SIZEOF_HEADERS;
! . = 0 + SIZEOF_HEADERS;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
--- 32,45
GROUP(
-lc
)
+ INPUT(
+
/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4/crtend.o
+ /usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu/crtn.o
+ )
ENTRY(_start)
SECTIONS
{
! PROVIDE (__executable_start = 0x01); . = 0x01 + SIZEOF_HEADERS;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
***
*** 90,97
}
. = ALIGN (0x1000) - ((0x1000 - .) (0x1000 - 1));
.dynamic: { *(.dynamic) }
! .got
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
So here's what gcc reports when run on the raspbian arm target I'm trying to cross compile for: root@beria:/tmp# gcc -### test.c -ldl Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14+rpi1) COLLECT_GCC_OPTIONS='-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1 -quiet -imultilib . -imultiarch arm-linux-gnueabihf test.c -quiet -dumpbase test.c -march=armv6 -mfloat-abi=hard -mfpu=vfp -auxbase test -o /tmp/ccTepGGB.s COLLECT_GCC_OPTIONS='-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' as -march=armv6 -mfloat-abi=hard -mfpu=vfp -meabi=5 -o /tmp/ccUcKZI2.o /tmp/ccTepGGB.s COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/ LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../:/lib/arm-linux-gnueabihf/:/lib/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/ COLLECT_GCC_OPTIONS='-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' /usr/lib/gcc/arm-linux-gnueabihf/4.6/collect2 --sysroot=/ --build-id --no-add-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X --hash-style=both -m armelf_linux_eabi /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabihf/4.6 -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../.. -L/lib/arm-linux-gnueabihf -L/usr/lib/arm-linux-gnueabihf /tmp/ccUcKZI2.o -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crtn.o ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
So this problem is not related to cthreads per se.
I've changed the program to:
program test;
uses
Interfaces;
begin
writeln('DATE ',{$i %DATE%});
writeln('FPCTARGET ',{$i %FPCTARGET%});
writeln('FPCTARGETCPU ',{$i %FPCTARGETCPU%});
writeln('FPCTARGETOS ',{$i %FPCTARGETOS%});
writeln('FPCVERSION ',{$i %FPCVERSION%});
end.
and built it as:
fpc -Tlinux -Parm \
-Fu/home/bruce/lazarus/lcl/units/arm-linux/gtk2 \
-Fu/home/bruce/lazarus/lcl/units/arm-linux \
-Fu/home/bruce/lazarus/components/lazutils/lib/arm-linux \
-s test.pas
where relevant part of /etc/fpc.cfg is:
-Sgic
-viwn
-Xs
-Fu/usr/local/lib/fpc/$fpcversion/units/$fpctarget/*
#IFDEF FPC_CROSSCOMPILING
-XP$FPCTARGET-
#IFDEF LINUX
#IFDEF CPUARMHF
-Xd
-k--sysroot=/usr/local/opt/chroot/raspbian/rootfs
-Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib/gcc/arm-linux-gnueabihf/4.6
-Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf
-Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib
-Fl/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf
-Fl/usr/local/opt/chroot/raspbian/rootfs/lib
-FD/usr/local/opt/binutils/bin
#ENDIF
#ENDIF
#ENDIF
this produces 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 Assembling test
/usr/local/opt/binutils/bin/arm-linux-as -mfloat-abi=hard -meabi=5
-march=armv7-a -mfpu=vfpv3-d16 -o test.o test.s
if [ $? != 0 ]; then DoExitAsm test; fi
rm test.s
echo Linking test
OFS=$IFS
IFS=
/usr/local/opt/binutils/bin/arm-linux-ld
--sysroot=/usr/local/opt/chroot/raspbian/rootfs
--dynamic-linker=/lib/ld-linux-armhf.so.3 -s -L. -o test link.res
if [ $? != 0 ]; then DoExitLink test; fi
IFS=$OFS
This assembles but the link fails on missing library dependencies.
The original (unmodified) INPUT statement in link.res is:
INPUT(
-ldl
-lpthread
-lX11
-lgdk_pixbuf-2.0
-lgtk-x11-2.0
-lgdk-x11-2.0
-lgobject-2.0
-lglib-2.0
-lgthread-2.0
-lgmodule-2.0
-lpango-1.0
-lcairo
-latk-1.0
)
To which I have to manually add these libraries:
-lrt
-lgcc_s
-lpcre
to fix these dependency problems, but the link then produces:
$ ./ppas.sh
Assembling test
Linking test
/usr/local/opt/binutils/bin/arm-linux-ld: warning: link.res contains
output sections; did you forget -T?
/usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/dynlibs.o: In function
`DYNLIBS_$$_LOADLIBRARY$ANSISTRING$$LONGINT':
dynlibs.pas:(.text.n_dynlibs_$$_loadlibrary$ansistring$$longint+0x1c):
warning: Using 'dlopen' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlopen.o):
In function `dlopen':
(.text+0xc): undefined reference to `__dlopen'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlclose.o):
In function `dlclose':
(.text+0x0): undefined reference to `__dlclose'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlsym.o):
In function `dlsym':
(.text+0xc): undefined reference to `__dlsym'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlerror.o):
In function `dlerror':
(.text+0x0): undefined reference to `__dlerror'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dladdr.o):
In function `dladdr':
(.text+0x0): undefined reference to `__dladdr'
An error occurred while linking test
I cannot see any reason why arm-linux-ld is trying to link this statically
on the basis of the arguments used in ppas.sh and the contents of the
link.res based on the output of gcc in my previous email.
I've tried comparing the linker arguments used with those produced by
gcc and there some differences at assembly time. Is this important?
Prima facie is looks like it might be.
For example gcc on the target says:
-march=armv6
but FPC directs the assembler to use:
-march=armv7-a
FYI, below is the full content of the (amended) link.res file...
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/)
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf/)
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/)
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf/)
SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/gcc/arm-linux-gnueabihf/4.6/)
SEARCH_DIR(/home/bruce/lazarus/lcl/units/arm-linux/gtk2/)
SEARCH_DIR(/home/bruce/lazarus/lcl/units/arm-linux/)
SEARCH_DIR(/home/bruce/lazarus/components/lazutils/lib/arm-linux/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/httpd22/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/cdrom/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/jni/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/imagemagick/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/fcl-fpcunit/)
SEARCH_DIR(/usr/local/lib/fpc/2.7.1/units/arm-linux/tcl/)
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Thanks Jonas, I think I've nailed it with your help. The linker --verbose reports: attempt to open /usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.so failed attempt to open /usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a succeeded (/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a)dlopen.o /usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/dynlibs.o: In function `DYNLIBS_$$_LOADLIBRARY$ANSISTRING$$LONGINT': dynlibs.pas:(.text.n_dynlibs_$$_loadlibrary$ansistring$$longint+0x1c): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking That is, the attempt to open libdl.so failed so libdl.a was opened instead which is the immediate reason why the link tries to link statically; the linker did not find the .so! The library libdl.so on the crossroot is in fact an absolute symlink: libdl.so - /lib/arm-linux-gnueabihf/libdl.so.2 so arm-linux-ld ends up looking for the target of symlink (/lib/arm-linux-gnueabihf/libdl.so.2) on the host and not on the crossroot. Hmm. To solve this I've replaced the symlink with a linker script of the same name containing: OUTPUT_FORMAT(elf32-littlearm) GROUP ( /lib/arm-linux-gnueabihf/libdl.so.2 /usr/lib/arm-linux-gnueabihf/libdl.a AS_NEEDED ( /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ) ) which seems to solve the problem; with a linker script the --sysroot prefix is applied correctly and the link completes successfully. Thanks for all your pointers, I'm learning a lot about how ld actually works :-) So this raises some questions perhaps you can answer or comment on for me: 1) it seems to me that the use of absolute symlinks to resolve library files (as opposed to relative links or linker scripts) is bad practice (at least insofar as one may want to use them for cross compilation) but it appears many libraries (as packaged for Debian at least) do this (use absolute links). Is there a reason one might need to use absolute links? If so, is there a way (other than hacking the library files on the crossroot as I've done here) to make cross compiling work? On the other hand, if there is no reason to use absolute symlinks then I'm thinking this may be worth me filing a bug report or two with Debian! It seems one Gentoo developer think so: http://dev.gentoo.org/~zmedico/portage/doc/ch06s06.html 2) is there any reason linker scripts should be preferred to relative symlinks? 3) there remains one problem; dependencies on librt.so, libgcc_s.so and libpcre.so are not found by FPC (it does not put them in the link.res file). However, inspecting the crossroot I can see all these libraries are in fact absolute symlinks too so I'm guessing FPC cannot find them (when cross compiling) for the same reason; I will replace them with linker scripts too and try again. Thanks for all your help and advice. Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-building on from Linux/x86-64 to Linux/i386 (was: Win64 release of FPC 2.6.2 missing)
I've solved the problem (in my case at least). http://lists.freepascal.org/lists/fpc-pascal/2013-May/038254.html Thanks for your suggestions Marco (and also thanks to Jonas!). Bruce. On Fri, May 24, 2013 at 6:27 PM, Marco van de Voort mar...@stack.nl wrote: In our previous episode, Bruce Tulloch said: This indicates libgcc is not being pulled in (the Wheezy case). That's what I would expect yes. My guess is that the default glibc references the gcc and it gets pulled in, and it doesn't in the cross situation (so you have to manually add a reference to it) I think that can be considered a bug in those cross libs. To check this compile a simple cthreads using program straight and cross with -s. This allows you to inspect the link.res in both cases. If -lgcc isn't necessary in one case, but it is in the other, I assume it is a library dependency problem ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: How does FPC calculate linker search paths upon -XP?
So it looks like -XR is not the solution for cross-compiling, at least in my case. The compiler option I used: -XR/usr/local/opt/chroot/raspbian/rootfs seems to break when the linker encounters a linker script that specifies a new path for the actual library object required; these generated paths are not prepended when using -XR. Instead one needs to use --sysroot so I've replaced this one line with: -Xd -k--sysroot=/usr/local/opt/chroot/raspbian/rootfs -Fl/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf -Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf disabling the default paths and making explicit the paths one actually requires. I still don't understand how FPC generates the search paths per my previous email but at least this alternative, verbose though it is, seems to work. Is this the correct (i.e. best practice) solution? Thanks, Bruce. On Thu, May 23, 2013 at 3:38 PM, Bruce Tulloch pas...@causal.com wrote: Using FPC 2.7.1 I'm cross-compiling from x86_64 to ARM/RPi and have specified: -XR/usr/local/opt/chroot/raspbian/rootfs This produces a link.res file that includes the following: SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf/) SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/) SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/) but it DOES NOT include this line: SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf/) despite the fact the ld.so configuration file: /usr/local/opt/chroot/raspbian/rootfs/etc/ld.so.conf.d/arm-linux-gnueabihf.conf specifies both paths as: # Multiarch support /lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf What am I doing wrong? Thanks, Bruce ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Starting with a simple test program arm-test.pas:
program test;
begin
writeln('DATE ',{$i %DATE%});
writeln('FPCTARGET ',{$i %FPCTARGET%});
writeln('FPCTARGETCPU ',{$i %FPCTARGETCPU%});
writeln('FPCTARGETOS ',{$i %FPCTARGETOS%});
writeln('FPCVERSION ',{$i %FPCVERSION%});
end.
I can cross-compile:
Free Pascal Compiler version 2.7.1 [2013/05/20] for arm
Copyright (c) 1993-2013 by Florian Klaempfl and others
Target OS: Linux for ARMHF
Compiling arm-test.pas
Assembling test
Linking arm-test
8 lines compiled, 0.1 sec
successfully producing this:
arm-test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically
linked, for GNU/Linux 2.0.0, stripped
which when executed produces:
DATE 2013/05/23
FPCTARGET arm
FPCTARGETCPU arm
FPCTARGETOS Linux
FPCVERSION 2.7.1
All good, the ARM cross-compiler is working.
However, if I simply add this uses clause:
uses
cthreads;
the program compiles fine but fails when linking:
Linking arm-test-threads
/usr/local/lib/fpc/2.7.1/
units/arm-linux/rtl/cthreads.o: In function
`CTHREADS_$$_LOADPTHREADS$$BOOLEAN':
cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+0xc): warning: Using
'dlopen' in statically linked applications requires at runtime the shared
libraries from the glibc version used for linking
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlopen.o):
In function `dlopen':
(.text+0xc): undefined reference to `__dlopen'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlclose.o):
In function `dlclose':
(.text+0x0): undefined reference to `__dlclose'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlsym.o):
In function `dlsym':
(.text+0xc): undefined reference to `__dlsym'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dladdr.o):
In function `dladdr':
(.text+0x0): undefined reference to `__dladdr'
An error occurred while linking arm-test-threads
When compiling the same code native (x86_64) or cross compiled to Linux
i386, this does not happen (i.e the program links and executes fine). The
ARM linux system against which I'm linking is raspbian for RPi.
The relevant compiler configuration is:
#IFDEF CPUARM
-Xd
-k--sysroot=/usr/local/opt/chroot/raspbian/rootfs
-Fl/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf
-Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf
-FD/usr/local/opt/binutils/bin
-XP$FPCTARGET-
#ENDIF
What am I doing wrong?
Thanks, Bruce.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Okay, so I'm not trying to link statically, not intentionally anyway. Here's the command line from ppas.sh that produces this error: /usr/local/opt/binutils/bin/arm-linux-ld \ --sysroot=/usr/local/opt/chroot/raspbian/rootfs \ --dynamic-linker=/lib/ld-linux-armhf.so.3 \ -s -L. -o arm-test-threads link.res and the dynamic linker referred to is: root@beria:/lib# file ld-linux-armhf.so.3 ld-linux-armhf.so.3: symbolic link to `arm-linux-gnueabihf/ld-2.13.so' root@beria:/lib# file arm-linux-gnueabihf/ld-2.13.so arm-linux-gnueabihf/ld-2.13.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x40caad061df15685e213cec1e4dfe1ba5f67701c, stripped Any clues? -b On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:10, Bruce Tulloch wrote: However, if I simply add this uses clause: uses cthreads; the program compiles fine but fails when linking: Linking arm-test-threads /usr/local/lib/fpc/2.7.1/ units/arm-linux/rtl/cthreads.**o: In function `CTHREADS_$$_LOADPTHREADS$$**BOOLEAN': cthreads.pp:(.text.n_cthreads_**$$_loadpthreads$$boolean+0xc): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Why/how are you trying to create a statically linked binary? As the message above explains, statically linking libdl relies on a bunch of library magic. At the very least you'll probably also have to link libc explicitly, but I would really recommend to link dynamically instead. Support for binaries statically linked against C libraries is generally very much untested, and known not to work on certain platforms (e.g. Linux/x86-64). Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Yes, it's in the search path as: root@beria:/lib/arm-linux-gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9812 Feb 23 00:37 libdl-2.13.so lrwxrwxrwx 1 root root 13 Feb 23 00:37 libdl.so.2 - libdl-2.13.so It's referred to in an INPUT statement in link.res as: INPUT( -lpthread -ldl ) and there are two search statements: SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf/) SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf/) at the top of the file which suggest it should be found okay. On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:25, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe jonas.ma...@elis.ugent.be **wrote: On 23 May 2013, at 14:10, Bruce Tulloch wrote: Linking arm-test-threads /usr/local/lib/fpc/2.7.1/ units/arm-linux/rtl/cthreads.o: In function `CTHREADS_$$_LOADPTHREADS$$BOOLEAN': cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+**0xc): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Why/how are you trying to create a statically linked binary? As the message above explains, statically linking libdl relies on a bunch of library magic. At the very least you'll probably also have to link libc explicitly, but I would really recommend to link dynamically instead. Support for binaries statically linked against C libraries is generally very much untested, and known not to work on certain platforms (e.g. Linux/x86-64). Okay, so I'm not trying to link statically, not intentionally anyway. Do you have a libdl.so in your library search path? And what kind of reference to libdl does link.res contain? Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Just noticed another INPUT statement also refers to dl as: /usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/dl.o This appears ahead of the -ldl statement. Could this be the problem? -b On Thu, May 23, 2013 at 10:32 PM, Bruce Tulloch pas...@causal.com wrote: Yes, it's in the search path as: root@beria:/lib/arm-linux-gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9812 Feb 23 00:37 libdl-2.13.so lrwxrwxrwx 1 root root 13 Feb 23 00:37 libdl.so.2 - libdl-2.13.so It's referred to in an INPUT statement in link.res as: INPUT( -lpthread -ldl ) and there are two search statements: SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf/) SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf/) at the top of the file which suggest it should be found okay. On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:25, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe jonas.ma...@elis.ugent.be **wrote: On 23 May 2013, at 14:10, Bruce Tulloch wrote: Linking arm-test-threads /usr/local/lib/fpc/2.7.1/ units/arm-linux/rtl/cthreads.o: In function `CTHREADS_$$_LOADPTHREADS$$BOOLEAN': cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+**0xc): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking Why/how are you trying to create a statically linked binary? As the message above explains, statically linking libdl relies on a bunch of library magic. At the very least you'll probably also have to link libc explicitly, but I would really recommend to link dynamically instead. Support for binaries statically linked against C libraries is generally very much untested, and known not to work on certain platforms (e.g. Linux/x86-64). Okay, so I'm not trying to link statically, not intentionally anyway. Do you have a libdl.so in your library search path? And what kind of reference to libdl does link.res contain? Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Okay, but it is installed: root@beria:~# apt-file search libdl.so libc6: /lib/arm-linux-gnueabihf/libdl.so.2 libc6-dev: /usr/lib/arm-linux-gnueabihf/libdl.so root@beria:~# apt-show-versions libc6-dev libc6-dev/wheezy uptodate 2.13-38+rpi2 but I noticed that: root@beria:/usr/lib/arm-linux-gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9042 Feb 23 00:38 libdl.a lrwxrwxrwx 1 root root 35 Feb 23 00:38 libdl.so - /lib/arm-linux-gnueabihf/libdl.so.2 which means they're the same file. Checking my host x86_64 system we have: bruce@fermi:/usr/lib/x86_64-linux-gnu$ ls -l libdl* -rw-r--r-- 1 root root 13074 Dec 31 02:36 libdl.a lrwxrwxrwx 1 root root32 Dec 31 02:36 libdl.so - /lib/x86_64-linux-gnu/libdl.so.2 bruce@fermi:/usr/lib/x86_64-linux-gnu$ but building native on the host does not produce this problem. Still confused :-) -b On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:32, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@elis.ugent.be **wrote: On 23 May 2013, at 14:25, Bruce Tulloch wrote: Do you have a libdl.so in your library search path? And what kind of reference to libdl does link.res contain? Yes, it's in the search path as: root@beria:/lib/arm-linux-**gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9812 Feb 23 00:37 libdl-2.13.so lrwxrwxrwx 1 root root 13 Feb 23 00:37 libdl.so.2 - libdl-2.13.so You don't have libdl.so, only libdl.so.2. The latter is for use at run time, the former for use at link/compile time. Install the libc-dev or similar package in your crossroot to get it along with other missing symlinks. Do not start creating those manually, it will only lead to errors and confusion down the line. It's referred to in an INPUT statement in link.res as: INPUT( -lpthread -ldl ) and there are two search statements: SEARCH_DIR(/usr/local/opt/**chroot/raspbian/rootfs/usr/** lib/arm-linux-gnueabihf/) SEARCH_DIR(/usr/local/opt/**chroot/raspbian/rootfs/lib/** arm-linux-gnueabihf/) at the top of the file which suggest it should be found okay. The linker will only look for libdl.so and resolve it to its target in case it's a symlink, so that the symlink is no longer required at run time. It will not look for libdl.so.something, that one is used by the programs at run time (since the symlinks at compile/link time pointed to it and the linker will write the name of this symlink target into the binary's list of linked libraries). Just noticed another INPUT statement also refers to dl as: /usr/local/lib/fpc/2.7.1/**units/arm-linux/rtl/dl.o This appears ahead of the -ldl statement. That is the object file of the Pascal dl unit. It is unrelated to your library issue. Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Okay, I understand the reason for the two file locations, thanks. The problem occurs ONLY when cross-compiling to ARM. Native (and cross to i386) is fine. The files I referred to are on the crossroot not the host despite appearances; the crossroot is at /usr/local/opt/chroot/raspbian/rootfs but I reported these files in my previous email from within a qemu enabled chroot (so they looked like they were native). The machine name beria is the chroot and fermi is the host. My apologies for the confusion. -b On Thu, May 23, 2013 at 11:19 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 15:03, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe jonas.ma...@elis.ugent.be **wrote: On 23 May 2013, at 14:32, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@elis.ugent.be **wrote: On 23 May 2013, at 14:25, Bruce Tulloch wrote: Do you have a libdl.so in your library search path? And what kind of reference to libdl does link.res contain? Yes, it's in the search path as: root@beria:/lib/arm-linux-**gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9812 Feb 23 00:37 libdl-2.13.so lrwxrwxrwx 1 root root 13 Feb 23 00:37 libdl.so.2 - libdl-2.13.so You don't have libdl.so, only libdl.so.2. The latter is for use at run time, the former for use at link/compile time. Install the libc-dev or similar package in your crossroot to get it along with other missing symlinks. Do not start creating those manually, it will only lead to errors and confusion down the line. Okay, but it is installed: root@beria:~# apt-file search libdl.so libc6: /lib/arm-linux-gnueabihf/**libdl.so.2 libc6-dev: /usr/lib/arm-linux-gnueabihf/**libdl.so The topic of this thread is about cross-compiling, but those are the files on the native system. Are you getting this error while cross-compiling or while compiling natively? If you are compiling natively, try compiling something with gcc -### x.c -ldl to see what parameters gcc passes to linker (create an empty x.c file first). root@beria:~# apt-show-versions libc6-dev libc6-dev/wheezy uptodate 2.13-38+rpi2 but I noticed that: root@beria:/usr/lib/arm-linux-**gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9042 Feb 23 00:38 libdl.a lrwxrwxrwx 1 root root 35 Feb 23 00:38 libdl.so - /lib/arm-linux-gnueabihf/**libdl.so.2 which means they're the same file. Yes, they are the same file. Why that is the case and why nevertheless need both is what I tried to explain in my previous message. Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
I have to pack it in for about 8 hours (I'm down under) but I can provide more feedback then. By way of background, I have cross-compilation set up and working well for Linux i386 and Windows i385 and x86_64 targets from this x86_64 development system. I debootstrapped a raspbian system using qemu to add the ARM/RPi as a new target when I ran into this problem. The setup I've used for this target is very similar to the Linux i386 cross setup which works just fine. I've compared the linker arguments and link.res between the i386 and ARM cross builds and cannot see a difference which looks material to the problem. Any suggestions as to what else I can try or where else I can look for a solution are welcome! Thanks for all your advice so far, it's most appreciated. -b On Thu, May 23, 2013 at 11:34 PM, Bruce Tulloch pas...@causal.com wrote: Okay, I understand the reason for the two file locations, thanks. The problem occurs ONLY when cross-compiling to ARM. Native (and cross to i386) is fine. The files I referred to are on the crossroot not the host despite appearances; the crossroot is at /usr/local/opt/chroot/raspbian/rootfs but I reported these files in my previous email from within a qemu enabled chroot (so they looked like they were native). The machine name beria is the chroot and fermi is the host. My apologies for the confusion. -b On Thu, May 23, 2013 at 11:19 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 15:03, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe jonas.ma...@elis.ugent.be **wrote: On 23 May 2013, at 14:32, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@elis.ugent.be **wrote: On 23 May 2013, at 14:25, Bruce Tulloch wrote: Do you have a libdl.so in your library search path? And what kind of reference to libdl does link.res contain? Yes, it's in the search path as: root@beria:/lib/arm-linux-**gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9812 Feb 23 00:37 libdl-2.13.so lrwxrwxrwx 1 root root 13 Feb 23 00:37 libdl.so.2 - libdl-2.13.so You don't have libdl.so, only libdl.so.2. The latter is for use at run time, the former for use at link/compile time. Install the libc-dev or similar package in your crossroot to get it along with other missing symlinks. Do not start creating those manually, it will only lead to errors and confusion down the line. Okay, but it is installed: root@beria:~# apt-file search libdl.so libc6: /lib/arm-linux-gnueabihf/**libdl.so.2 libc6-dev: /usr/lib/arm-linux-gnueabihf/**libdl.so The topic of this thread is about cross-compiling, but those are the files on the native system. Are you getting this error while cross-compiling or while compiling natively? If you are compiling natively, try compiling something with gcc -### x.c -ldl to see what parameters gcc passes to linker (create an empty x.c file first). root@beria:~# apt-show-versions libc6-dev libc6-dev/wheezy uptodate 2.13-38+rpi2 but I noticed that: root@beria:/usr/lib/arm-linux-**gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9042 Feb 23 00:38 libdl.a lrwxrwxrwx 1 root root 35 Feb 23 00:38 libdl.so - /lib/arm-linux-gnueabihf/**libdl.so.2 which means they're the same file. Yes, they are the same file. Why that is the case and why nevertheless need both is what I tried to explain in my previous message. Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross-building on from Linux/x86-64 to Linux/i386 (was: Win64 release of FPC 2.6.2 missing)
While trying to debug my ARM cross-compile problems (in another email thread) I decided to replicate the cross-compiler setup to i386 (to compare it for clues) but I've run into another problem with x86_64 - i386 cross compiling which seems related to this thread. My cross built fpc 2.7.1 works just fine for x86_64 - i386 when fpc.cfg has: #IFDEF LINUX #IFDEF CPUI386 -Xd -k--sysroot=/usr/local/opt/chroot/i386-linux-squeeze -FD/usr/local/opt/binutils/bin #ENDIF #ENDIF that is, when built against a Debian Squeeze crossroot. However when linked against a Wheezy crossroot: #IFDEF LINUX #IFDEF CPUI386 -Xd -k--sysroot=/usr/local/opt/chroot/i386-linux-wheezy -FD/usr/local/opt/binutils/bin #ENDIF #ENDIF It fails reporting lines like this: (.text+0x795): undefined reference to `__divdi3' This indicates libgcc is not being pulled in (the Wheezy case). Wheezy is multarch and -Xd means no standard locations are searched by fpc anyway, so in light of these two bug reports: http://bugs.freepascal.org/view.php?id=24372 http://bugs.freepascal.org/view.php?id=24262 I amended fpc.cfg as: #IFDEF LINUX #IFDEF CPUI386 -Xd -k--sysroot=/usr/local/opt/chroot/i386-linux-wheezy -Fl/usr/local/opt/chroot/i386-linux-wheezy/lib/i386-linux-gnu -Fl/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i386-linux-gnu -Fl/usr/local/opt/chroot/i386-linux-wheezy/lib/i486-linux-gnu -Fl/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/i486-linux-gnu -Fl/usr/local/opt/chroot/i386-linux-wheezy/usr/local/lib -Fl/usr/local/opt/chroot/i386-linux-wheezy/usr/lib/gcc/i486-linux-gnu/4.4 -FD/usr/local/opt/binutils/bin #ENDIF #ENDIF It still did not pull in libgcc but I know libgcc.a in the correct place (in the crossroot) so I recompiled with -Cn and linked with ppas.sh after manually adding -lgcc to the GROUP statement in link.res, it linked correctly. So my question is; what am I missing in the wheezy case that means libgcc is not applied during the link where as (with everything else being identical) the squeeze case does work out of the box (i.e. no explicit -lgcc needs to be applied in the link.res file). Thanks, Bruce. On Wed, May 8, 2013 at 2:34 AM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 07 May 2013, at 18:17, patspiper wrote: Cross compiler building is broken for FPC 2.7.1 on Ubuntu and Fedora. I had submitted a couple of bug reports and made several posts in this mailing list, but all went unnoticed or were not handled. I have almost lost hope. Bug reports: http://bugs.freepascal.org/view.php?id=24262 You presumably have to add something like CROSSOPT=-XR/path/to/your/32bit/root -Fl/directory/containing/your/32bitlibgcc. As Florian mentioned, the compiling the entire tree now depends on certain C libraries, and hence you have to tell the build process where to find these (and the associated startup code files) if they are not in the standard directories. http://bugs.freepascal.org/view.php?id=24372 And does the linker not interpret that parameter correctly? Even if it doesn't, that does not appear to be a problem specific to cross building. Jonas PS: when asking questions about a different topic, at change the subject (and preferably start a new thread altogether)___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] CThreads problem when cross-compiling to ARM/RPi.
Raspbian is a Debian Wheezy derived distribution for ARMHF on Raspberry Pi. My attempts to replicate the exactly same setup for a Wheezy based i386 target (so I could compare with this one) ran into problems when cross compiled and linked: http://lists.freepascal.org/lists/fpc-pascal/2013-May/038241.html In that case the cross compile did not pull in libgcc but I found a temporary hack to work around it. Perhaps they are related? They are both Wheezy based crossroots. The key question for my ARM cross compile is why does it report: /usr/local/lib/fpc/2.7.1/units/arm-linux/rtl/cthreads.o: In function `CTHREADS_$$_LOADPTHREADS$$BOOLEAN': cthreads.pp: (.text.n_cthreads_$$_loadpthreads$$boolean+0xc): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking when linking. I've checked the linker script and arguments and nowhere am I (or FPC) asking for a static link, so why is this message reported? What else can cause ld to attempt a static link? Bruce. On Thu, May 23, 2013 at 11:48 PM, Bruce Tulloch pas...@causal.com wrote: I have to pack it in for about 8 hours (I'm down under) but I can provide more feedback then. By way of background, I have cross-compilation set up and working well for Linux i386 and Windows i385 and x86_64 targets from this x86_64 development system. I debootstrapped a raspbian system using qemu to add the ARM/RPi as a new target when I ran into this problem. The setup I've used for this target is very similar to the Linux i386 cross setup which works just fine. I've compared the linker arguments and link.res between the i386 and ARM cross builds and cannot see a difference which looks material to the problem. Any suggestions as to what else I can try or where else I can look for a solution are welcome! Thanks for all your advice so far, it's most appreciated. -b On Thu, May 23, 2013 at 11:34 PM, Bruce Tulloch pas...@causal.com wrote: Okay, I understand the reason for the two file locations, thanks. The problem occurs ONLY when cross-compiling to ARM. Native (and cross to i386) is fine. The files I referred to are on the crossroot not the host despite appearances; the crossroot is at /usr/local/opt/chroot/raspbian/rootfs but I reported these files in my previous email from within a qemu enabled chroot (so they looked like they were native). The machine name beria is the chroot and fermi is the host. My apologies for the confusion. -b On Thu, May 23, 2013 at 11:19 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 23 May 2013, at 15:03, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 23 May 2013, at 14:32, Bruce Tulloch wrote: On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe jonas.ma...@elis.ugent.be **wrote: On 23 May 2013, at 14:25, Bruce Tulloch wrote: Do you have a libdl.so in your library search path? And what kind of reference to libdl does link.res contain? Yes, it's in the search path as: root@beria:/lib/arm-linux-gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9812 Feb 23 00:37 libdl-2.13.so lrwxrwxrwx 1 root root 13 Feb 23 00:37 libdl.so.2 - libdl-2.13.so You don't have libdl.so, only libdl.so.2. The latter is for use at run time, the former for use at link/compile time. Install the libc-dev or similar package in your crossroot to get it along with other missing symlinks. Do not start creating those manually, it will only lead to errors and confusion down the line. Okay, but it is installed: root@beria:~# apt-file search libdl.so libc6: /lib/arm-linux-gnueabihf/libdl.so.2 libc6-dev: /usr/lib/arm-linux-gnueabihf/libdl.so The topic of this thread is about cross-compiling, but those are the files on the native system. Are you getting this error while cross-compiling or while compiling natively? If you are compiling natively, try compiling something with gcc -### x.c -ldl to see what parameters gcc passes to linker (create an empty x.c file first). root@beria:~# apt-show-versions libc6-dev libc6-dev/wheezy uptodate 2.13-38+rpi2 but I noticed that: root@beria:/usr/lib/arm-linux-gnueabihf# ls -l libdl* -rw-r--r-- 1 root root 9042 Feb 23 00:38 libdl.a lrwxrwxrwx 1 root root 35 Feb 23 00:38 libdl.so - /lib/arm-linux-gnueabihf/libdl.so.2 which means they're the same file. Yes, they are the same file. Why that is the case and why nevertheless need both is what I tried to explain in my previous message. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] How does FPC calculate linker search paths upon -XP?
Using FPC 2.7.1 I'm cross-compiling from x86_64 to ARM/RPi and have specified: -XR/usr/local/opt/chroot/raspbian/rootfs This produces a link.res file that includes the following: SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf/) SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/) SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/usr/lib/) but it DOES NOT include this line: SEARCH_DIR(/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf/) despite the fact the ld.so configuration file: /usr/local/opt/chroot/raspbian/rootfs/etc/ld.so.conf.d/arm-linux-gnueabihf.conf specifies both paths as: # Multiarch support /lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf What am I doing wrong? Thanks, Bruce ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
Thanks Ludo, but I know the value in (%eax) in this case is nil (see the cpu register dump in my email) because the address of the string length (in edx) is 0xfff8 (which is 8 less than nil) per the instruction just before the one that fails with SEGV. The SEGV itself is caused by an attempt to read the address in edx, i.e. 0xfff8 at the instruction cmpl $0,(%edx). The corruption is not occurring when the return value of foo is used, it's occurring when the Result variable in foo is first assigned (a valid string, '') when Result first appears in scope of the body of the function foo. Thanks for your feedback. Cheers, Bruce. On Thu, May 9, 2013 at 4:21 PM, Ludo Brands ludo.bra...@free.fr wrote: On 05/09/2013 05:19 AM, Bruce Tulloch wrote: This tells me that the test at the top of fpc_AnsiStr_Decr_Ref: cmpl $0,(%eax) jne .Ldecr_ref_continue ret .Ldecr_ref_continue: passed (i.e. (%eax) was NOT nil) but sometime during the execution of the following code: // Temps allocated between ebp-24 and ebp+0 subl$4,%esp // Var S located in register // Var l located in register movl%eax,(%esp) // [101] l:=@PAnsiRec mailto:=@PAnsiRec(S-FirstOff)^.Ref; movl(%eax),%edx subl$8,%edx // [102] If l^0 then exit; cmpl$0,(%edx) the variable (%eax) MUST have been changed (to nil) BY ANOTHER THREAD. Is there any other plausible explanation I may have missed? SIGSEGV is caused by an access to any memory outside the process address space. Not only nil. So the first test only checks if the address is not nil but will let other, even invalid, addresses pass on. If there is no other explanation, then it means I need to find out how the string variable referred to by (%eax) could have been been accessed (or even known to exist) by any other thread in the same address space. If that variable is local to a function (i.e. foo's Result with SEGV upon its assignment immediately it first comes into scope, per my earlier email) then absent a bug in FPC's handling string references and allocation, it seems impossible that it could be known or referenced by any other other thread. I'm reasonably confident there's no other way it could be overwritten by another thread (i.e. I don't think there are any range or buffer pointer errors anywhere else) so logic tells me I must have the wrong thesis or there's a string handling error in FPC. Any clues or insight, gratefully received :-) Result in foo is initialized with the address of the left side variable in the call to foo. If you have s:=foo; result will point to s. If you just call foo; and drop the result, the compiler will create and use a hidden temp string variable. Strings are managed types and initialized to nil. So you are looking at the wrong location for your bug. You should look at what has corrupted the string variable that receives the result of foo. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
Thanks José, I can see that might cause a problem given bar passes result by reference to foo without initializing result first. My question to Jonas or others more knowledgeable than me about what the compiler does, is whether result (in your example and my own case) is guaranteed to be initialized to nil when it first appears in scope (i.e. before it's been assigned any value in our code). If it is initialized to nil, then foo would receive a reference to bar's result variable (via para) and the value of that variable would be nil (and all would be okay). If it isn't initialized to nil, the same rule applies but the value of result (as seen by foo via para) would likely be invalid and would probably blow up in foo when dereferenced (as a string). My problem is similar except that I know it's not nil when passed in (because the initial test in fpc_AnsiStr_Decr_Ref looking for nil passes) but that it becomes nil very soon afterward (because the SEGV arises as an indirect result of it being nil, as I explained in my reply to Ludo just now). I'm pretty sure I have a shared memory problem somewhere between threads in my code but I can't understand how this could be given the erroneously shared variable appears to be an automatic variable (i.e. Result) that has just been created on the stack in the function foo that calls fpc_AnsiStr_Decr_Ref where the SEGV occurs. I'll keep looking :-) Bruce. On Thu, May 9, 2013 at 9:48 PM, José Mejuto joshy...@gmail.com wrote: El 09/05/2013 5:19, Bruce Tulloch escribió: If there is no other explanation, then it means I need to find out how the string variable referred to by (%eax) could have been been accessed (or even known to exist) by any other thread in the same address space.-- Hello, In the past I had suffered a problem like yours and the culprit was another different function that passes result (string) as a parameter when calling a function without initialization, something like this: function foo(var para: string): string; begin //Something with para end; function bar(): string; begin result:=foo(result); end; I hope this helps... __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
The compiler turns such functions into procedures with an implicit var-parameter and the *caller* passes the location where the function result should go via that parameter. Okay, thanks, that clarifies, now I understand how a variable in the caller's scope can be affected while making assignments to Result in the callee's scope BEFORE callee has finished executing. Another way of stating this is; Result is a local variable of a function, initialized to nil and passed by value to the caller upon completion ONLY if Result not a reference to a dynamic type, otherwise it's an implicit var argument with scope beyond that of the function. Is that correct? If so, it would seem to be a bit of semantic trap for the unwary :-) Such optimizations only occur in safe situations (e.g., not when assigning to a global variable... Does the compiler consider ANY non-local variable to be global? For example, fields of an object? So you are probably writing in two threads to whatever you are assigning the result of that function to. Yep, makes sense, we will look carefully to see if that's what we're doing. The functions concerned are actually methods of the TBlockSocket class of the synapse library. We use an instance of this class in two threads; one sending, the other receiving. These threads have full shared memory protection in our own code but having a look at the TBlockSocket implementation I can see at least one suspect; FLastErrorDesc. This field is changed by methods that send and receive on the socket which means it's assigned values in the context of two different threads (given our usage). Indeed it suggests TBlockSocket is not thread safe as currently coded. Looks like a smoking gun to me. Thanks one and all for all your helpful feedback! Bruce. On Thu, May 9, 2013 at 10:55 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 09 May 2013, at 14:39, Bruce Tulloch wrote: Thanks José, I can see that might cause a problem given bar passes result by reference to foo without initializing result first. My question to Jonas or others more knowledgeable than me about what the compiler does, is whether result (in your example and my own case) is guaranteed to be initialized to nil when it first appears in scope (i.e. before it's been assigned any value in our code). Every instance of an automated type, whether it was explicitly declared or implicitly created as a temp, initially gets the value nil. However, as Michael and Ludo explained, the result variable of a function returning an ansistring/unicodestring is not created inside that function itself. The compiler turns such functions into procedures with an implicit var-parameter and the *caller* passes the location where the function result should go via that parameter. This location can be a temporary location, but the compiler can also optimize this by directly passing the location of the variable to which you assign the result of that function call. Such optimizations only occur in safe situations (e.g., not when assigning to a global variable, because otherwise assigning something to the function result would immediately change the value of that global variable too), but as Ludo explains this means that you are looking in the wrong place for the data race. So you are probably writing in two threads to whatever you are assigning the result of that function to. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
After a random but very long period of time (i.e. very many successful calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref. GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's reference is to be decremented) is nil (i.e. 0x0). Prima facie, that's the reason for the SEGV, but how is it possible that the compiler would pass a nil pointer to this function the first place? To put this into context, I'm running FPC 2.6.2 on a 32 bit Linux system executing in a multi-threaded application (which uses python threads and fpc threads). I have not found obvious evidence of memory corruption from other execution contexts or shared memory handling problems. The SEGV occurs when called from a function, let's call it foo, that looks like this: function foo : AnsiString; begin Result := ''; other stuff end; The AnsiString pointer that fpc_AnsiStr_Decr_Ref throws a SEGV is Result, at the first line of the function foo. It appears the compiler is passing Result to fpc_AnsiStr_Decr_Ref even though Result (at this point in the function) must be nil (having only just come into scope). How is is possible that fpc_AnsiStr_Decr_Ref is being called at all? Any/all advice gratefully received. Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
I should clarify, foo is a virtual method of an object, not a regular function. -b On Wed, May 8, 2013 at 4:13 PM, Bruce Tulloch pas...@causal.com wrote: After a random but very long period of time (i.e. very many successful calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref. GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's reference is to be decremented) is nil (i.e. 0x0). Prima facie, that's the reason for the SEGV, but how is it possible that the compiler would pass a nil pointer to this function the first place? To put this into context, I'm running FPC 2.6.2 on a 32 bit Linux system executing in a multi-threaded application (which uses python threads and fpc threads). I have not found obvious evidence of memory corruption from other execution contexts or shared memory handling problems. The SEGV occurs when called from a function, let's call it foo, that looks like this: function foo : AnsiString; begin Result := ''; other stuff end; The AnsiString pointer that fpc_AnsiStr_Decr_Ref throws a SEGV is Result, at the first line of the function foo. It appears the compiler is passing Result to fpc_AnsiStr_Decr_Ref even though Result (at this point in the function) must be nil (having only just come into scope). How is is possible that fpc_AnsiStr_Decr_Ref is being called at all? Any/all advice gratefully received. Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
Thanks Jonas, that confirms what I suspected. Next time I trap an instance of this (rare) fault I will inspect exactly which CPU instruction raised the SEGV inside fpc_AnsiStr_Decr_Ref in search of a source of memory corruption. Bruce. On Wed, May 8, 2013 at 11:49 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 08 May 2013, at 08:13, Bruce Tulloch wrote: After a random but very long period of time (i.e. very many successful calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref. GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's reference is to be decremented) is nil (i.e. 0x0). Prima facie, that's the reason for the SEGV, but how is it possible that the compiler would pass a nil pointer to this function the first place? The first thing fpc_AnsiStr_Decr_Ref does is check whether its parameter is nil, and if so it immediately exists. It can be nil in case the ansistring contains an empty string. That routine itself also sets its argument to nil in case this was not the case initially (it's a var-parameter), and I assume your crash happens after this has been done. To put this into context, I'm running FPC 2.6.2 on a 32 bit Linux system executing in a multi-threaded application (which uses python threads and fpc threads). I have not found obvious evidence of memory corruption from other execution contexts or shared memory handling problems. It's nevertheless most likely memory corruption. You can try compiling with -gv and running your program under valgrind to see whether it finds anything (you will probably get some false positives about certain RTL pchar routines such as strscan and strlen, but you can ignore those). Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
Michael, thanks for your feedback. One thing that confuses me in light of Jonas' reply, if what you say is correct (that local variables that have just come into scope are not guaranteed to be nil) then assignment of Result := ''; at the first line of foo may arbitrarily SEGV because fpc_AnsiStr_Decr_Ref will interpret the (possibly) non-nil value (of Result) as an AnsiString which (being a random uninitialized value) will likely be incorrect and blow up. Surely the semantics of string handling relies on FPC guaranteeing automatic variables are always preassigned nil when they come into scope? Put another way, how does fpc_AnsiStr_Decr_Ref and friends, which receive the address of the caller's Result variable via their var parameter know that the value of this parameter (which may not be initialized if what you say is correct) is or is not a valid string? Bruce. On Wed, May 8, 2013 at 5:18 PM, Michael Van Canneyt mich...@freepascal.orgwrote: On Wed, 8 May 2013, Bruce Tulloch wrote: After a random but very long period of time (i.e. very many successful calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref. GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's reference is to be decremented) is nil (i.e. 0x0). Prima facie, that's the reason for the SEGV, but how is it possible that the compiler would pass a nil pointer to this function the first place? To put this into context, I'm running FPC 2.6.2 on a 32 bit Linux system executing in a multi-threaded application (which uses python threads and fpc threads). I have not found obvious evidence of memory corruption from other execution contexts or shared memory handling problems. The SEGV occurs when called from a function, let's call it foo, that looks like this: function foo : AnsiString; begin Result := ''; other stuff end; The AnsiString pointer that fpc_AnsiStr_Decr_Ref throws a SEGV is Result, at the first line of the function foo. It appears the compiler is passing Result to fpc_AnsiStr_Decr_Ref even though Result (at this point in the function) must be nil (having only just come into scope). This is not correct. Result is NOT guaranteed to be nil. About a year ago, I was as surprised as you are to discover this, but it is so. It is even so in Delphi. How is is possible that fpc_AnsiStr_Decr_Ref is being called at all? Roughly: What happens is that the caller gives the address of the location where the result must go. The function receives this address, and then treats it as a normal variable, meaning that as soon as it is used, fpc_AnsiStr_Decr_Ref and friends come into play. The exact behaviour also depends on the compiler version. One of the compiler maintainers can describe this in more detail. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
I've not managed to trap it again, but based on the information I have from the last time it occurred I can say the error happened here: --- a/rtl/i386/i386.inc +++ b/rtl/i386/i386.inc @@ -1523,7 +1523,7 @@ movl(%eax),%edx subl$8,%edx // [102] If l^0 then exit; cmpl$0,(%edx) -- SEGV OCCURS HERE jl .Lj3596 .Lj3603: // [104] If declocked(l^) then That is, when testing the string length, the address of the length variable appears to be duff. I don't know what %edx was pointing to at the time (I hope to know next time I trap it) but it was obviously wrong. -b On Thu, May 9, 2013 at 9:33 AM, Bruce Tulloch pas...@causal.com wrote: Thanks Jonas, that confirms what I suspected. Next time I trap an instance of this (rare) fault I will inspect exactly which CPU instruction raised the SEGV inside fpc_AnsiStr_Decr_Ref in search of a source of memory corruption. Bruce. On Wed, May 8, 2013 at 11:49 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 08 May 2013, at 08:13, Bruce Tulloch wrote: After a random but very long period of time (i.e. very many successful calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref. GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's reference is to be decremented) is nil (i.e. 0x0). Prima facie, that's the reason for the SEGV, but how is it possible that the compiler would pass a nil pointer to this function the first place? The first thing fpc_AnsiStr_Decr_Ref does is check whether its parameter is nil, and if so it immediately exists. It can be nil in case the ansistring contains an empty string. That routine itself also sets its argument to nil in case this was not the case initially (it's a var-parameter), and I assume your crash happens after this has been done. To put this into context, I'm running FPC 2.6.2 on a 32 bit Linux system executing in a multi-threaded application (which uses python threads and fpc threads). I have not found obvious evidence of memory corruption from other execution contexts or shared memory handling problems. It's nevertheless most likely memory corruption. You can try compiling with -gv and running your program under valgrind to see whether it finds anything (you will probably get some false positives about certain RTL pchar routines such as strscan and strlen, but you can ignore those). Jonas __**_ fpc-pascal maillist - fpc-pascal@lists.freepascal.**orgfpc-pascal@lists.freepascal.org http://lists.freepascal.org/**mailman/listinfo/fpc-pascalhttp://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.6.2 throws SEGV in fpc_AnsiStr_Decr_Ref(). How is this possible?
So here's some more diagnostic at the point of the SEGV: (gdb) disass Dump of assembler code for function _$SYSTEM$_Ll1637: = 0x0118ace1 +0: cmpl $0x0,(%edx) End of assembler dump. (gdb) i reg eax0xb6c77158 -1228443304 ecx0xb6c76c04 -1228444668 edx0xfff8 -8 ebx0x12adbf819586040 esp0xb6c75f5c 0xb6c75f5c ebp0xb6c75f70 0xb6c75f70 esi0xb6c77020 -1228443616 edi0xb6c77020 -1228443616 eip0x118ace10x118ace1 _$SYSTEM$_Ll1637 eflags 0x210293 [ CF AF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) p $eax^ $4 = 0 This tells me that the test at the top of fpc_AnsiStr_Decr_Ref: cmpl $0,(%eax) jne .Ldecr_ref_continue ret .Ldecr_ref_continue: passed (i.e. (%eax) was NOT nil) but sometime during the execution of the following code: // Temps allocated between ebp-24 and ebp+0 subl$4,%esp // Var S located in register // Var l located in register movl%eax,(%esp) // [101] l:=@PAnsiRec(S-FirstOff)^.Ref; movl(%eax),%edx subl$8,%edx // [102] If l^0 then exit; cmpl$0,(%edx) the variable (%eax) MUST have been changed (to nil) BY ANOTHER THREAD. Is there any other plausible explanation I may have missed? If there is no other explanation, then it means I need to find out how the string variable referred to by (%eax) could have been been accessed (or even known to exist) by any other thread in the same address space. If that variable is local to a function (i.e. foo's Result with SEGV upon its assignment immediately it first comes into scope, per my earlier email) then absent a bug in FPC's handling string references and allocation, it seems impossible that it could be known or referenced by any other other thread. I'm reasonably confident there's no other way it could be overwritten by another thread (i.e. I don't think there are any range or buffer pointer errors anywhere else) so logic tells me I must have the wrong thesis or there's a string handling error in FPC. Any clues or insight, gratefully received :-) Cheers, Bruce. PS: I can't use valgrind in practice for a variety of reasons, not the least of which is that I'm not likely to see the error for an extraordinary long time given that slight changes to the (execution time of the) code made so far have had a dramatic effect on the likelihood of the occurrence of this problem at all but it's clearly some sort of race condition over unprotected memory somewhere. On Thu, May 9, 2013 at 9:47 AM, Bruce Tulloch pas...@causal.com wrote: I've not managed to trap it again, but based on the information I have from the last time it occurred I can say the error happened here: --- a/rtl/i386/i386.inc +++ b/rtl/i386/i386.inc @@ -1523,7 +1523,7 @@ movl(%eax),%edx subl$8,%edx // [102] If l^0 then exit; cmpl$0,(%edx) -- SEGV OCCURS HERE jl .Lj3596 .Lj3603: // [104] If declocked(l^) then That is, when testing the string length, the address of the length variable appears to be duff. I don't know what %edx was pointing to at the time (I hope to know next time I trap it) but it was obviously wrong. -b On Thu, May 9, 2013 at 9:33 AM, Bruce Tulloch pas...@causal.com wrote: Thanks Jonas, that confirms what I suspected. Next time I trap an instance of this (rare) fault I will inspect exactly which CPU instruction raised the SEGV inside fpc_AnsiStr_Decr_Ref in search of a source of memory corruption. Bruce. On Wed, May 8, 2013 at 11:49 PM, Jonas Maebe jonas.ma...@elis.ugent.bewrote: On 08 May 2013, at 08:13, Bruce Tulloch wrote: After a random but very long period of time (i.e. very many successful calls) I get a SEGV in the built-in function fpc_AnsiStr_Decr_Ref. GDB reports the argument to fpc_AnsiStr_Decr_Ref (the string who's reference is to be decremented) is nil (i.e. 0x0). Prima facie, that's the reason for the SEGV, but how is it possible that the compiler would pass a nil pointer to this function the first place? The first thing fpc_AnsiStr_Decr_Ref does is check whether its parameter is nil, and if so it immediately exists. It can be nil in case the ansistring contains an empty string. That routine itself also sets its argument to nil in case this was not the case initially (it's a var-parameter), and I assume your crash happens after this has been done. To put this into context, I'm running FPC 2.6.2 on a 32 bit Linux system executing in a multi-threaded application (which uses python threads and fpc threads). I have not found obvious evidence of memory corruption from other execution contexts or shared memory handling problems. It's nevertheless most
[fpc-pascal] Abstract methods called from descendants via Inherited.
This is a minor issue, just a question of design... I understand that by design abstract methods cannot be called and that doing so is an error. However FPC used to allow an abstract method to be called from an overriding descendant method without any error (and without doing anything useful, of course). More recently it doesn't allow this. It seems to me the earlier behaviour is more desirable because it means one can write the overriding method in decedent classes in such a way that this method can call inherited without knowing if it's abstract or not. The new behaviour means that the overriding method in all (first) decedent classes must be modified (to call the inherited method) if the parent class with the abstract method is changed (or a new class inserted in between) which makes the abstract method a concrete one. If the compiler silently ignored calls to abstract methods, when made from an overriding method, this problem would be avoided and one could change inherited behaviour in the parent class without affecting the descendant classes (which usually call the inherited method at some point). A simple work-around is to make the abstract method a do nothing real one in the first place, but then one looses the benefits of the abstract error raised when another (unrelated) object calls the (unimplemented) method. Am I misunderstanding something here? Why is it done the way it is done now? Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Linker fails cross compiling from Linux to Mac.
I had a working Debian Squeeze to Mac OSX Snow Leopard cross- compilation system working. It's documented here: http://wiki.freepascal.org/Cross_compiling_OSX_on_Linux Unfortunately the method described on that page is now broken. The problem linking for OSX on a Linux no longer works for me. It produces errors like these: i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libiconv.dylib load command 5 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libobjc.dylib load command 7 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/usr/lib/libc.dylib load command 5 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Carbon load command 4 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Cocoa.framework/Cocoa load command 4 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL load command 5 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Foundation.framework/Foundation load command 6 unknown cmd field Here's what I'm using: 1) FPC 2.6.2 rc1 (and I've tried 2.6.0 as well). 2) Apple's cctools 809 release suitably patched. 3) A Debian Wheezy Linux host. The cctools-809 source comes from: http://www.opensource.apple.com/tarballs/cctools/cctools-809.tar.gz The patch applied to make it buildable for Linux is: https://github.com/mingwandroid/xchain/blob/master/patches/cctools-809-nondarwin.patch plus a few tweaks of my own to fix some build bugs. It's built against MacOSX10.6.sdk (I've tried MacOSX10.5.sdk too) for 32 bit (-m32) builds (64 bit is not supported). FPC, FCL, LCL et al are all built against the same SDK. Compilation works just but linking fails as shown above. I've tried various combination of compilation switches but nothing seems to allow the link to succeed. Does anyone have a clue why this might be failing? I seems like I'm on the brink of success if only I can work out why these errors are occurring. The most obvious thought is that not all objects were built against the same revision of the SDK but I can confirm they are. The missing command codes are (from MacOSX10.6.sdk/usr/include/mach-o/loader.h): #define LC_THREAD 0x4 /* thread */ #define LC_UNIXTHREAD 0x5 /* unix thread (includes a stack) */ #define LC_LOADFVMLIB 0x6 /* load a specified fixed VM shared library */ #define LC_IDFVMLIB0x7 /* fixed VM shared library identification */ I will give up on this if no one has any ideas and the wiki needs to be updated to report that cross-compilation from Linux to Mac is no longer possible but I'm willing to give it some more work based on pointers anyone can suggest. Failing that I will revert to a native Mac system but I'd really like to have cross-compilation working if possible. Any suggestions? Bruce ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linker fails cross compiling from Linux to Mac.
On Tue, Jan 8, 2013 at 9:04 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 08 Jan 2013, at 10:49, Bruce Tulloch wrote: I had a working Debian Squeeze to Mac OSX Snow Leopard cross- What had changed when it stopped working? I had to upgrade from Debian Sneeze to Wheezy (for other reasons) and the previously built odcctools linker (derived from the older cctools-758) required libraries no longer available in Wheezy which required that I rebuild it from source but the long dead odcctools source was no longer available so I rebuilt from Apple's upstream cctools-809 with the new patches. This suggests that you are using a linker that is too old. Should be okay, cctool-809 is 10.6 aware (the get_macosx_deployment_target() function in the linker reports 10.6 when run). Are you certain that the used i386-darwin-ld is the one you built from cctools-809? Yep, I already checked this. ppas.sh reports /usr/local/opt/cctools/bin/i386-darwin-ld which is correct. The linker is built with this script (working in a repository I created): #!/bin/bash # Compilation parameters, adjust as required... export TARGET=i386-darwin # OSX target (i386-darwin or x86_64-darwin) export SYSROOT=/usr/local/opt/osx/MacOSX10.6.sdk # OSX SDK root export CCTOOLS=809 # OSX cctools version (must be a patched for linux) export PREFIX=/usr/local/opt/cctools # build host installation directory cd cctools # working repository # Checkout revision and patch hg update -C cctools-$CCTOOLS hg -R $(hg root)/.hg/patches update -C cctools-$CCTOOLS hg qpush --all # configure and build autoconf chmod +x configure CFLAGS=-m32 -D__DARWIN_UNIX03 LDFLAGS=-m32 ./configure \ --prefix=$PREFIX \ --target=$TARGET \ --with-sysroot=$SYSROOT \ make make install # cleanup hg update -C hg qpop --all hg clean The most obvious thought is that not all objects were built against the same revision of the SDK but I can confirm they are. That has no influence anyway. Objects are not really built against an SDK, only libraries and applications are. The SDK only affects the linking in case of Pascal (in case of C/C++, it also affects the compilation because of the used headers). Thanks, understood. It's linking the application that presents the problem. I've noticed that all errors except these two: i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Carbon load command 4 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL load command 5 unknown cmd field disappear IF I enable debug symbols when compiling. Don't know if this is a clue and it does not appear to matter which type of debug info I enable. Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linker fails cross compiling from Linux to Mac.
Any other thoughts as to what I should do or information I can provide to help diagnose this further? It would be a shame to loose the ability to cross compile to Mac. Bruce. On Jan 8, 2013 10:07 PM, Bruce Tulloch pas...@causal.com wrote: On Tue, Jan 8, 2013 at 9:04 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 08 Jan 2013, at 10:49, Bruce Tulloch wrote: I had a working Debian Squeeze to Mac OSX Snow Leopard cross- What had changed when it stopped working? I had to upgrade from Debian Sneeze to Wheezy (for other reasons) and the previously built odcctools linker (derived from the older cctools-758) required libraries no longer available in Wheezy which required that I rebuild it from source but the long dead odcctools source was no longer available so I rebuilt from Apple's upstream cctools-809 with the new patches. This suggests that you are using a linker that is too old. Should be okay, cctool-809 is 10.6 aware (the get_macosx_deployment_target() function in the linker reports 10.6 when run). Are you certain that the used i386-darwin-ld is the one you built from cctools-809? Yep, I already checked this. ppas.sh reports /usr/local/opt/cctools/bin/i386-darwin-ld which is correct. The linker is built with this script (working in a repository I created): #!/bin/bash # Compilation parameters, adjust as required... export TARGET=i386-darwin # OSX target (i386-darwin or x86_64-darwin) export SYSROOT=/usr/local/opt/osx/MacOSX10.6.sdk # OSX SDK root export CCTOOLS=809 # OSX cctools version (must be a patched for linux) export PREFIX=/usr/local/opt/cctools # build host installation directory cd cctools # working repository # Checkout revision and patch hg update -C cctools-$CCTOOLS hg -R $(hg root)/.hg/patches update -C cctools-$CCTOOLS hg qpush --all # configure and build autoconf chmod +x configure CFLAGS=-m32 -D__DARWIN_UNIX03 LDFLAGS=-m32 ./configure \ --prefix=$PREFIX \ --target=$TARGET \ --with-sysroot=$SYSROOT \ make make install # cleanup hg update -C hg qpop --all hg clean The most obvious thought is that not all objects were built against the same revision of the SDK but I can confirm they are. That has no influence anyway. Objects are not really built against an SDK, only libraries and applications are. The SDK only affects the linking in case of Pascal (in case of C/C++, it also affects the compilation because of the used headers). Thanks, understood. It's linking the application that presents the problem. I've noticed that all errors except these two: i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/Carbon.framework/Carbon load command 4 unknown cmd field i386-darwin-ld: MacOSX10.6.sdk/System/Library/Frameworks/OpenGL.framework/OpenGL load command 5 unknown cmd field disappear IF I enable debug symbols when compiling. Don't know if this is a clue and it does not appear to matter which type of debug info I enable. Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: FPC's broken cross-compiler directory structure?
Thanks, but that's what the make file appears to do already (crossinstall into a local target which is then zipped). If this problem is not affecting anyone else I'll not worry about it it as I've coded a simple script to work around the problem when installing on my system here. Bruce. On Tue, Jan 8, 2013 at 10:31 PM, leledumbo leledumbo_c...@yahoo.co.id wrote: I never use [cross]zipinstall so I have no idea about it, make [cross]install produce the correct directory structure. Perhaps you can [cross]install first then manually zip the result. -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/FPC-s-broken-cross-compiler-directory-structure-tp5712491p5712504.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC's broken cross-compiler directory structure?
I build FPC cross-compilers for Windows, Macintosh and (32 bit) Linux on a
Debian Wheezy 64 bit host.
There appears to be a bug in the build process that produces dodgy
*crosszipinstall
tarballs* for Windows.
This applies to FPC 2.6.0, 2.6.2 RC1 and 2.7.1 (today's SVN head). It's
completely broken in 2.7.1 so I'll ignore that.
Below is the *build script* and the (filtered) *directory layout* of each
tarball produced when building 2.6.2 RC 1.
*fpc-2.6.2rc1.x86_64-linux.tar.gz* is the native compiler. All the others
are all cross-compilers.
Both windows compilers have directory structures that are different and
seem to be wrong.
They do not appear to map where *fpc* expects to find *ppcross386* and *
ppcrossx64* compilers (i.e. *lib/fpc/2.6.2*) and instead they are located
in *bin/arch/*. Further, the tarball cannot simply be unpacked at the
installation root (e.g. /usr/local) to have everything put in the correct
place.
I can manually work around this problem but am I missing something?
Is this installation difference intentional?
Is there some additional option required when building cross compilers for
Windows?
Many thanks, Cheers, Bruce.**
*Build Script...*
# Build Mac OSX 10.6 64 Bit...make distclean /dev/nulltime make
crossall crosszipinstall \CPU_TARGET=x86_64 OS_TARGET=darwin
\CROSSBINDIR=/usr/local/opt/cctools/bin \BINUTILSPREFIX=i686-darwin-
\OPT=-gl -gw -godwarfsets -XX -CX -Xd -Fl${OSX_SDK_LIB}
# Build Mac OSX 10.6 32 Bit...make distclean /dev/nulltime make
crossall crosszipinstall \CPU_TARGET=i386 OS_TARGET=darwin
\CROSSBINDIR=/usr/local/opt/cctools/bin \BINUTILSPREFIX=i686-darwin-
\OPT=-gl -gw -godwarfsets -XX -CX -Xd -Fl${OSX_SDK_LIB}
# Build Windows 8 64 Bit...make distclean /dev/nulltime make crossall
crosszipinstall \CPU_TARGET=x86_64 OS_TARGET=win64
\CROSSBINDIR=/usr/local/opt/binutils/bin \BINUTILSPREFIX=i386-mingw-
\OPT=-XX -CX
# Build Windows 8 32 Bit...make distclean /dev/nulltime make crossall
crosszipinstall \CPU_TARGET=i386 OS_TARGET=win32
\CROSSBINDIR=/usr/local/opt/binutils/bin \BINUTILSPREFIX=i386-mingw-
\OPT=-XX -CX
# Build Linux 32 Bit...make distclean /dev/nulltime make crossall
crosszipinstall \CPU_TARGET=i386 OS_TARGET=linux
\CROSSBINDIR=/usr/local/opt/binutils/bin \BINUTILSPREFIX=i386-linux-
\OPT=-XX -CX
# Build (native) Linux 64 Bit...make distclean /dev/nulltime make all
zipinstall
*Directory Layout...*
bruce@beria:~/hg/pascal$ tar tvfz fpc-2.6.2rc1.i386-win32.tar.gz #
cross compiler (wrong layout?)
drwxr-xr-x bruce/bruce 0 2013-01-07 16:03 bin/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:03 bin/x86_64-linux/
-rwxr-xr-x bruce/bruce 2760664 2013-01-07 16:03 bin/x86_64-linux/ppcross386
drwxr-xr-x bruce/bruce 0 2013-01-07 16:03 units/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:03
units/i386-win32/bruce@beria:~/hg/pascal$ tar tvfz
fpc-2.6.2rc1.i386-darwin.tar.gz # cross compiler (correct layout)
drwxr-xr-x bruce/bruce 0 2013-01-07 16:00 bin/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:00 lib/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:00 lib/fpc/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:00 lib/fpc/2.6.2/
-rwxr-xr-x bruce/bruce 8376619 2013-01-07 16:00 lib/fpc/2.6.2/ppcross386
drwxr-xr-x bruce/bruce 0 2013-01-07 16:00 lib/fpc/2.6.2/units/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:00
lib/fpc/2.6.2/units/i386-darwin/bruce@beria:~/hg/pascal$ tar tvfz
fpc-2.6.2rc1.i386-linux.tar.gz # cross compiler (correct layout)
drwxr-xr-x bruce/bruce 0 2013-01-07 16:04 bin/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:04 lib/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:04 lib/fpc/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:04 lib/fpc/2.6.2/
-rwxr-xr-x bruce/bruce 2760664 2013-01-07 16:04 lib/fpc/2.6.2/ppcross386
drwxr-xr-x bruce/bruce 0 2013-01-07 16:04 lib/fpc/2.6.2/units/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:04
lib/fpc/2.6.2/units/i386-linux/bruce@beria:~/hg/pascal$ tar tvfz
fpc-2.6.2rc1.x86_64-win64.tar.gz # cross compiler (wrong layout?)
drwxr-xr-x bruce/bruce 0 2013-01-07 16:01 bin/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:01 bin/x86_64-linux/
-rwxr-xr-x bruce/bruce 2471768 2013-01-07 16:01 bin/x86_64-linux/ppcrossx64
drwxr-xr-x bruce/bruce 0 2013-01-07 16:01 units/
drwxr-xr-x bruce/bruce 0 2013-01-07 16:01
units/x86_64-win64/bruce@beria:~/hg/pascal$ tar tvfz
fpc-2.6.2rc1.x86_64-darwin.tar.gz # cross compiler (correct layout)
drwxr-xr-x bruce/bruce 0 2013-01-07 15:58 bin/
drwxr-xr-x bruce/bruce 0 2013-01-07 15:58 lib/
drwxr-xr-x bruce/bruce 0 2013-01-07 15:58 lib/fpc/
drwxr-xr-x bruce/bruce 0 2013-01-07 15:58 lib/fpc/2.6.2/
drwxr-xr-x bruce/bruce 0 2013-01-07 15:58 lib/fpc/2.6.2/units/
drwxr-xr-x bruce/bruce 0 2013-01-07 15:58
lib/fpc/2.6.2/units/x86_64-darwin/
-rwxr-xr-x bruce/bruce 7773587 2013-01-07 15:58
lib/fpc/2.6.2/ppcrossx64bruce@beria:~/hg/pascal$ tar tvfz
fpc-2.6.2rc1.x86_64-linux.tar.gz # native installation (correct
layout)
drwxr-xr-x bruce/bruce
Re: [fpc-pascal] Cross compiling x86_64 on i386 Linux.
On 31/05/12 17:59, Jonas Maebe wrote: You can try filing a bug with binutils of course, but I don't think it will be considered a bug (although you can always ask to add an option to get the behaviour you want). Thanks Jonas, I agree that this is not likely to be considered a bug by GNU but would be nice to have as an option for ld. I might suggest it. Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross compiling x86_64 on i386 Linux.
On 31/05/12 01:40, Jonas Maebe wrote: I'm thinking that ld should be looking at: /mnt/engels/lib/libpthread.so.0 but according to the error message it's looking at: /lib/libpthread.so.0 which read literally would explain the error. That's correct. It seems that -XR isn't completely implemented on Linux in the compiler. Could you try, *instead* of using -XR, to use -k--sysroot=/full/path/to/crossroot/ ? I replaced the -XR option with -k--sysroot=/mnt/engels and that works (ie, you are correct, -XR does not appear to pass the sysroot to the linker) but there's another catch. Now I'm getting: x86_64-linux-ld: skipping incompatible /mnt/engels/usr/lib64/libdl.so when searching for -ldl this library (on /mnt/engels) **is compatible** but it is a symlink: /usr/lib64/libdl.so - /lib/libdl.so.2 Given the specified --sysroot the linker should be looking at /mnt/engels/lib/libdl.so.2 but I'm guessing it's looking at /lib/libdl.so.2 which does not right to me. It looks like --sysroot is not analogous to chroot as far as the linker is concerned and symlinks are dereferenced literally. For completeness I added -XR/mnt/engels as well, so all the (other) linker search paths are prepended with /mnt/engels. This ended up producing a slightly errnoeous message: x86_64-linux-ld: skipping incompatible /mnt/engels/usr/lib64 //libdl.so when searching for -ldl Note the // in the reported path name before libdl.so. This time it also reported the same error for glibc: x86_64-linux-ld: skipping incompatible /mnt/engels/usr/lib64//libglib- 2.0.so when searching for -lglib-2.0 again with the erroneous //. This glibc library is also a symlink to the /lib directory on engels. I tried adding -k-rpath-link options to tell the linker to look in the relevant paths under /mnt/engels but all to no avail. Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross compiling x86_64 on i386 Linux.
In follow up, I updated and rebuilt the latest binutils http://ftp.gnu.org/gnu/binutils/binutils-2.22.tar.gz and tried the patch associated with this bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=10340 to see if my problem was due to this bug. It does not appear to be: the link problem I've described remains true. I'm thinking Tony Whyman's suggestion (building inside a chroot on a 64/32 bit host platform) is probably the best way forward for me now but there does look like there's a problem with FPC (i.e. handling of -XR apropos the ld) and GNU ld (i.e. the failure to prepend sysroot for symlink dereferenced library files). If you concur on the latter point, perhaps it might be worth reporting upstream to GNU? Bruce. On 31/05/12 10:39, Bruce Tulloch wrote: On 31/05/12 01:40, Jonas Maebe wrote: I'm thinking that ld should be looking at: /mnt/engels/lib/libpthread.so.0 but according to the error message it's looking at: /lib/libpthread.so.0 which read literally would explain the error. That's correct. It seems that -XR isn't completely implemented on Linux in the compiler. Could you try, *instead* of using -XR, to use -k--sysroot=/full/path/to/crossroot/ ? I replaced the -XR option with -k--sysroot=/mnt/engels and that works (ie, you are correct, -XR does not appear to pass the sysroot to the linker) but there's another catch. Now I'm getting: x86_64-linux-ld: skipping incompatible /mnt/engels/usr/lib64/libdl.so when searching for -ldl this library (on /mnt/engels) **is compatible** but it is a symlink: /usr/lib64/libdl.so - /lib/libdl.so.2 Given the specified --sysroot the linker should be looking at /mnt/engels/lib/libdl.so.2 but I'm guessing it's looking at /lib/libdl.so.2 which does not right to me. It looks like --sysroot is not analogous to chroot as far as the linker is concerned and symlinks are dereferenced literally. For completeness I added -XR/mnt/engels as well, so all the (other) linker search paths are prepended with /mnt/engels. This ended up producing a slightly errnoeous message: x86_64-linux-ld: skipping incompatible /mnt/engels/usr/lib64 //libdl.so when searching for -ldl Note the // in the reported path name before libdl.so. This time it also reported the same error for glibc: x86_64-linux-ld: skipping incompatible /mnt/engels/usr/lib64//libglib- 2.0.so when searching for -lglib-2.0 again with the erroneous //. This glibc library is also a symlink to the /lib directory on engels. I tried adding -k-rpath-link options to tell the linker to look in the relevant paths under /mnt/engels but all to no avail. Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross compiling x86_64 on i386 Linux.
Hi Tony, I use Debian as my Debian derived distro :-) I agree a minimal chroot environment for each target is a good solution but it's predicated on running a 64-bit kernel on the host (which I am trying to avoid so I can use this setup on a 32-bit capable netbook). Looks like I might have to abandon the idea (cross compiling for a x86_64 target on a i386 host) and upgrade my mobile development platform to something with an x86_64 capable CPU in it :-/ I'll see if Jonas has any more ideas. Cheers, Bruce. On 29/05/12 18:40, Tony Whyman wrote: Bruce, If you are using a Debian derived distribution such as Ubuntu, you might find it easier to use debootstrap to create a 64 bit environment on your system and compile the program in that environment (see https://help.ubuntu.com/community/DebootstrapChroot for a guide). Then you can be sure that you have all the correct libraries in their standard paths, etc. In my set up, I compile for both 64 bit and 32 bit targets on a 64 bit machine and have separate debootstrap (chroots) for each target environment rather than compile in the development environment. This ensures that the final compilation takes place in a known clean environment. I also have a chroot for a win32 cross compiler. Once you have created the chroot for each target, all you need to do is to install the fpc debs in the appropriate environment (64 bit fpc for the 64 bit environment, 32 bit for the 32 bit environment), install any other libraries you need for the distribution repository and then compile the software in each chroot separately. The result will be executables built for each target and built in a clean environment. If you also want to generate distribution packages (debs), this is also the best way to go about it. Regards Tony Whyman MWA Software On 29/05/12 03:19, Bruce Tulloch wrote: Closer, but not quite there yet... To get this going I've (sshfs) mounted a 64 bit system on /mnt/engels and then attempted to cross-compile on the 32 bit system with: fpc -MDelphi -Scgi -CX -O3 -OoUNCERTAIN -OoREGVAR \ -Tlinux -Px86_64 -Xs -XX -va -l \ -dLCL -dLCLgtk2 -XR/mnt/engels This compiles but fails at the linker: Searching file /mnt/engels/usr/lib64/crtn.o... found Searching file /usr/local/opt/binutils/bin/x86_64-linux-ld... found Using util /usr/local/opt/binutils/bin/x86_64-linux-ld /usr/local/opt/binutils/bin/x86_64-linux-ld: skipping incompatible /lib/libpthread.so.0 when searching for /lib/libpthread.so.0 /usr/local/opt/binutils/bin/x86_64-linux-ld: cannot find /lib/libpthread.so.0 Error: Error while linking Fatal: There were 1 errors compiling module, stopping The linker /usr/local/opt/binutils/bin/x86_64-linux-ld was created using (an appropriately modified) fpcfixes_2.6/cross/buildcrossbinutils i.e. built to run on i386 and target x86_64 MYINTEL=i386 TARGETS_X86_64=linux and the pthread library is (presumably, given the -XR option) /mnt/engels/lib/libpthread.so which file reports as libpthread-2.11.3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped How can I find out why x86_64-linux-ld reports it as incompatible? Many thanks, Bruce. On 05/28/12 23:02, Jonas Maebe wrote: On 28 May 2012, at 14:56, Bruce Tulloch wrote: Am I correct to assume that if I drag in the x86_64 libraries I need from another x86_64 system, put them in a local directory and then reference then using the -XR option I can make this setup work? -XR is for pointing the compiler/linker to the top of a complete sysroot (i.e., a hierarchy with /lib, /usr/lib etc), not to a directory with just few handpicked libraries. For the latter, use the -Fl command line switch instead, possibly combined with -Xd (to prevent the compiler from passing the default system directories as search paths to the linker). And yes, that should indeed work fine. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Cross compiling x86_64 on i386 Linux.
Thanks Jonas, I tried --with-sysroot for configure in buildcrossbinutils and it does not appear to make any difference. I still get the error /usr/local/opt/binutils/bin/x86_64-linux-ld: skipping incompatible /lib/libpthread.so.0 when searching for /lib/libpthread.so.0 at the link phase. I'm thinking that ld should be looking at: /mnt/engels/lib/libpthread.so.0 but according to the error message it's looking at: /lib/libpthread.so.0 which read literally would explain the error. FWIW I have attached the buildcrossbinutils build log in case there's a clue in there. Unless you have any other suggestions I might just give up and upgrade my mobile development environment to an x86_64 capable netbook and run a mixed 64/32 bit system to build 64 bit (and 32 bit) targets. I'm guessing not many people attempt to do it the other way around these days so I might as well join the 64 bit party... Cheers, Bruce. On 29/05/12 18:45, Jonas Maebe wrote: Bruce Tulloch wrote on Tue, 29 May 2012: Closer, but not quite there yet... [...] fpcfixes_2.6/cross/buildcrossbinutils Try adding --with-sysroot to the configure flags in that script. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal log-x86_64-linux.gz Description: application/gzip ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Cross compiling x86_64 on i386 Linux.
Is it possible to cross-compile a Linux/x86_64 target on a Linux/i386 host? AFAICT it should be possible and I've almost got it working (using Debian's gcc-4.4-multilib for start-up code) but the linker looks for x86_64 libraries that aren't available on a i386 system. I'm guessing that libraries for x86_64 do not exist on most i386 distributions (since one can't run x86_64 binaries on a i386 CPU). Normally one would cross-compile a i386 target on a x86_64 host and use the i386 compatibility libraries. I want to do it the other way around (to be able to work on an Atom netbook that does not run x86_64). Am I correct to assume that if I drag in the x86_64 libraries I need from another x86_64 system, put them in a local directory and then reference then using the -XR option I can make this setup work? Many thanks, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC mysteriously fails to find a specified path.
I have a project in the directory: /home/bruce/project which has sub-directories: src lib Both are specified in Lazarus' Other Unit Files: src;lib but verbose message when attempting to compile the project produces the following excerpt: Handling option -Fu/home/bruce/project/src interpreting option -Fu/home/bruce/project/src Path ./src/ not found Handling option -Fu/home/bruce/project/lib interpreting option -Fu/home/bruce/project/lib Using unit path: ./lib/ That is, FPC fails to find the src directory but succeeds to find the lib directory. Both directories exist and are in all respects except their names identical. Something is blocking FPC from finding src because it's called src. I've tried other directory names and some work and others don't. I've detected a pattern to it yet. This problem occurs using the Ubuntu 11.10 (Unity) packaged versions of FPC and Lazarus. If I use Lazarus SVN trunk on a Debian Squeeze machine (with FPC 2.4.2) it all works fine. Is this an FPC 2.4.4 bug or some sort of error on my part? Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: FPC mysteriously fails to find a specified path.
Okay, worked it out, main project directory was remotely mounted (from a CIFS share) and there's clearly some sort of problem in the Ubuntu case with I/O (Debian seems to be okay when the same share is mounted there, hmm). -b On 11/11/11 15:36, Bruce Tulloch wrote: I have a project in the directory: /home/bruce/project which has sub-directories: src lib Both are specified in Lazarus' Other Unit Files: src;lib but verbose message when attempting to compile the project produces the following excerpt: Handling option -Fu/home/bruce/project/src interpreting option -Fu/home/bruce/project/src Path ./src/ not found Handling option -Fu/home/bruce/project/lib interpreting option -Fu/home/bruce/project/lib Using unit path: ./lib/ That is, FPC fails to find the src directory but succeeds to find the lib directory. Both directories exist and are in all respects except their names identical. Something is blocking FPC from finding src because it's called src. I've tried other directory names and some work and others don't. I've detected a pattern to it yet. This problem occurs using the Ubuntu 11.10 (Unity) packaged versions of FPC and Lazarus. If I use Lazarus SVN trunk on a Debian Squeeze machine (with FPC 2.4.2) it all works fine. Is this an FPC 2.4.4 bug or some sort of error on my part? Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Non-standard baud rates in OS X | IOSSIOSPEED IOCTL
I can now confirm that the ioctl definition I used is correct, tested on a Snow Leopard system with an FT232RL chip USB/Serial chip. Cheers, Bruce. On 08/15/11 15:23, Bruce Tulloch wrote: Apple have define an IOCTL (since Tiger) called IOSSIOSPEED which facilitates non-standard baud rates. They publish a C example which explains it: http://developer.apple.com/library/mac/#samplecode/SerialPortSample/Introduction/Intro.html Attached is a patch for FPC's darwin RTL which adds this IOCTL. I think it's correct (i.e. it evaluates to the same value, 0x80045402, as some C I threw together using Apple's headers, see attached). I've appended this definition in termios.inc as this seems the most appropriate place for it. Jonas? Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Non-standard baud rates in OS X | IOSSIOSPEED IOCTL
Apple have define an IOCTL (since Tiger) called IOSSIOSPEED which
facilitates non-standard baud rates.
They publish a C example which explains it:
http://developer.apple.com/library/mac/#samplecode/SerialPortSample/Introduction/Intro.html
Attached is a patch for FPC's darwin RTL which adds this IOCTL.
I think it's correct (i.e. it evaluates to the same value, 0x80045402,
as some C I threw together using Apple's headers, see attached).
I've appended this definition in termios.inc as this seems the most
appropriate place for it. Jonas?
Cheers, Bruce.
*** a/rtl/darwin/termios.inc Mon Aug 15 15:05:10 2011
--- b/rtl/darwin/termios.inc Mon Aug 15 15:05:10 2011
***
*** 601,605
--- 601,609
FIOGETOWN = (IOC_OUT or (sizeof(cint) and IOCPARM_MASK) 16) or ((ord('f') 8) or 123);
FIODTYPE = (IOC_OUT or (sizeof(cint) and IOCPARM_MASK) 16) or ((ord('f') 8) or 122);
+ // from /System/Library/Frameworks/IOKit.framework/Versions/A/Headers/serial/ioss.h
+
+ FIOSSIOSPEED = (IOC_IN or (sizeof(culong) and IOCPARM_MASK) 16) or ((ord('T') 8) or 2);
+
{$endif}
#include stdio.h
#define IOCPARM_MASK 0x1fff /* parameter length, at most 13 bits */
#define IOC_IN (unsigned long)0x8000
#define _IOC(inout,group,num,len) \
(inout | ((len IOCPARM_MASK) 16) | ((group) 8) | (num))
#define _IOW(g,n,t) _IOC(IOC_IN, (g), (n), sizeof(t))
#define IOSSIOSPEED_IOW('T', 2, speed_t)
typedef unsigned long speed_t;
int main()
{
printf(IOSSIOSPEED = 0x%x\n,IOSSIOSPEED);
return 0;
}
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Where's my OSX window dressing?
I'm new to OSX so bear with me. Something has changed but I can't tell what. The consequence is that my Lazarus/FPC generated OSX applications are now missing their window dressing? It's like the OSX window manager has gone AWOL when I run my Lazarus apps. That is, the apps run fine but they run without a window title and they are located under the desktop menu, top left of the screen, from where they cannot be relocated. What's missing? What am I doing differently? How does Lazarus/FPC manage this stuff apropos the OSX window manager? I've done a clean rebuild thinking there may be something wrong with the Application Bundle previously created by Lazarus but recreating it does not seem to make any difference. Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] The fpOpen call on a serial port blocks on a Mac. Why? [SOLVED]
Thanks Henry, I've found the problem, more than one actually. For the record if anyone else runs into this is that the red-herring here was another bug in synaser.pas (007.005.002) where an incorrect ioctl call is made (in Darwin), fixed on line 1939 with: - SerialCheck(fpioctl(FHandle, TCIOflush, TCIOFLUSH)); + SerialCheck(fpioctl(FHandle, TCIOflush, Pointer(PtrInt(TCIOFLUSH; This bug resulted in the purge that's called after the port is opened to fail resulting in my client code being erroneously told the open failed. Inspection of errno revealed the real problem (EINVAL). Thanks for the tips and just to confirm the open call I now use (on line 946) which works in Darwin (subject to the ioctl fix above) is: FHandle := THandle(fpOpen(FDevice, O_RDWR or O_SYNC or O_NONBLOCK)); which opens successfully and allows the other termio flags to then be set appropriately. My earlier comments about ENOTTY were erroneous. Bruce. On 08/11/11 18:54, Henry Vermaak wrote: On 11/08/11 05:00, Bruce Tulloch wrote: I am using the latest synaser (007.005.002) from the synapse library which works just fine with (USB) serial ports on Linux and Windows but Mac OSX 10.6 it is proving problematic. The call which opens the port (synaser.pas:946) is: FHandle := THandle(fpOpen(FDevice, O_RDWR or O_SYNC)); where in my case, FDevice is /dev/tty.usbserial.DCUIYCH4. This fpOpen call blocks indefinitely (i.e. it never returns). The device is present, working and requires no flow control: My-Mac:~ admin$ stty -f /dev/tty.usbserial-DCUIYCH4 -a speed 9600 baud; 0 rows; 0 columns; lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -iutf8 -ignbrk -brkint -inpck -ignpar -parmrk oflags: -opost -onlcr -oxtabs -onocr -onlret cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol =undef; eol2 =undef; erase = ^?; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; Have you tried setting clocal under oflags? If open thinks it's a modem, then it can block until it sees carrier detection. I notice that my serial ports have clocal set. and the screen command opens and communicates via this port just fine so I don't believe there is anything wrong with the device, the driver or the state of any port flags when fpOpen is attempted. Can anyone tell me what I might be doing wrong here? Note that adding the O_NONBLOCK flag allows the fpOpen to succeed but all subsequent attempts to talk to the port return ENOTTY which is of course wrong as it is a real (USB) serial (TTY) device. This should have helped for the modem issue. Did you remove the O_SYNC? Maybe setting clocal after opening will help? Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] The fpOpen call on a serial port blocks on a Mac. Why?
I am using the latest synaser (007.005.002) from the synapse library which works just fine with (USB) serial ports on Linux and Windows but Mac OSX 10.6 it is proving problematic. The call which opens the port (synaser.pas:946) is: FHandle := THandle(fpOpen(FDevice, O_RDWR or O_SYNC)); where in my case, FDevice is /dev/tty.usbserial.DCUIYCH4. This fpOpen call blocks indefinitely (i.e. it never returns). The device is present, working and requires no flow control: My-Mac:~ admin$ stty -f /dev/tty.usbserial-DCUIYCH4 -a speed 9600 baud; 0 rows; 0 columns; lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -iutf8 -ignbrk -brkint -inpck -ignpar -parmrk oflags: -opost -onlcr -oxtabs -onocr -onlret cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow -dtrflow -mdmbuf cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = undef; eol2 = undef; erase = ^?; intr = ^C; kill = ^U; lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W; and the screen command opens and communicates via this port just fine so I don't believe there is anything wrong with the device, the driver or the state of any port flags when fpOpen is attempted. Can anyone tell me what I might be doing wrong here? Note that adding the O_NONBLOCK flag allows the fpOpen to succeed but all subsequent attempts to talk to the port return ENOTTY which is of course wrong as it is a real (USB) serial (TTY) device. I'm building with FPC 2.4.2 binaries and sources (for Mac) and it's an FTDI serial device I'm dealing with. Any and all advice most welcome. Cheers, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Cross Compiling from Linux to a Mac OS X 10.5 or 10.6 target. How? [SOLVED]
Brilliant, thanks Reinier, it looks good. Cheers, Bruce. On 08/08/11 23:03, Reinier Olislagers wrote: On 6-8-2011 15:28, Causal Lists wrote: I finally managed to get Intel Mac OS X cross-compilation (from Linux) working well so I thought I'd document what I did for the benefit of others because the info in the wiki is wildly out of date. I'll update the wiki (if I can) to point to this message. snip Cheers, Bruce. Bruce, Thanks for your post. I've taken the liberty to start the wiki page as I'm trying it out. See http://wiki.lazarus.freepascal.org/Cross_compiling_OSX_on_Linux Regards, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Cross Compiling from Linux to a Mac OS X 10.5 or 10.6 target. How? [SOLVED]
Indeed. I have retained a 32 bit system for my main development host for the time being due to issues such as this (not that I knew of this particular problem). I'll be interested to see what solutions you find work as I do plan to migrate to 64 bits soon. Good to know what I'm up against. FWIW, the cross-compiled bundle generated by my new setup does appear to run okay on a 64-bit Mac -b On 08/09/11 18:46, Reinier Olislagers wrote: My pleasure - though I haven't finished yet may run into things. It seems you're setting up a 32 bit environment. Both my Linux (Debian) and OSX machine are 64 bit - don't know if this will work. Anyway, I'll get back on the list if I have problems... Reinier On 9-8-2011 10:28, Bruce Tulloch wrote: Brilliant, thanks Reinier, it looks good. Cheers, Bruce. On 08/08/11 23:03, Reinier Olislagers wrote: http://wiki.lazarus.freepascal.org/Cross_compiling_OSX_on_Linux ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Cross Compiling from Linux to a Mac OS X 10.5 or 10.6 target. How?
So I've got cross-compilation working but I have one last problem.
I can't seem to get fpc to drive the linker to search the SDK path
BEFORE the default paths. Specifically, i386-darwin-ld finds
/usr/lib/crt1.o
and NOT
/opt/MacOSX10.5.sdk/usr/lib/crt1.o
despite fpc being passed the option
-k-L/opt/MacOSX10.5.sdk/usr/lib
on the command line. I'm using Free Pascal Compiler version 2.4.2
[2011/06/07] for i386 and the complete command line is:
fpc \
-MDelphi \
-Scagi \
-O3 \
-Tdarwin \
-Pi386 \
-k-L/opt/MacOSX10.5.sdk/usr/lib \
-vew \
-l \
-Fi${BUILD}/i386/darwin/carbon \
-Fl/opt/MacOSX10.5.sdk/usr/lib \
-Fusrc \
-Fu${LAZARUS}/lcl/units/i386-darwin \
-Fu${LAZARUS}/lcl/units/i386-darwin/carbon \
-Fu${LAZARUS}/packager/units/i386-darwin \
-FU${BUILD}/i386/darwin/carbon/ \
-FE${BUILD}/ \
-oProject \
-gw \
-godwarfsets \
-dLCL \
-dLCLcarbon \
Project.lpr
I know it works because if I temporarily rename /usr/lib/crt1.o the
linker finds the correct SDK version and links the project properly.
What am I doing wrong that fpc does not appear to put the path
/opt/MacOSX10.5.sdk/usr/lib
ahead of the default paths when calling i386-darwin-ld?
Many thanks, Bruce.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Cross Compiling from Linux to a Mac OS X 10.5 or 10.6 target. How?
Is anyone on the list doing this? If so, how did you set it up? The information on the FPC wiki and elsewhere in the lists is woefully out of date. Many thanks, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Cross Compiling from Linux to a Mac OS X 10.5 or 10.6 target. How?
Thanks for the feedback everyone. I have a Mac on which I can run a native FPC/Lazarus environment for debugging purposes. My goal here is to add a cross compiling build for OS X along side existing Linux and Win32/64 targets so all our OS and CPU targets can be rebuilt at once. So, from what I gather, I can copy the SDK across from my (Leopard) Mac to the Linux build machine and I have found odcctools: http://svn.macosforge.org/repository/odcctools/trunk/ so I should be able to build the toolchain (as, ld). I don't need -Xg/dsymutils (because I using this as build system only) and I can add a clause to /etc/fpc.cfg to include the necessary search paths. I'll give it a go and report back. -b On 08/01/11 17:49, Bruce Tulloch wrote: Is anyone on the list doing this? If so, how did you set it up? The information on the FPC wiki and elsewhere in the lists is woefully out of date. Many thanks, Bruce. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory leaks in FPC 2.3.1 SVN 13188
Hmm, I did. Apparently mantis did not register this? Done it again. Closed now. -b Joost van der Sluis wrote: Op dinsdag 26-05-2009 om 10:16 uur [tijdzone +1000], schreef Bruce Tulloch: Confirmed fixed in r13195 as tested with the application in which this was originally discovered, thanks Jonas. In that case, can you close the bug report? So we know that we don't have to look at this issue anymore? Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory leaks in FPC 2.3.1 SVN 13188
Ok, I don't think that caveat does not applies in this case, we neither call halt nor share these particular variables between threads (we do have threads in this application however). What we do see when freeing (ie, assigning to nil) some of these variables is a jump from recount = 1 (as we expect at this point in our application) to refcount = 7 on some blocks. There is no way (in our application) that there are 7 references to these blocks. We are investigating and report further as soon as we have some more concrete data to feed back to you. Bruce. PS: does the attribute compilerproc mean the function is defined to be called by the compiler implicitly? We have rebuilt the FPC RTL with debug enabled to further diagnose what's happening here (which is why we came across it). Jonas Maebe wrote: On 25 May 2009, at 07:38, Bruce Tulloch wrote: Are we correct to assume that as soon as no variable in our program, be it global, static, object field or property, refers to a dynamic array, the dynamic array will be released. Are we also correct to assume that the reassignment of any variable referring to a dynamic array to a new value will cause the previous array value to be released (presuming nothing else refers to this array)? Yes. One caveat is that the memory may not be immediately released after the last reference that you know of disappears, because there may still be temporary memory locations (implicitly created by the compiler while evaluating expressions) containing a reference. Such temporary locations will be finalised either when they are reused by the compiler later on, or when the function in which they were created by the compiler exits (such temporary locations can never survive the scope in which they were created by the compiler). However, this could only cause the behaviour you are seeing if you were to call halt() somewhere in a deeply nested function and some temporary locations in a parent stack frame still contained references, or of you call halt() while some threads are still running that have local variables/temporaries that point to such variables. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory leaks in FPC 2.3.1 SVN 13188
I think I've nailed and example of the problem; when Copy() is called with the result of another Copy() the reference count for the returned array is not managed correctly when compiled with -MDelphi. A trivial example program, copytest.pas: program copytest; var S, D : array of Integer; begin SetLength(S,4000); D := Copy(Copy(S)); end. which when compiled with: fpc -MDelphi -gl -gh copytest.pas and run produces the following: lenin:$ ./copytest Heap dump by heaptrc unit 3 memory blocks allocated : 48024/48024 2 memory blocks freed : 32016/32016 1 unfreed memory blocks : 16008 True heap size : 262144 True free heap : 246048 Should be : 246072 Call trace for block $B7F4BF50 size 16008 $080480EA main, line 8 of copytest.pas $080657A7 I hope this helps diagnose what's happening here. Note that if compiled without -MDelphi it works correctly but in our case we need to use -MDelphi because our application is also built with Delphi and Kylix3. Cheers, Bruce. Jonas Maebe wrote: On 25 May 2009, at 10:30, Bruce Tulloch wrote: PS: does the attribute compilerproc mean the function is defined to be called by the compiler implicitly? We have rebuilt the FPC RTL with debug enabled to further diagnose what's happening here (which is why we came across it). It means that the procedure becomes invisible to regular Pascal code, and that it gets a particular internal symbol name. Such routines are indeed called implicitly by the compiler for various purposes. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory leaks in FPC 2.3.1 SVN 13188
I've reported this as an FPC bug: http://bugs.freepascal.org/view.php?id=13820 Cheers, Bruce. Bruce Tulloch wrote: I think I've nailed and example of the problem; when Copy() is called with the result of another Copy() the reference count for the returned array is not managed correctly when compiled with -MDelphi. A trivial example program, copytest.pas: program copytest; var S, D : array of Integer; begin SetLength(S,4000); D := Copy(Copy(S)); end. which when compiled with: fpc -MDelphi -gl -gh copytest.pas and run produces the following: lenin:$ ./copytest Heap dump by heaptrc unit 3 memory blocks allocated : 48024/48024 2 memory blocks freed : 32016/32016 1 unfreed memory blocks : 16008 True heap size : 262144 True free heap : 246048 Should be : 246072 Call trace for block $B7F4BF50 size 16008 $080480EA main, line 8 of copytest.pas $080657A7 I hope this helps diagnose what's happening here. Note that if compiled without -MDelphi it works correctly but in our case we need to use -MDelphi because our application is also built with Delphi and Kylix3. Cheers, Bruce. Jonas Maebe wrote: On 25 May 2009, at 10:30, Bruce Tulloch wrote: PS: does the attribute compilerproc mean the function is defined to be called by the compiler implicitly? We have rebuilt the FPC RTL with debug enabled to further diagnose what's happening here (which is why we came across it). It means that the procedure becomes invisible to regular Pascal code, and that it gets a particular internal symbol name. Such routines are indeed called implicitly by the compiler for various purposes. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Memory leaks in FPC 2.3.1 SVN 13188
Thanks for that. We're using -gh. We're aware of the usage requirements of heaptrc. The cause of this problem in our case is very subtle. So far we have been unable to reproduce it outside our (very large) application but we're working on isolating it in a smaller test program. The problem looks like a dynamic array, created by Copy() inside an object's method, which is returned as the result of the method and assigned to a property (not a field) of another object (of a different class), is never released. This is the case even when the property to which it's assigned, is assigned a new value later on (at which point by our accounting, the reference count of the first array should have dropped to zero). We'll post more details or an example program when we have abstracted this problem from the rest of our application (in which application we have already eliminated all other known memory leaks using heaptrc). Are we correct to assume that as soon as no variable in our program, be it global, static, object field or property, refers to a dynamic array, the dynamic array will be released. Are we also correct to assume that the reassignment of any variable referring to a dynamic array to a new value will cause the previous array value to be released (presuming nothing else refers to this array)? Cheers, Bruce. leledumbo wrote: Are we missing something here or might this be an FPC bug? It depends on how you use HeapTrc. If via -gh, this might a bug. If you manually include in a uses clause, you have to be sure that you put it as the first one of your program. Otherwise, HeapTrc won't be able to detect what have been done by units loaded before it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
