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
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.
> >>>
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
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 bi
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 threadmanage
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 pro
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
> 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:
http://free-pascal-general.1045716.n5.nabble.com/
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 th
Am 25.07.2014 15:11 schrieb "Ewald" :
>
> 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 somewh
2014-07-25 10:10 GMT-03:00 Ewald :
> 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
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 t
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 :
>
>
> On Fri, 25 Jul 2014, Mark Morgan Lloyd wrote:
>
> Michael Van Cann
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.
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, 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 i
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 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 includ
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 existed
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
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, mayb
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: ../
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-linux/rtl/cthreads.o: In function
>>
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): w
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/03
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 q
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
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 >
**wrote:
On 23 May 2013, at 14:25, Bruce Tulloch wrote:
Do you have a libdl.so in your lib
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-gnueab
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 path? And what kind of
reference to libdl does link.res contain?
Yes, it's in the search path a
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:
>
> root@beria:/li
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
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
/usr/local/lib/fpc/2.7.1/
units/arm-linux/rtl/cthreads.**o: In function
`CTHREADS_$$_LOADPTHREADS$$**BOOLEAN':
cthread
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: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':
cthr
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
2012/10/1 Johann Glaser :
> 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
http://lists.freepascal.org/mailman/listinfo/fpc-pasc
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
/lib64/ld
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".
>
>
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 on
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
pth
43 matches
Mail list logo
