Alexander Burger wrote:

 Hi Cli,

Hi Alex,

(...)

 So that means, that you fixed also the problems with loading dynamic
 libraries, which was a major trouble during recent months.

I guess I did ... :-)

 As I'm on a trip until Monday evening, having only sporadic time and
 network access, I'll look at it more thoroughly early next week.

 -    DYNAMIC-LIB-FLAGS = -dynamiclib -undefined dynamic_lookup +
 DYNAMIC-LIB-FLAGS = -dynamiclib -undefined dynamic_lookup -m32

 So this was the culprit for the "*.so" loading problem ;-)

This was *one* problem, however. Those solutions play a bit together :-)

 main.c: +/* Globals declared in pico.h */ +int Signal, Chr, Slot,
 Spkr, Mic, Hear, Tell, Children, ExtN; +char **AV, *AV0, *Home; ...

 pico.h: /* Globals */ -int Signal, Chr, Slot, Spkr, Mic, Hear, Tell,
 Children, ExtN; -char **AV, *AV0, *Home;

 Funny! This is how it was some time ago. I'd changed it to have the
 globals and the prototypes in "pico.h" only, to avoid redundancy. I
 didn't expect that this could cause problems on some compilers!

This was the second part of the problem. It seems that defining the variables in more than one place cause trouble in MacOS/X as e.g. io.c gets its own set of them. And they seem not to be properly handled (i.e. resolved) as one and the same variable by the linker.

So the correct solution (I believe as stated in the C standard) should be, to declare them extern in pico.h and define them once in one and only one compilation unit i.e. main.c in our case. Then no linker/loader should have any problem to resolve them correctly.

 -      (task (port T 4444) (eval (udp @))) -      (udp "localhost"
 4444 '(setq *B 4)) +      (task (port T 4445) (eval (udp @))) +
 (udp "localhost" 4445 '(setq *B 4))

 Does port 4444 produce any conflict?

Yeah, if running in scope of the whole test suite. As the tests in test/src/net.l also use port 4444, it seems that the port was not released back to the OS yet, when test/lib.l was running. Therfore it was still be used and couldn't be bound again.

Running the test/lib.l on its own works. Or -- as I did -- simple changing of the port to e.g. 4445 :-)

> I hope, I did not break your coding style too much via the patch
> ...

 Not at all! I'm very happy that you found it out!

So I am, cause now I can begin to investigate picoLisp for my problem domain :-D

 Many thanks!

I have to thank *you* for making such a fine tool available to the public ...

 Cheers, - Alex

Ciao,
Cle :-)


--------------000403050800030703020406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Alexander Burger wrote:<br>
<br>
<span style="white-space: pre;">&gt; Hi Cli,<br>
</span><br>
Hi Alex,<br>
<span style="white-space: pre;"><br>
(...)</span><br>
<br>
<span style="white-space: pre;">&gt; So that means, that you fixed also
the problems with loading dynamic <br>
&gt; libraries, which was a major trouble during recent months.<br>
</span><br>
I guess I did ... :-)<br>
<br>
<span style="white-space: pre;">&gt; As I'm on a trip until Monday
evening, having only sporadic time and <br>
&gt; network access, I'll look at it more thoroughly early next week.<br>
&gt; <br>
&gt; -    DYNAMIC-LIB-FLAGS = -dynamiclib -undefined dynamic_lookup +<br>
&gt; DYNAMIC-LIB-FLAGS = -dynamiclib -undefined dynamic_lookup -m32<br>
&gt; <br>
&gt; So this was the culprit for the "*.so" loading problem ;-)<br>
</span><br>
This was *one* problem, however. Those solutions play a bit together :-)<br>
<span style="white-space: pre;"><br>
&gt; main.c: +/* Globals declared in pico.h */ +int Signal, Chr, Slot,<br>
&gt; Spkr, Mic, Hear, Tell, Children, ExtN; +char **AV, *AV0, *Home; ...<br>
&gt; <br>
&gt; pico.h: /* Globals */ -int Signal, Chr, Slot, Spkr, Mic, Hear,
Tell,<br>
&gt; Children, ExtN; -char **AV, *AV0, *Home;<br>
&gt; <br>
&gt; Funny! This is how it was some time ago. I'd changed it to have
the <br>
&gt; globals and the prototypes in "pico.h" only, to avoid redundancy.
I <br>
&gt; didn't expect that this could cause problems on some compilers!<br>
</span><br>
This was the second part of the problem. It seems that defining the
variables in more than one place cause trouble in MacOS/X as e.g. io.c
gets its own set of them. And they seem not to be properly handled
(i.e. resolved) as one and the same variable by the linker.<br>
<br>
So the correct solution (I believe as stated in the C standard) should
be, to declare them extern in pico.h and define them once in one and
only one compilation unit i.e. main.c in our case. Then no
linker/loader should have any problem to resolve them correctly.<br>
<span style="white-space: pre;"><br>
&gt; -      (task (port T 4444) (eval (udp @))) -      (udp "localhost"<br>
&gt; 4444 '(setq *B 4)) +      (task (port T 4445) (eval (udp @))) +<br>
&gt; (udp "localhost" 4445 '(setq *B 4))<br>
&gt; <br>
&gt; Does port 4444 produce any conflict?<br>
</span><br>
Yeah, if running in scope of the whole test suite. As the tests in
test/src/net.l also use port 4444, it seems that the port was not
released back to the OS yet, when test/lib.l was running. Therfore it
was still be used and couldn't be bound again.<br>
<br>
Running the test/lib.l on its own works. Or -- as I did -- simple
changing of the port to e.g. 4445 :-)<br>
<br>
<span style="white-space: pre;">&gt;&gt; I hope, I did not break your
coding style too much via the patch<br>
&gt;&gt; ...<br>
&gt; <br>
&gt; Not at all! I'm very happy that you found it out!<br>
</span><br>
So I am, cause now I can begin to investigate picoLisp for my problem
domain :-D<br>
<span style="white-space: pre;"><br>
&gt; Many thanks!<br>
</span><br>
I have to thank *you* for making such a fine tool available to the
public ...<br>
<span style="white-space: pre;"><br>
&gt; Cheers, - Alex</span><br>
<br>
Ciao,<br>
Cle :-)<br>
<br>
</body>
</html>

--------------000403050800030703020406--
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe

Reply via email to