I have written a small program that uses threads. It works on a 386 Linux, but I have some problems on the Arm Linux platform.

The program routes a TCP connection to a serial port and if the TCP is not in use it can route UDP packets to the serial port return answers.

The "sockets.Recv" returns an obscure value on the Arm platform (line 462). I have created a "workaround", but sometimes I still loss data.

I only have problems in the TCP part of the program all other things works.

If I run the TCP part as a single program it works (without workarounds).

Have I done some obvious (to a thread programmer) errors writing the thread program, which only shows on the Arm Linux platform, or should I look elsewhere. On the Arm Linux platform I am using a uLibC library instead of the normal C library (I do not think that this is the problem but ??) .

I have run out of ideas.

Is there anyone that can give me a hint?

The source is included.

Carsten

How do you linked your binary to uLibC instead of standard libC ? You were cross compiling right? Is is possible to tell FPC which libc to use ?
Look here: http://uclibc.org/other_libs.html
Are there many FPC functions that will use a libc function instead of a system call (except the LibC unit) ?

Thanks.

Op Tue, 12 Dec 2006, schreef Alexander Todorov:

FPC detects the libc depending on the files it finds in /lib. I once added the right code for uclibc. Wether it still works, I don't know, and the support likely never was complete.

Daniël

I just renamed the uLibC lib to libc

were cross compiling right?

Yes

Is is possible to tell FPC which libc to use ?

Yes and No
In the FPC.CFG (attached) I tells the fpc compiler where to look, but it looks after libc
I just renamed uLibC to libc

I have ajusted the startup file cprt0.as (attached). The fpc program looks after the c lib loader. a command like this takes care of that

ln -sf /lib/ld-uClibc-0.9.27.so /lib/ld-linux.so.2

Now the program uses the ulibc loader.
It works

Look here: http://uclibc.org/other_libs.html Are there many FPC functions that will use a libc function instead of a system call (except the LibC unit) ?

threads

Op Tue, 12 Dec 2006, schreef Carsten Bager:

The compiler looks first for /lib/ld-linux.so.2, if this is found it assumes glibc. Then it looks for /lib/ld-uClibc.so.0, if this is found uclibc is assumed. Therefore, symlinking doesn't look like a good idea.

Daniël

Date sent: Tue, 12 Dec 2006 15:33:22 +0100 (CET)
From: Daniël Mantione
To: FPC-Pascal users discussions <fpc-

Subject: Re: [fpc-pascal] Re: Threads
Send reply to: FPC-Pascal users discussions <fpc-

<mailto:fpc-pascal-

<mailto:fpc-pascal-

The compiler is told that it is a cross compile, so it dos not look in /lib (fpc.cfg)
The symlinking is don on the target platform where the program runs. Carsten

The dynlinker can be override using -FL. I hope this conditional code respects that. Libraries can be overriden using the beta -XL support, hardcoded library paths using -Xd and -Xr.

So the only problem remaining is the startup code.

Probably you can avoid this by a combination of -Xr and -FL parameters. (and -Xd is a good idea always, when crosscompiling)