Is it necessary to declare the functions extern in the header file? The default linkage for functions is external.


On 22 Nov 2009, at 4:54 AM, cle wrote:

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

Cle :-)


Reply via email to