Is it necessary to declare the functions extern in the header file?
The default linkage for functions is external.
John
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
Ciao,
Cle :-)
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
