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
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.
___
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
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
:-)
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
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
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
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:
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
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
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:
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%});
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
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
.
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
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
), 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
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
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
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
:
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
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
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
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
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/)
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
/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
.
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
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
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
...@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
, 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
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 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
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
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.
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
.
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
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
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
63 matches
Mail list logo
