Thanks, I will give them a go. -b
On Fri, Jan 10, 2014 at 10:36 PM, Jonas Maebe wrote:
>
> 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 Valgrin
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
to us) topic :-)
Cheers, Bruce.
On Mon, Jun 10, 2013 at 7:55 PM, Jonas Maebe wrote:
>
> On 10 Jun 2013, at 11:41, Bruce Tulloch wrote:
>
> On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe *
>> *wrote:
>>
>> Under Mac OS X (and *BSD, and probably even most Linux distribut
Okay, got it, thanks Jonas. -b
On Mon, Jun 10, 2013 at 7:55 PM, Jonas Maebe wrote:
>
> On 10 Jun 2013, at 11:41, Bruce Tulloch wrote:
>
> On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe *
>> *wrote:
>>
>> Under Mac OS X (and *BSD, and probably even most Linux di
On Mon, Jun 10, 2013 at 6:59 PM, Jonas Maebe 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 l
What is the *recommended* way to build and package a shared library for OSX?
Our aim is that ordinary users can "just install it" such that other
applications that depend on the library "just run" (without requiring
authors of those other applications to include a copy of the library in
their bund
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
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
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 wrote:
> In our previous episode, Bruce Tull
For those that are interested, converting all symlinks to be relative (in
/usr/lib in the crossroot) fixes cross linking problems (i.e. when using
--sysroot with ld) when targetting Debian Wheezy or similar systems (e.g
Ubuntu, or in my case, Raspbian):
root@fermi:/usr/lib/arm-linux-gnueabihf# sym
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
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(
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: ../
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 t
Not yet, but I will try this shortly -b
On Fri, May 24, 2013 at 6:47 PM, Jonas Maebe 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-
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
g. 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 wrote:
> I have to pack it in for about 8 hours (
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 j
ot 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 wrote:
> Okay, I under
> On 23 May 2013, at 15:03, Bruce Tulloch wrote:
>
> On Thu, May 23, 2013 at 10:50 PM, Jonas Maebe
>> **wrote:
>>
>>
>>> On 23 May 2013, at 14:32, Bruce Tulloch wrote:
>>>
>>> On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe >> >
Jonas Maebe wrote:
>
> On 23 May 2013, at 14:32, Bruce Tulloch wrote:
>
> On Thu, May 23, 2013 at 10:28 PM, Jonas Maebe
>> **wrote:
>>
>>
>>> On 23 May 2013, at 14:25, Bruce Tulloch wrote:
>>>
>>> Do you have a libdl.so in your library search
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 wrote:
> Yes, it's in the search path as:
>
&
23, 2013 at 10:28 PM, Jonas Maebe wrote:
>
> On 23 May 2013, at 14:25, Bruce Tulloch wrote:
>
> On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe
>> **wrote:
>>
>> On 23 May 2013, at 14:10, Bruce Tulloch wrote:
>>>
>>> Linking arm-test-threads
&g
version
1 (SYSV), dynamically linked,
BuildID[sha1]=0x40caad061df15685e213cec1e4dfe1ba5f67701c, stripped
Any clues? -b
On Thu, May 23, 2013 at 10:18 PM, Jonas Maebe wrote:
>
> On 23 May 2013, at 14:10, Bruce Tulloch wrote:
>
> However, if I simply add this uses clause:
>>
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 cros
tion?
Thanks, Bruce.
On Thu, May 23, 2013 at 3:38 PM, Bruce Tulloch 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:
>
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/ra
s one and all for all your helpful feedback!
Bruce.
On Thu, May 9, 2013 at 10:55 PM, Jonas Maebe wrote:
>
> 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 with
PM, José Mejuto 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 sa
the body of the function
foo.
Thanks for your feedback. Cheers, Bruce.
On Thu, May 9, 2013 at 4:21 PM, Ludo Brands 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:
> >
> >
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 wrote:
> I've not managed to trap it again, but based on the information I have
> from the last time it occurred
trap it) but it was obviously wrong.
-b
On Thu, May 9, 2013 at 9:33 AM, Bruce Tulloch 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
ruce.
On Wed, May 8, 2013 at 5:18 PM, Michael Van Canneyt
wrote:
>
>
> 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.
>>
>>
:
>
> 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'
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 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.
>
>
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 S
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
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,
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" wrote:
> On Tue, Jan 8, 2013 at 9:04 PM, Jonas Maebe
> wrote:
&
On Tue, Jan 8, 2013 at 9:04 PM, Jonas Maebe 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 othe
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.
I
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 broke
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
(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
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
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-
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
.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
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
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 projec
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"
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
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
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
s that OSX allows an application to appear such that
its title bar is hidden by the desktop menu bar but does not seem to
provide an easy way to then relocate the window to a new position.
I'm clearly a Mac newbie, what am I missing?
Cheers, Bruce.
On 08/11/11 16:08, Bruce Tulloch wrote:
>
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
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 i
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,
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
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
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 list
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.o
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
Confirmed fixed in r13195 as tested with the application in which this
was originally discovered, thanks Jonas.
Bruce Tulloch wrote:
> I've reported this as an FPC bug:
>
> http://bugs.freepascal.org/view.php?id=13820
>
> Cheers, Bruce.
>
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 no
ening 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 attribut
mpilerproc" 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:
>
>
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
When building an application with Lazarus (r20153) using FPC (r13188)
(on a Debian Lenny system) we are experiencing significant memory leaks.
Earlier revisions of both Lazarus and FPC 2.3.1 experience the same problem.
Building and running our app with heaptrc enabled we find a very large
number
69 matches
Mail list logo
