Sven Barth wrote:
On 26.07.2014 19:50, leledumbo wrote:
Because then all apps are linked to it, also the ones that don't need
threads. Same for clocale and cwstrings.
If the widestring manager could be made by ourselves, is it possible for
thread manager as well?
Principiall yes, but the
In our previous episode, leledumbo said:
Because then all apps are linked to it, also the ones that don't need
threads. Same for clocale and cwstrings.
If the widestring manager could be made by ourselves, is it possible for
thread manager as well?
You could make an own threadmanager in
In our previous episode, Mark Morgan Lloyd said:
Going back to something less labour intensive, would it be possible to
have s directive which has the effect that if a procedure isn't
eliminated by smartlinking then the linker should warn if a specific
library hasn't been linked?
ELF
On 27.07.2014 11:39, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 26.07.2014 19:50, leledumbo wrote:
Because then all apps are linked to it, also the ones that don't need
threads. Same for clocale and cwstrings.
If the widestring manager could be made by ourselves, is it possible for
thread
On Sun, Jul 27, 2014 at 02:39:58PM +0200, Sven Barth wrote:
On 27.07.2014 11:39, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 26.07.2014 19:50, leledumbo wrote:
Because then all apps are linked to it, also the ones that don't need
threads. Same for clocale and cwstrings.
If the widestring
On 27.07.2014 17:01, Henry Vermaak wrote:
On Sun, Jul 27, 2014 at 02:39:58PM +0200, Sven Barth wrote:
On 27.07.2014 11:39, Mark Morgan Lloyd wrote:
Sven Barth wrote:
On 26.07.2014 19:50, leledumbo wrote:
Because then all apps are linked to it, also the ones that don't need
threads. Same for
Because then all apps are linked to it, also the ones that don't need
threads. Same for clocale and cwstrings.
If the widestring manager could be made by ourselves, is it possible for
thread manager as well?
--
View this message in context:
On 26.07.2014 19:50, leledumbo wrote:
Because then all apps are linked to it, also the ones that don't need
threads. Same for clocale and cwstrings.
If the widestring manager could be made by ourselves, is it possible for
thread manager as well?
Principiall yes, but the problem here would be
I was asked why a threaded application compiles on Linux without uses
cthreads but it does not work.
cthreads must _always_ be added to uses section.
I had no answer to that. IMO such errors should be trapped at
compile-time, not at run-time.
Could it be fixed somehow?
Many people experience the
On Fri, 25 Jul 2014, Juha Manninen wrote:
I was asked why a threaded application compiles on Linux without uses
cthreads but it does not work.
cthreads must _always_ be added to uses section.
I had no answer to that. IMO such errors should be trapped at
compile-time, not at run-time.
Could it
Michael Van Canneyt wrote:
On Fri, 25 Jul 2014, Juha Manninen wrote:
I was asked why a threaded application compiles on Linux without uses
cthreads but it does not work.
cthreads must _always_ be added to uses section.
I had no answer to that. IMO such errors should be trapped at
compile-time,
On Fri, 25 Jul 2014, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
On Fri, 25 Jul 2014, Juha Manninen wrote:
I was asked why a threaded application compiles on Linux without uses
cthreads but it does not work.
cthreads must _always_ be added to uses section.
I had no answer to that.
The same question that I posted on bugtracker:
Linux, BSD, Unix, has another threaddriver than cthreads? If no, why not
make cthreads unit the default threaddriver for Unix?
2014-07-25 7:33 GMT-03:00 Michael Van Canneyt mich...@freepascal.org:
On Fri, 25 Jul 2014, Mark Morgan Lloyd wrote:
On 07/25/2014 03:04 PM, Fabio Luis Girardi wrote:
The same question that I posted on bugtracker:
Linux, BSD, Unix, has another threaddriver than cthreads? If no, why
not make cthreads unit the default threaddriver for Unix?
I read somewhere some time ago that the main reason for this was that
2014-07-25 10:10 GMT-03:00 Ewald ew...@yellowcouch.org:
On 07/25/2014 03:04 PM, Fabio Luis Girardi wrote:
The same question that I posted on bugtracker:
Linux, BSD, Unix, has another threaddriver than cthreads? If no, why
not make cthreads unit the default threaddriver for Unix?
I read
Am 25.07.2014 15:11 schrieb Ewald ew...@yellowcouch.org:
On 07/25/2014 03:04 PM, Fabio Luis Girardi wrote:
The same question that I posted on bugtracker:
Linux, BSD, Unix, has another threaddriver than cthreads? If no, why
not make cthreads unit the default threaddriver for Unix?
I
In our previous episode, Fabio Luis Girardi said:
The same question that I posted on bugtracker:
Linux, BSD, Unix, has another threaddriver than cthreads?
No.
If no, why not
make cthreads unit the default threaddriver for Unix?
Because then all apps are linked to it, also the ones that
Hi,
the TThreadManager class has only the SemaphoreWait procedure and it
lacks the SemaphoreTimedWait function. But in the cthreads unit exists a
cSemaphoreTimedWait implementation.
Is there a problem with that function and didn't included in the
TThreadManager class ?
I have some
On Tue, 11 Feb 2014, Dimitrios Chr. Ioannidis wrote:
Hi,
the TThreadManager class has only the SemaphoreWait procedure and it
lacks the SemaphoreTimedWait function. But in the cthreads unit exists a
cSemaphoreTimedWait implementation.
Is there a problem with that function and didn't
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):
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:
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%});
On 24 May 2013, at 13:37, Bruce Tulloch wrote:
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.
You can try passing --verbose to ld,
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
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
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':
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
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
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
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:
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?
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:
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,
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 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
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:
Hi!
libusb(x) links to libpthread:
$ ldd /lib/x86_64-linux-gnu/libusb-1.0.so.0
linux-vdso.so.1 =
librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6
2012/10/1 Johann Glaser johann.gla...@gmx.at:
Is it necessary to have the unit CThreads in my Uses clause?
No, only if you use threads in your pascal code.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Hello,
I'm trying to use the pthread_self function that supposed to be
existed at cthreads unit.
However the compiler tell me that it does not know pthread_self.
I'm using Linux 64 bit (so I can't use libc), using fpc 2.2.0 .
Looking at the source of cthreads.pp, it does have an include for
On 17 Feb 2008, at 19:42, ik wrote:
I'm trying to use the pthread_self function that supposed to be
existed at cthreads unit.
However the compiler tell me that it does not know pthread_self.
It's only imported into that unit (in the implementation), it's not
exported. The cthreads unit
Thanks, that works.
On Feb 17, 2008 8:50 PM, Jonas Maebe [EMAIL PROTECTED] wrote:
On 17 Feb 2008, at 19:42, ik wrote:
I'm trying to use the pthread_self function that supposed to be
existed at cthreads unit.
However the compiler tell me that it does not know pthread_self.
It's only
42 matches
Mail list logo
