Prolog - Can't compile SWI on FreeBSD

Author

Can't compile SWI on FreeBSD

Mike Goodrich

2006-09-22, 7:01 pm

version 5.6.20

Is griping about conflicting definitions of the 'timezone' variable. Using
gcc version 3.4.2

Anyone seen this one?

Jan, did I miss a setting particular to FreeBSD somewhere?

russell kym horsell

2006-09-23, 4:00 am

Mike Goodrich <goodrich_ms@yahoo.com> wrote:
> version 5.6.20
> Is griping about conflicting definitions of the 'timezone' variable. Using
> gcc version 3.4.2
> Anyone seen this one?
> Jan, did I miss a setting particular to FreeBSD somewhere?

These are the kinds of things most porters don't even notice. :)

Rule #1: anything that sticks out just chop off.
Rule #2: antyhing that doesn't stick out far enough, chop off
something that stands out and stick it there.

Jan Wielemaker

2006-09-23, 4:00 am

On 2006-09-22, Mike Goodrich <goodrich_ms@yahoo.com> wrote:
>
>
> version 5.6.20
>
>
> Is griping about conflicting definitions of the 'timezone' variable. Using
> gcc version 3.4.2
>
> Anyone seen this one?
>
> Jan, did I miss a setting particular to FreeBSD somewhere?

This problem appears with the new time handling primitives. One of the
things I need from the system C-library is:

========================================
========================
SYNOPSIS
#include <time.h>

void tzset (void);

extern char *tzname[2];
extern long timezone;
extern int daylight;

<snip>

CONFORMING TO
SVID 3, POSIX, 4.3BSD
========================================
========================

