gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] MacOS X & other stuff


From: Christian Grothoff
Subject: Re: [GNUnet-developers] MacOS X & other stuff
Date: Sun, 19 Dec 2004 22:03:55 -0500
User-agent: KMail/1.7.1

On Saturday 18 December 2004 14:51, Jussi Eloranta wrote:
> Hi,
>
> Recently somebody asked about a problem with gnunet and macos x.
> Gnunetd was complaining that
> something went wrong in semaphore.c. I was able to reproduce the
> problem and noticed that some
> of the test programs gave that message as well but everything went OK
> otherwise (e.g. make check succeeded).
> After looking at one of the test programs I noticed that the problem
> was that cron_handler never got initialized
> to any non-zero value in util/cron.c and that PTHREAD_KILL was trying
> to killl something that did exist.
> I believe all *BSD systems should give the same message but not Linux
> since it just silently ignores this
> situation. Shouldn't cron_handle be initialized properly or am I
> missing something?

Well, KILL is used to signal the cron to stop sleeping (which is quite 
pointless if cron does not yet exist).  I've fixed the code to not do this 
anymore :-).

> Few other things with the CVS version from yesterday:
>
> 1) Both Extractor and gnunet define symbol OPEN and the macos X linker
> chokes on this.

Any ideas why?  Bug in the linker?  Is there a fix other than to rename OPEN?

> 2) Extractor Makefile in src/plugins/ole2 have the following lines
> after configure:
>
> # Ok, linking this one is complicated, see Mantis #787.
> libextractor_ole2_la_LDFLAGS = \
>   -Wl,-Bstatic -Wl,-lgobject-2.0 -Wl,-lglib-2.0 -Wl,-Bdynamic \
>   -Wl,-Bsymbolic -avoid-version -module
>
> On systems with non-gnu ld (like macos x) this will not work. Just
> setting this to empty seems to work.
> What is this "hack" anyway?

Well, go to Mantis (http://ovmj.org/~mantis/) and check out bug #787. It's a 
long and complicated story.  And yes, it will seem to work without those 
lines, but only up to a certain point (2nd load of the plugin by an 
application using glib (like gnunet-gtk), and then it'll break).

C




reply via email to

[Prev in Thread] Current Thread [Next in Thread]