but appearently on FreeBSD timezone() is a function. You get the
above behaviour in MacOSX using #define __DARWIN_UNIX03 1, but I
still do not know how to fix this for FreeBSD. The above is from
the Linux documentation and if the `conforming POSIX' is correct,
I'd assume there is some setting in FreeBSD to get the desired
POSIX behaviour.

B.t.w. the variable timezone gives the number of seconds west of
GMT.

B.t.w. If ou just need a working Prolog, replace the occurence of
timezone in pl-tai.c with the number it should have. Do not move
timezones afterwards :-)

If anyone knows the proper way to do this, please let me know.

Cheers --- Jan

A.L.

2006-09-23, 8:00 am

On Sat, 23 Sep 2006 05:42:29 +0000 (UTC), russell kym horsell
<kym@ukato.freeshell.org> wrote:

>Mike Goodrich <goodrich_ms@yahoo.com> wrote:
>
>These are the kinds of things most porters don't even notice. :)
>
>Rule #1: anything that sticks out just chop off.
>Rule #2: antyhing that doesn't stick out far enough, chop off
>something that stands out and stick it there.

Ruke#3: If you have nothing to say, don't respond. The world knows
about your existence, anyway.

A.L.

Darren Bane

2006-09-24, 7:01 pm

Jan Wielemaker wrote:

!snip!

> If anyone knows the proper way to do this, please let me know.

Your Mac OS X workaround doesn't work for 10.3, so I raised
https://svn.macosforge.org/projects...ts/ticket/10334 FreeBSD
could be the same given their common ancestry.

russell kym horsell

2006-09-25, 4:00 am

Darren Bane <darren.bane@gmail.com> wrote:
> Jan Wielemaker wrote:
> !snip!
> Your Mac OS X workaround doesn't work for 10.3, so I raised
> https://svn.macosforge.org/projects...ts/ticket/10334 FreeBSD
> could be the same given their common ancestry.

This may be a long story, but hold on for the point. :)

I like to keep the approx 20,0000 packages from sourceforge upt-o-date on
my little network. Various hardware, various platforms.

This is difficult to do with a staff of 3, so we've developed some
automated programming tools to upload stuff every w

or 2, "debug" it,
and install it.

The "debugging" is 99.9% automated. It's nice to have a base of 20,000
packages to datamine for common problems, or develop contrasts for
common solutions. We also rely on released s/w being "close" to working,
and only a small edit away from "success". :)

But since this in the realm of AI, the solutions developed by the process
don't always "work [as intended]", or "work well", or "look nice".

In the case of packages declaring stuff that is already declared in
a slightly different and probably non-conforming way in some system header
the potted solution the tool has developed over a few years of its
automated musing and tinkering runs along the lines of:

#define offendingname foobar
#include <systemheader>
// package version of the offending name:
sometype offendingname(someparams);

If necessary it can include some ifdef's to ensure things are identical
on the original platform, viz:

#ifdef __FreeBSD__
#if OSVERSION == something
#define offendingname foobar
#endif
#endif
#include <systemheader>
// package version of the offending name:
sometype offendingname(someparams);

It's quick and painless, and usually results in no further compiler warning
(or error).

Like all AI techniques, it can't really be viewed just after breakfast.

russell kym horsell

2006-09-25, 4:00 am

russell kym horsell <kym@ukato.freeshell.org> wrote:
[...]
> #define offendingname foobar
> #include <systemheader>

Naturally, I forgot the
#undef offendingname
to have this make sense. Oh well, it was only 1 edit away from ok,
so your automated tools should have developed the solution. :}

> // package version of the offending name:
> sometype offendingname(someparams);

Jan Wielemaker

2006-09-25, 4:00 am

Dear Darren,

On 2006-09-25, russell kym horsell <kym@ukato.freeshell.org> wrote:
> Darren Bane <darren.bane@gmail.com> wrote:
>
> This may be a long story, but hold on for the point. :)

> #define offendingname foobar
> #include <systemheader>
> // package version of the offending name:
> sometype offendingname(someparams);

This is -AFAIK-, not the problem we are faced with. Standards, including
POSIX and BSD4.3 define a global variable timezone that was set by
tzset() to the number of seconds west of GMT of the current timezone.
Note this is a constant value over the year. If DST is active we have to
add another 3600 seconds. That is the value I need. Now modern FreeBSD
defines a *function* timezone(). I forgot what it does, but not what the
variable does.

Considering the variable timezone is covered by various standards I
assume there is a way around in FreeBSD to get compatibility. I do not
have a FreeBSD system though.

--- Jan

Jan Wielemaker

2006-09-25, 4:00 am

On 2006-09-24, Darren Bane <darren.bane@gmail.com> wrote:
> Jan Wielemaker wrote:
>
> !snip!
>
>
> Your Mac OS X workaround doesn't work for 10.3, so I raised
> https://svn.macosforge.org/projects...ts/ticket/10334 FreeBSD
> could be the same given their common ancestry.

Somehow I got a mail from this service, but it requires a password :-(
If there is a solution in the ticket, please post it here or send it
by mail.

Thanks --- Jan

Darren Bane

2006-09-25, 8:01 am

Jan Wielemaker wrote:

!snip!

> Somehow I got a mail from this service, but it requires a password :-(
> If there is a solution in the ticket, please post it here or send it
> by mail.

Sorry about that, I thought that system was readable by the public
without registration.

Here's the patch:

--- pl-tai.c.orig Thu Aug 10 16:52:22 2006
+++ pl-tai.c Thu Aug 10 16:56:19 2006
@@ -22,14 +22,6 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
02111-1307 USA
*/

-/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
-Somehow, MacOS X defines timezone() as a function. Using the
#define
-__DARWIN_UNIX03 1 is reverts to the standard behaviour to make it
an
-long set by tzset(). Not really clean ...
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - */
-
-#define __DARWIN_UNIX03 1
-
#include <math.h>
#include "pl-incl.h"
#include "libtai/taia.h"
@@ -41,8 +33,6 @@
#define daylight _daylight
#else
extern char *tzname[2];
-extern long timezone;
-extern int daylight;
#endif

@@ -82,8 +72,24 @@

static int
tz_offset()
-{ do_tzset();
- return timezone;
+{ time_t tloc;
+ struct tm result;
+
+ tloc = time(NULL);
+ return localtime_r(&tloc, &result)->tm_gmtoff;
+}
+
+/* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
+tz_daylight() tests whether summer time is in effect.
+- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - */
+
+static int
+tz_daylight()
+{ time_t tloc;
+ struct tm result;
+
+ tloc = time(NULL);
+ return localtime_r(&tloc, &result)->tm_isdst;
}

@@ -312,7 +318,7 @@
ct.hour = tm.tm_hour;
ct.minute = tm.tm_min;
tzatom = tz_name_as_atom(tm.tm_isdst);
- if ( daylight ) /* from tzset() */
+ if ( tz_daylight() ) /* from tzset() */
{ if ( tm.tm_isdst )
{ utcoffset -= 3600;
dstatom = ATOM_true;
@@ -721,7 +727,7 @@
{ localtime_r(&unixt, &tb.tm);
tb.sec = (double)tb.tm.tm_sec + modf(tb.stamp, &ip);
tb.utcoff = tz_offset();
- if ( daylight )
+ if ( tz_daylight() )
{ if ( tb.tm.tm_isdst )
{ tb.utcoff -= 3600;
tb.isdst = TRUE;

Jan Wielemaker

2006-09-25, 7:00 pm

On 2006-09-25, Darren Bane <darren.bane@gmail.com> wrote:
> Jan Wielemaker wrote:
>
> !snip!
>
>
> Sorry about that, I thought that system was readable by the public
> without registration.
>
> Here's the patch:

Thanks, but unfortunately it is not correct. It is more or less the
same as proposed on the SWI-Prolog bugzilla
(See http://gollem.science.uva.nl/bugzil..._bug.cgi?id=206) and
has the same flaws: tm_gmtoff is at the time of conversion, and so
includes DST offset. Now we can correct that using tm.tm_isdst.

Somehow, I still hope someone tells me why FreeBSD conflicts with
the standard and how to get the standard behaviour back. Now I have
to rely on the _non-standard_ field tm_gmtoff.

Cheers --- Jan

P.s. Maybe better to use the above Bugzilla for this discussion.
Its not really about Prolog ...

2006-09-26, 4:01 am

Jan Wielemaker <jan@nospam.ct.xs4all.nl> wrote:
> Considering the variable timezone is covered by various standards I
[...]
> assume there is a way around in FreeBSD to get compatibility. I do not
> have a FreeBSD system though.

OK. My mistook.

I did a quick scan yesterday (details not near me now) of some of the auto
builds, and a not-bleeding-edge but "recent" version -- I think it was
swipl-5.4.7 -- seemed to build fine under fbsd6.{0,1}
with none of my hacking.

But I'll check the details and get back to you.

Jan Wielemaker

2006-09-26, 4:01 am

On 2006-09-26, <kym@droog.sdf-eu.org> <kym@droog.sdf-eu.org> wrote:
> Jan Wielemaker <jan@nospam.ct.xs4all.nl> wrote:
> [...]
>
> OK. My mistook.
>
> I did a quick scan yesterday (details not near me now) of some of the auto
> builds, and a not-bleeding-edge but "recent" version -- I think it was
> swipl-5.4.7 -- seemed to build fine under fbsd6.{0,1}
> with none of my hacking.
>
> But I'll check the details and get back to you.

I've found various reports of similar problems with other software.
Bottom line appears to be that timezone variable is simply lacking and
one should use the tm_gmtoff of struct tm. With help of provided patches
and work-arounds in other systems I think I managed to get a working
version. At least it compiles on both Linux and MacOS 10.4. Linux
provides both interfaces and they give consistent results. Patches
are on the SWI-Prolog CVS server.

Cheers --- Jan

russell kym horsell

2006-09-27, 4:01 am

Mike Goodrich <goodrich_ms@yahoo.com> wrote:
> version 5.6.20
> Is griping about conflicting definitions of the 'timezone' variable. Using
> gcc version 3.4.2
> Anyone seen this one?
> Jan, did I miss a setting particular to FreeBSD somewhere?

OK. I've now built up 5.4.7 and 5.6.x (can't remember patch level) swipl through
the standard ports builds for freebsd 5.4 and 6.0, and also "by hand"
outside the ports environment.
I can see no problem as above either in the base prolog or any of the packages
that I see built (e.g. cpp and xpce; and on some platforms jpl).

The only problems I *do* see are related to "make" appearing inside
../Makefile.in rather than '$(MAKE)' and someone using sys/malloc.h
rather than just malloc.h or even stdlib.h (at least 1 version
of html.c tests for all under ifndef, but ends up choosing the
"wrong" one under FreeBSD and OpenBSD).

There also seem to be one heck of a lot of "error:" messages in the latter
parts of xpce about things failing to import/define. The xpce-client
fails to build (?) but other related xpce things end up on /usr/local/lib/pl-XXX.

While it certainly is the case that "timezone" is a function and not
a variable in fbsd/obsd time.h (and there doesn't seem to be a clean way
to make that function delcaration disappear and an appropriate timezone variable
appear), unless the prob is *only* in 5.6.20 it seems the configure and/or
std patches that come with the ports swi-pl (admittedly this lags behind the
"current" swipl by a league or so) work OK. Doing it by hand requires some
OTHER fixes, but nothing to do with timezone.

In the code I did look at there were some test for tm_gmtoff existing,
and that was about all.

If Jan W wants to see the gory details, I can send the 8 build logs
(2 version of pl, 2 versions of obsd, 2 version of fbsd) and the system
"time" hdrs from all the platforms. I normally don't like to jam MB down
people's mail slots without an invite and an idea it wont go to /dev/null
immediatement.

Jan Wielemaker

2006-09-27, 4:01 am

On 2006-09-27, russell kym horsell <kym@ukato.freeshell.org> wrote:
> Mike Goodrich <goodrich_ms@yahoo.com> wrote:
>
> OK. I've now built up 5.4.7 and 5.6.x (can't remember patch level) swipl through
> the standard ports builds for freebsd 5.4 and 6.0, and also "by hand"
> outside the ports environment.
> I can see no problem as above either in the base prolog or any of the packages
> that I see built (e.g. cpp and xpce; and on some platforms jpl).
>
> The only problems I *do* see are related to "make" appearing inside
> ./Makefile.in rather than '$(MAKE)' and someone using sys/malloc.h

Some of those are fixed recently.

> rather than just malloc.h or even stdlib.h (at least 1 version
> of html.c tests for all under ifndef, but ends up choosing the
> "wrong" one under FreeBSD and OpenBSD).

Some parts of the system are very old and ported to many weird OSes
:-) Removed the sys/malloc.h. As configure doesn't even test for it
anymore and it was included conditionally, I wonder how it can cause a
problem. I won't take out malloc.h for now as I think there are still
ports out there that needs it.

> There also seem to be one heck of a lot of "error:" messages in the latter
> parts of xpce about things failing to import/define. The xpce-client
> fails to build (?) but other related xpce things end up on /usr/local/lib/pl-XXX.

Sounds a bit worrying. Please send details to me or post them to the Bugzilla
at http://www.swi-prolog.org.

> While it certainly is the case that "timezone" is a function and not
> a variable in fbsd/obsd time.h (and there doesn't seem to be a clean way
> to make that function delcaration disappear and an appropriate timezone variable
> appear), unless the prob is *only* in 5.6.20 it seems the configure and/or
> std patches that come with the ports swi-pl (admittedly this lags behind the
> "current" swipl by a league or so) work OK. Doing it by hand requires some
> OTHER fixes, but nothing to do with timezone.
>
> In the code I did look at there were some test for tm_gmtoff existing,
> and that was about all.

With help from various people, the CVS version now contains code that
appears to run on FreeBSD.

> If Jan W wants to see the gory details, I can send the 8 build logs
> (2 version of pl, 2 versions of obsd, 2 version of fbsd) and the system
> "time" hdrs from all the platforms. I normally don't like to jam MB down
> people's mail slots without an invite and an idea it wont go to /dev/null
> immediatement.

No thanks :-) I'm interested in specific problems, but please no MBs
of logfiles. Its probably even easier to fix by installing FreeBSD
myself :-)

Cheers --- Jan

michael.goodrich@gmail.com

2006-09-27, 7:59 am

I very much appreciate your efforts to resolve this, however I must
report that it still will not build. Seems to be unhappy with the
syntax of the Makefile now after running configure.

Perhaps I will get some time shortly to see if I can understand what is
wrong.

Also configure says it can't find libgmp even though I installed that
from the ports files.

I got your updated files from CVS - they appear to all be located in
the 'src' directory; I was assuming that these would resolve the
difficutly. Did I miss anything?

cheers,

-Mike

Jan Wielemaker

2006-09-27, 7:02 pm

On 2006-09-27, michael.goodrich@gmail.com <michael.goodrich@gmail.com> wrote:
>
> I very much appreciate your efforts to resolve this, however I must
> report that it still will not build. Seems to be unhappy with the
> syntax of the Makefile now after running configure.

You have to make sure it is using (GNU-) gmake. I have seen reports
it builds fine right now.

> Perhaps I will get some time shortly to see if I can understand what is
> wrong.
>
> Also configure says it can't find libgmp even though I installed that
> from the ports files.

Of the problem is that the development libraries are missing. Look at
config.log to find what went wrong.

> I got your updated files from CVS - they appear to all be located in
> the 'src' directory; I was assuming that these would resolve the
> difficutly. Did I miss anything?

BSD relevant patches are all in the src directory. Some involve configure,
so you must re-run this.

Cheers --- Jan

russell kym horsell

2006-09-28, 4:00 am

Jan Wielemaker <jan@nospam.ct.xs4all.nl> wrote:
[...]
> BSD relevant patches are all in the src directory. Some involve configure,
> so you must re-run this.

And just to add:
It's always a good idea to get rid of any file "config.cache" before
trying to rebuild after twiddling things.

russell kym horsell

2006-09-28, 4:00 am

Jan Wielemaker <jan@nospam.ct.xs4all.nl> wrote:
[...]
> Some of those are fixed recently.

I finally got hold of the specific version mentiond and found the problem
mentioned.

I also see that 5.6.20 it was a very clean build apart from -- as USUAL :) --
jpl. (It has some problem finding the "defaul" places for the various
java hdrs and libs. They are scattered around even more than the config
expects.)
Even xpce seemed to give none of the old niggles. :)

[...]
> Some parts of the system are very old and ported to many weird OSes
> :-) Removed the sys/malloc.h.
[...]

Brother, I *know* how that is. :)

> As configure doesn't even test for it
> anymore and it was included conditionally, I wonder how it can cause a
> problem. I won't take out malloc.h for now as I think there are still
> ports out there that needs it.

The compile was getting some syntax error -- I didn't check too closely. Maybe
some other needed headr is not included. Anyway, the "std" malloc.h works fine
for the moment. It does give a warning, which will turn fatal if -Werror
is on.

>[Re ERROR: messages from later parts of xpce build]
> Sounds a bit worrying. Please send details to me or post them to the Bugzilla
> at http://www.swi-prolog.org.
[...]

OK. I'll send that ovr. But that problem seems to have gone away with .20.

> With help from various people, the CVS version now contains code that
> appears to run on FreeBSD.

OK. I did look into it, and as you probably heard on both obsd and fbsd
(and, no doubt, nbsd as well) the clib "localtime.c" module does have those
daylight, timzone variables but under a USG conditional. I.e. old.
Probably now has something to do with avoiding reentrancy problems. You can
never tell when 2 threads might want to run in different timezones. :o

Looking through the std libs there appeared to be no "compatibility"
version of localtime that had been compiled with the USG option enabled
and stashed somehwere in /usr/lib.

And the fbsd/obsd time.h &ct hdr files do not include any ifdef to
make it work in the posix manner.

So it's a hack with a "my_tzset" that works with those vars, or something
similar.

Cheers, and thanks for all the swipl. :)

Jan Wielemaker

2006-09-28, 4:00 am

On 2006-09-28, russell kym horsell <kym@ukato.freeshell.org> wrote:
> OK. I did look into it, and as you probably heard on both obsd and fbsd
> (and, no doubt, nbsd as well) the clib "localtime.c" module does have those
> daylight, timzone variables but under a USG conditional. I.e. old.
> Probably now has something to do with avoiding reentrancy problems. You can
> never tell when 2 threads might want to run in different timezones. :o

Still weird. These variables are part of the POSIX standard. Timezones
(and locale in general) are a nightmare with threads anyway; this is just
one of the many issues. Anyway, the current source works and I think it
is safe.

> Cheers, and thanks for all the swipl. :)

Thanks for the feedback.

--- Jan

Sponsored Links