Re: Failed to compile haproxy with lua on Solaris 10

[Willy Tarreau]

Hi!

On Tue, Jul 18, 2017 at 03:17:29AM +, Akhnin Nikita wrote:
> Bump! Any updates for this?

So I actually implemented it in the master branch, in case you want to
give it a try. "it works for me(tm)" :-)

I'll stick a note to backport it into the next 1.7.

Cheers,
Willy

Re: Failed to compile haproxy with lua on Solaris 10

[Willy Tarreau]

On Tue, Jul 18, 2017 at 03:17:29AM +, Akhnin Nikita wrote:
> Bump! Any updates for this?

It looks like nobody had the time to work on this or had more important
stuff to deal with for now :-/  Adding this to my very long todo-list.

Willy

RE: Failed to compile haproxy with lua on Solaris 10

[Akhnin Nikita]

Bump! Any updates for this?

-Original Message-
From: Akhnin Nikita [mailto:n.akh...@ftc.ru] 
Sent: Monday, May 15, 2017 9:31 AM
To: Willy Tarreau ; Benoît GARNIER 
Cc: haproxy@formilux.org
Subject: RE: Failed to compile haproxy with lua on Solaris 10

Thanks guys! I'm looking forward to the patch

-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu]
Sent: Saturday, May 13, 2017 4:27 PM
To: Benoît GARNIER 
Cc: Ахнин Никита Андреевич ; haproxy@formilux.org
Subject: Re: Failed to compile haproxy with lua on Solaris 10

On Sat, May 13, 2017 at 10:42:58AM +0200, Benoît GARNIER wrote:
> Le 13/05/2017 à 09:46, Willy Tarreau a écrit :
> > On Sat, May 13, 2017 at 08:44:06AM +0200, Benoît GARNIER wrote:
> >> Time handling is not easy. I hate to say that, but POSIX and glibc 
> >> manage to make it even harder. Especially the timezone global 
> >> handling which is not thread-safe as you pinpointed.
> >> Anyway, free conding a simple timegm() is not very hard, since you 
> >> don't have to take any timezone into account, only leap years.
> > That's what I've seen, none of them implement the leap seconds (I 
> > thought it was needed).
> 
> They don't because leap seconds don't exist. Really. The kernel (at 
> least on Linux) hides this extraneous second(*) from userland.
> There are two ways the kernel can do this:
> 1) skipping it entirely - i.e the kernel will return 23:59:59 during 2 
> seconds

I disagree on this one, as the kernel doesn't return human-readable time but 
only seconds and optionally micros/nanos. It's the tools and libc which turn 
that into human readable format. And furthermore, I've seen one with my own 
eyes by accident around 2000, so based on the list, I think it was the 1999 
one. That was the first time I've heard about this. I spent more than one hour 
searching what bug in my system could have caused a second to appear as "60" !

> 2) slowly adjusting time returned by the kernel until it matches UTC 
> time - for a few hours kernel seconds will last longer than a real 
> second So, at the end of day, from userland point of view, a day 
> always lasts
> 86400 seconds, even when a leap second is inserted (and although the 
> day was officially 86401 seconds long).

That's what NTP helps doing indeed by slightly slowing down the internal 
clock's PLL so that no date is off by more than 1/86400s (=11 microseconds) 
during the day.

> That means you don't have to worry about leap seconds when making 
> computations on past dates.

But yeah in fact that's a good point.

> But it can reveal subtle bugs (especially time going backward in the 
> first case and giving negative values when computing elapsed times).
> Measuring elapsed time should preferably done with
> clock_gettime(CLOCK_MONOTONIC,...) which is always monotonic, but is 
> adjusted by NTP (if the internal clock is drifting).
> Another variant is clock_gettime(CLOCK_MONOTONIC_RAW,...) which is 
> monotonic and never adjusted but is specific to Linux > 2.6.28.
> (Note: you can still have time going backward in a SMP platform during 
> task switching since each CPU has its own clock, even thought the 
> kernel try to compensate for the difference).

We've been used to these trouble in the past, on the first dual-core opteron 
systems and then in many VMs, causing us to implement an internal monotonic, 
corrected clock to address this for the internal timers. That's what the 
internal time for the tasks is measured in "ticks" which we all know are 
corrected milliseconds but could change if needed. The code was later ported to 
keepalived who started to suffer from the same problems, but causing more 
serious trouble there such as random timeouts triggering causing occasional 
switchovers.

Anyway thanks for your insights, I think we can go with a "my_timegm()"
implementation to address this problem once for all, it will be the most 
durable solution.

Willy

RE: Failed to compile haproxy with lua on Solaris 10

[Akhnin Nikita]

Thanks guys! I'm looking forward to the patch

-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu] 
Sent: Saturday, May 13, 2017 4:27 PM
To: Benoît GARNIER 
Cc: Ахнин Никита Андреевич ; haproxy@formilux.org
Subject: Re: Failed to compile haproxy with lua on Solaris 10

On Sat, May 13, 2017 at 10:42:58AM +0200, Benoît GARNIER wrote:
> Le 13/05/2017 à 09:46, Willy Tarreau a écrit :
> > On Sat, May 13, 2017 at 08:44:06AM +0200, Benoît GARNIER wrote:
> >> Time handling is not easy. I hate to say that, but POSIX and glibc 
> >> manage to make it even harder. Especially the timezone global 
> >> handling which is not thread-safe as you pinpointed.
> >> Anyway, free conding a simple timegm() is not very hard, since you 
> >> don't have to take any timezone into account, only leap years.
> > That's what I've seen, none of them implement the leap seconds (I 
> > thought it was needed).
> 
> They don't because leap seconds don't exist. Really. The kernel (at 
> least on Linux) hides this extraneous second(*) from userland.
> There are two ways the kernel can do this:
> 1) skipping it entirely - i.e the kernel will return 23:59:59 during 2 
> seconds

I disagree on this one, as the kernel doesn't return human-readable time but 
only seconds and optionally micros/nanos. It's the tools and libc which turn 
that into human readable format. And furthermore, I've seen one with my own 
eyes by accident around 2000, so based on the list, I think it was the 1999 
one. That was the first time I've heard about this. I spent more than one hour 
searching what bug in my system could have caused a second to appear as "60" !

> 2) slowly adjusting time returned by the kernel until it matches UTC 
> time - for a few hours kernel seconds will last longer than a real 
> second So, at the end of day, from userland point of view, a day 
> always lasts
> 86400 seconds, even when a leap second is inserted (and although the 
> day was officially 86401 seconds long).

That's what NTP helps doing indeed by slightly slowing down the internal 
clock's PLL so that no date is off by more than 1/86400s (=11 microseconds) 
during the day.

> That means you don't have to worry about leap seconds when making 
> computations on past dates.

But yeah in fact that's a good point.

> But it can reveal subtle bugs (especially time going backward in the 
> first case and giving negative values when computing elapsed times).
> Measuring elapsed time should preferably done with
> clock_gettime(CLOCK_MONOTONIC,...) which is always monotonic, but is 
> adjusted by NTP (if the internal clock is drifting).
> Another variant is clock_gettime(CLOCK_MONOTONIC_RAW,...) which is 
> monotonic and never adjusted but is specific to Linux > 2.6.28.
> (Note: you can still have time going backward in a SMP platform during 
> task switching since each CPU has its own clock, even thought the 
> kernel try to compensate for the difference).

We've been used to these trouble in the past, on the first dual-core opteron 
systems and then in many VMs, causing us to implement an internal monotonic, 
corrected clock to address this for the internal timers. That's what the 
internal time for the tasks is measured in "ticks" which we all know are 
corrected milliseconds but could change if needed. The code was later ported to 
keepalived who started to suffer from the same problems, but causing more 
serious trouble there such as random timeouts triggering causing occasional 
switchovers.

Anyway thanks for your insights, I think we can go with a "my_timegm()"
implementation to address this problem once for all, it will be the most 
durable solution.

Willy

Re: Failed to compile haproxy with lua on Solaris 10

[Benoît GARNIER]

Le 13/05/2017 à 11:27, Willy Tarreau a écrit :
> On Sat, May 13, 2017 at 10:42:58AM +0200, Benoît GARNIER wrote:
>> Le 13/05/2017 à 09:46, Willy Tarreau a écrit :
>>> On Sat, May 13, 2017 at 08:44:06AM +0200, Benoît GARNIER wrote:
 Time handling is not easy. I hate to say that, but POSIX and glibc
 manage to make it even harder. Especially the timezone global handling
 which is not thread-safe as you pinpointed.
 Anyway, free conding a simple timegm() is not very hard, since you don't
 have to take any timezone into account, only leap years.
>>> That's what I've seen, none of them implement the leap seconds (I thought
>>> it was needed).
>> They don't because leap seconds don't exist. Really. The kernel (at
>> least on Linux) hides this extraneous second(*) from userland.
>> There are two ways the kernel can do this:
>> 1) skipping it entirely - i.e the kernel will return 23:59:59 during 2
>> seconds
> I disagree on this one, as the kernel doesn't return human-readable time
> but only seconds and optionally micros/nanos. It's the tools and libc
> which turn that into human readable format. And furthermore, I've seen
> one with my own eyes by accident around 2000, so based on the list, I
> think it was the 1999 one. That was the first time I've heard about
> this. I spent more than one hour searching what bug in my system could
> have caused a second to appear as "60" !
Yes, you're right, I was simplifying. The Kernel is in charge of keeping
time, but userland keeps it synchronised (thru adjtime()).
But still, the kernel has a notion of real time thru
clock_gettime(CLOCK_REALTIME, ...) since it returns epoch.
What I meant is that with *modern* Linux kernels / glibc, you won't see
the extraneous second.

Benoît

Re: Failed to compile haproxy with lua on Solaris 10

[Willy Tarreau]

On Sat, May 13, 2017 at 10:42:58AM +0200, Benoît GARNIER wrote:
> Le 13/05/2017 à 09:46, Willy Tarreau a écrit :
> > On Sat, May 13, 2017 at 08:44:06AM +0200, Benoît GARNIER wrote:
> >> Time handling is not easy. I hate to say that, but POSIX and glibc
> >> manage to make it even harder. Especially the timezone global handling
> >> which is not thread-safe as you pinpointed.
> >> Anyway, free conding a simple timegm() is not very hard, since you don't
> >> have to take any timezone into account, only leap years.
> > That's what I've seen, none of them implement the leap seconds (I thought
> > it was needed).
> 
> They don't because leap seconds don't exist. Really. The kernel (at
> least on Linux) hides this extraneous second(*) from userland.
> There are two ways the kernel can do this:
> 1) skipping it entirely - i.e the kernel will return 23:59:59 during 2
> seconds

I disagree on this one, as the kernel doesn't return human-readable time
but only seconds and optionally micros/nanos. It's the tools and libc
which turn that into human readable format. And furthermore, I've seen
one with my own eyes by accident around 2000, so based on the list, I
think it was the 1999 one. That was the first time I've heard about
this. I spent more than one hour searching what bug in my system could
have caused a second to appear as "60" !

> 2) slowly adjusting time returned by the kernel until it matches UTC
> time - for a few hours kernel seconds will last longer than a real second
> So, at the end of day, from userland point of view, a day always lasts
> 86400 seconds, even when a leap second is inserted (and although the day
> was officially 86401 seconds long).

That's what NTP helps doing indeed by slightly slowing down the internal
clock's PLL so that no date is off by more than 1/86400s (=11 microseconds)
during the day.

> That means you don't have to worry about leap seconds when making
> computations on past dates.

But yeah in fact that's a good point.

> But it can reveal subtle bugs (especially time going backward in the
> first case and giving negative values when computing elapsed times).
> Measuring elapsed time should preferably done with
> clock_gettime(CLOCK_MONOTONIC,...) which is always monotonic, but is
> adjusted by NTP (if the internal clock is drifting).
> Another variant is clock_gettime(CLOCK_MONOTONIC_RAW,...) which is
> monotonic and never adjusted but is specific to Linux > 2.6.28.
> (Note: you can still have time going backward in a SMP platform during
> task switching since each CPU has its own clock, even thought the kernel
> try to compensate for the difference).

We've been used to these trouble in the past, on the first dual-core
opteron systems and then in many VMs, causing us to implement an internal
monotonic, corrected clock to address this for the internal timers. That's
what the internal time for the tasks is measured in "ticks" which we all
know are corrected milliseconds but could change if needed. The code was
later ported to keepalived who started to suffer from the same problems,
but causing more serious trouble there such as random timeouts triggering
causing occasional switchovers.

Anyway thanks for your insights, I think we can go with a "my_timegm()"
implementation to address this problem once for all, it will be the most
durable solution.

Willy

Re: Failed to compile haproxy with lua on Solaris 10

[Benoît GARNIER]

Le 13/05/2017 à 09:46, Willy Tarreau a écrit :
> On Sat, May 13, 2017 at 08:44:06AM +0200, Benoît GARNIER wrote:
>> Time handling is not easy. I hate to say that, but POSIX and glibc
>> manage to make it even harder. Especially the timezone global handling
>> which is not thread-safe as you pinpointed.
>> Anyway, free conding a simple timegm() is not very hard, since you don't
>> have to take any timezone into account, only leap years.
> That's what I've seen, none of them implement the leap seconds (I thought
> it was needed).

They don't because leap seconds don't exist. Really. The kernel (at
least on Linux) hides this extraneous second(*) from userland.
There are two ways the kernel can do this:
1) skipping it entirely - i.e the kernel will return 23:59:59 during 2
seconds
2) slowly adjusting time returned by the kernel until it matches UTC
time - for a few hours kernel seconds will last longer than a real second
So, at the end of day, from userland point of view, a day always lasts
86400 seconds, even when a leap second is inserted (and although the day
was officially 86401 seconds long).
That means you don't have to worry about leap seconds when making
computations on past dates.
But it can reveal subtle bugs (especially time going backward in the
first case and giving negative values when computing elapsed times).
Measuring elapsed time should preferably done with
clock_gettime(CLOCK_MONOTONIC,...) which is always monotonic, but is
adjusted by NTP (if the internal clock is drifting).
Another variant is clock_gettime(CLOCK_MONOTONIC_RAW,...) which is
monotonic and never adjusted but is specific to Linux > 2.6.28.
(Note: you can still have time going backward in a SMP platform during
task switching since each CPU has its own clock, even thought the kernel
try to compensate for the difference).

(*) Or missing second but that didn't happen in recent history

>> But beware that real timegm() (and mktime()) perform some time
>> normalization on tm_mday (day of the month) or tm_mon (month).
>> For example, they will happily work with fake dates like "March 31st
>> 2017", "February 59th 2017" or even "1st day of 18th month of 2016" and
>> will convert them to "April 1st 2017" internally.
> I've read this and apparently most of the time it's not needed at
> all.
Probably, it depends on the use case.
>> It's very handy when you want to compute date in the future or in the
>> past, you just add/substract values to the corresponding field (day or
>> month) and let mktime() of timegm() do their magic trick.
> Yes, like you do with the "date" command to know what date it will be in
> 1 million seconds for example :-)
Exactly.


Benoît

Re: Failed to compile haproxy with lua on Solaris 10

[Willy Tarreau]

On Sat, May 13, 2017 at 08:44:06AM +0200, Benoît GARNIER wrote:
> Time handling is not easy. I hate to say that, but POSIX and glibc
> manage to make it even harder. Especially the timezone global handling
> which is not thread-safe as you pinpointed.
> Anyway, free conding a simple timegm() is not very hard, since you don't
> have to take any timezone into account, only leap years.

That's what I've seen, none of them implement the leap seconds (I thought
it was needed).

> But beware that real timegm() (and mktime()) perform some time
> normalization on tm_mday (day of the month) or tm_mon (month).
> For example, they will happily work with fake dates like "March 31st
> 2017", "February 59th 2017" or even "1st day of 18th month of 2016" and
> will convert them to "April 1st 2017" internally.

I've read this and apparently most of the time it's not needed at
all.

> It's very handy when you want to compute date in the future or in the
> past, you just add/substract values to the corresponding field (day or
> month) and let mktime() of timegm() do their magic trick.

Yes, like you do with the "date" command to know what date it will be in
1 million seconds for example :-)

Willy

Re: Failed to compile haproxy with lua on Solaris 10

[Benoît GARNIER]

Le 13/05/2017 à 08:09, Willy Tarreau a écrit :
> Hi Benoît,
>
> On Sat, May 13, 2017 at 07:32:10AM +0200, Benoît GARNIER wrote:
>> Le 12/05/2017 à 15:54, Willy Tarreau a écrit :
>>> Hi Benoît,
>>>
>>> On Thu, May 04, 2017 at 08:50:33AM +0200, Benoît GARNIER wrote:
>>> (...)
 If you do the following operation : time_t => localtime() => struct tm
 => timegm() => time_t, your result will be shift by the timezone time
 offset (but without any DST applied).

 Technically, if you live in Great Britain, the operation will succeed
 during winter (but will offset the result by 1 hour during summer, since
 DST is applied here).
>>> So in short you're saying that we should always use mktime() instead ?
>>>
>>> Willy
>> No, not at all !!! To sum up, these are the basic functions to work with
>> time :
>>
>> - time() return a time_t which is timezone agnostic since it's just a
>> precise moment in time (it represents the same moment for everybody)
>>
>> - localtime() takes this time_t and build a representation of this time
>> in the current time zone (struct tm)
>>
>> - mktime() take a struct tm representing a specific time in the current
>> timezone et return a time_t
>>
>> gmtime() and timegm() are the same as localtime() and mktime() but will
>> ignore the timezone and DST: they only work with UTC time.
>>
>> So you can use timegm() on a struct tm only if you know that struct tm
>> represents a GMT time (for example if it was build with gmtime()).
>>
>> Similarly, using mktime() is only valid if this struct tm represents the
>> time in the current time zone (i.e. if it was build with localtime()
>> with the same timezone).
>>
>> For example if you parse a log file with GMT time in it you'll use
>> timegm() to build a time_t representing the precise time of the log.
>>
>> If you parse a file with local time in it, you'll use mktime() but
>> you'll also have to know what was the timezone used to build it.
>>
>> 1) Time zone agnostic: time()
>> 2) Current time zone: localtime() and mktime()
>> 3) UTC time: gmtime() and timegm()
>>
>> As a rule of thumb, you cannot mix functions in categories 2 and 3.
> OK thank you, that's perfectly clear now and it makes sense. Thierry
> told me that he purposely used timegm() because he wanted UTC. Man
> pages recommend not to use it because it's obsolete and suggest to
> use setenv(TZ)+tzset()+mktime() !!! It's amazing to read something
> that stupid in man pages written 10 years after everyone started to
> write threaded applications! I found that in practice many people
> use a hand-written timegm() function which does all the computation
> by hand, just like those of us who have known MS-DOS used to do 30
> years ago, so I think we'll have to go down that route for a more
> portable implementation :-/  At least this will also save us from
> accidently using implementations where timegm() is a wrapper on
> setenv+tzset+mktime()...
Time handling is not easy. I hate to say that, but POSIX and glibc
manage to make it even harder. Especially the timezone global handling
which is not thread-safe as you pinpointed.
Anyway, free conding a simple timegm() is not very hard, since you don't
have to take any timezone into account, only leap years.

But beware that real timegm() (and mktime()) perform some time
normalization on tm_mday (day of the month) or tm_mon (month).
For example, they will happily work with fake dates like "March 31st
2017", "February 59th 2017" or even "1st day of 18th month of 2016" and
will convert them to "April 1st 2017" internally.
It's very handy when you want to compute date in the future or in the
past, you just add/substract values to the corresponding field (day or
month) and let mktime() of timegm() do their magic trick.

Benoît

Re: Failed to compile haproxy with lua on Solaris 10

[Willy Tarreau]

Hi Benoît,

On Sat, May 13, 2017 at 07:32:10AM +0200, Benoît GARNIER wrote:
> Le 12/05/2017 à 15:54, Willy Tarreau a écrit :
> > Hi Benoît,
> >
> > On Thu, May 04, 2017 at 08:50:33AM +0200, Benoît GARNIER wrote:
> > (...)
> >> If you do the following operation : time_t => localtime() => struct tm
> >> => timegm() => time_t, your result will be shift by the timezone time
> >> offset (but without any DST applied).
> >>
> >> Technically, if you live in Great Britain, the operation will succeed
> >> during winter (but will offset the result by 1 hour during summer, since
> >> DST is applied here).
> > So in short you're saying that we should always use mktime() instead ?
> >
> > Willy
> 
> No, not at all !!! To sum up, these are the basic functions to work with
> time :
> 
> - time() return a time_t which is timezone agnostic since it's just a
> precise moment in time (it represents the same moment for everybody)
> 
> - localtime() takes this time_t and build a representation of this time
> in the current time zone (struct tm)
> 
> - mktime() take a struct tm representing a specific time in the current
> timezone et return a time_t
> 
> gmtime() and timegm() are the same as localtime() and mktime() but will
> ignore the timezone and DST: they only work with UTC time.
> 
> So you can use timegm() on a struct tm only if you know that struct tm
> represents a GMT time (for example if it was build with gmtime()).
> 
> Similarly, using mktime() is only valid if this struct tm represents the
> time in the current time zone (i.e. if it was build with localtime()
> with the same timezone).
> 
> For example if you parse a log file with GMT time in it you'll use
> timegm() to build a time_t representing the precise time of the log.
> 
> If you parse a file with local time in it, you'll use mktime() but
> you'll also have to know what was the timezone used to build it.
> 
> 1) Time zone agnostic: time()
> 2) Current time zone: localtime() and mktime()
> 3) UTC time: gmtime() and timegm()
> 
> As a rule of thumb, you cannot mix functions in categories 2 and 3.

OK thank you, that's perfectly clear now and it makes sense. Thierry
told me that he purposely used timegm() because he wanted UTC. Man
pages recommend not to use it because it's obsolete and suggest to
use setenv(TZ)+tzset()+mktime() !!! It's amazing to read something
that stupid in man pages written 10 years after everyone started to
write threaded applications! I found that in practice many people
use a hand-written timegm() function which does all the computation
by hand, just like those of us who have known MS-DOS used to do 30
years ago, so I think we'll have to go down that route for a more
portable implementation :-/  At least this will also save us from
accidently using implementations where timegm() is a wrapper on
setenv+tzset+mktime()...

Thanks for your explanations!

Willy

Re: Failed to compile haproxy with lua on Solaris 10

[Benoît GARNIER]

Le 12/05/2017 à 15:54, Willy Tarreau a écrit :
> Hi Benoît,
>
> On Thu, May 04, 2017 at 08:50:33AM +0200, Benoît GARNIER wrote:
> (...)
>> If you do the following operation : time_t => localtime() => struct tm
>> => timegm() => time_t, your result will be shift by the timezone time
>> offset (but without any DST applied).
>>
>> Technically, if you live in Great Britain, the operation will succeed
>> during winter (but will offset the result by 1 hour during summer, since
>> DST is applied here).
> So in short you're saying that we should always use mktime() instead ?
>
> Willy

No, not at all !!! To sum up, these are the basic functions to work with
time :

- time() return a time_t which is timezone agnostic since it's just a
precise moment in time (it represents the same moment for everybody)

- localtime() takes this time_t and build a representation of this time
in the current time zone (struct tm)

- mktime() take a struct tm representing a specific time in the current
timezone et return a time_t

gmtime() and timegm() are the same as localtime() and mktime() but will
ignore the timezone and DST: they only work with UTC time.

So you can use timegm() on a struct tm only if you know that struct tm
represents a GMT time (for example if it was build with gmtime()).

Similarly, using mktime() is only valid if this struct tm represents the
time in the current time zone (i.e. if it was build with localtime()
with the same timezone).

For example if you parse a log file with GMT time in it you'll use
timegm() to build a time_t representing the precise time of the log.

If you parse a file with local time in it, you'll use mktime() but
you'll also have to know what was the timezone used to build it.

1) Time zone agnostic: time()
2) Current time zone: localtime() and mktime()
3) UTC time: gmtime() and timegm()

As a rule of thumb, you cannot mix functions in categories 2 and 3.

Benoît

Re: Failed to compile haproxy with lua on Solaris 10

[Willy Tarreau]

Hi Benoît,

On Thu, May 04, 2017 at 08:50:33AM +0200, Benoît GARNIER wrote:
(...)
> If you do the following operation : time_t => localtime() => struct tm
> => timegm() => time_t, your result will be shift by the timezone time
> offset (but without any DST applied).
> 
> Technically, if you live in Great Britain, the operation will succeed
> during winter (but will offset the result by 1 hour during summer, since
> DST is applied here).

So in short you're saying that we should always use mktime() instead ?

Willy

Re: Failed to compile haproxy with lua on Solaris 10

[Benoît GARNIER]

Le 04/05/2017 à 07:14, Willy Tarreau a écrit :
> Hi,
>
> On Wed, May 03, 2017 at 06:17:40AM +, Akhnin Nikita wrote:
>> Greetings!
>>
>> I have a problem with compiling haproxy with lua support against Solaris 10.
>> I'm using gcc v4.9 and making it with command (don't pay attention to the 
>> odd paths to the gcc and libraries):
>> gmake CC=/pub/site/opt/bin/gcc TARGET=solaris USE_OPENSSL=1 
>> SSL_INC=/pub/site/opt/include/openssl SSL_LIB=/pub/site/opt/lib USE_PCRE=1 
>> PCREDIR=/pub/site/opt PREFIX=/pub/site/opt USE_PCRE_JIT=1 USE_STATIC_PCRE=1 
>> USE_ZLIB=1 USE_LUA=1 ADDLIB="-R/pub/site/opt/lib" LUA_LIB=/pub/site/opt/lib 
>> LUA_INC=/pub/site/opt/include
>>
>> The error message is:
>>
>> /pub/site/opt/bin/gcc -Iinclude -Iebtree -Wall  -O2 -g -fno-strict-aliasing 
>> -Wdeclaration-after-statement -fomit-frame-pointer -DFD_SETSIZE=65536 
>> -D_REENTRANT  -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H 
>> -DUSE_GETADDRINFO -DUSE_ZLIB  -DENABLE_POLL -DUSE_OPENSSL 
>> -I/pub/site/opt/include/openssl -DUSE_LUA  -DUSE_PCRE 
>> -I/pub/site/opt/include -DUSE_PCRE_JIT  -DCONFIG_HAPROXY_VERSION=\"1.7.4\" 
>> -DCONFIG_HAPROXY_DATE=\"2017/03/27\" -c -o src/hlua_fcn.o src/hlua_fcn.c
>> src/hlua_fcn.c: In function 'hlua_parse_date':
>> src/hlua_fcn.c:290:2: warning: implicit declaration of function 'timegm' 
>> [-Wimplicit-function-declaration]
>>   time = timegm();
>>   ^
>>
>> /pub/site/opt/bin/gcc  -g -o haproxy src/haproxy.o src/base64.o 
>> src/protocol.o src/uri_auth.o src/standard.o src/buffer.o src/log.o 
>> src/task.o src/chunk.o src/channel.o src/listener.o src/lru.o src/xxhash.o 
>> src/time.o src/fd.o src/pipe.o src/regex.o src/cfgparse.o src/server.o 
>> src/checks.o src/queue.o src/frontend.o src/proxy.o src/peers.o src/arg.o 
>> src/stick_table.o src/proto_uxst.o src/connection.o src/proto_http.o 
>> src/raw_sock.o src/backend.o src/tcp_rules.o src/lb_chash.o src/lb_fwlc.o 
>> src/lb_fwrr.o src/lb_map.o src/lb_fas.o src/stream_interface.o src/stats.o 
>> src/proto_tcp.o src/applet.o src/session.o src/stream.o src/hdr_idx.o 
>> src/ev_select.o src/signal.o src/acl.o src/sample.o src/memory.o 
>> src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o src/payload.o 
>> src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o src/dns.o 
>> src/vars.o src/filters.o src/flt_http_comp.o src/flt_trace.o src/flt_spoe.o 
>> src/cli.o src/ev_poll.o src/ssl_sock.o src/shctx.o src/hlua.o src/hlua_fcn.o 
>> ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o 
>> ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o -lnsl -lsocket  
>> -lcrypt  -lz -L/pub/site/opt/lib -lssl -lcrypto -Wl,--export-dynamic  -llua 
>> -lm -L/pub/site/opt/lib -Wl,-Bstatic -lpcreposix -lpcre -Wl,-Bdynamic 
>> -R/pub/site/opt/lib
>> src/hlua_fcn.o: In function `hlua_parse_date':
>> /pub/home/appadm/temp/haproxy-1.7.4/src/hlua_fcn.c:290: undefined reference 
>> to `timegm'
>> collect2: error: ld returned 1 exit status
>> gmake: *** [haproxy] Error 1
>>
>> According to 
>> http://stackoverflow.com/questions/40904201/alternative-to-timegm-on-solaris,
>>  there is no timegm function in Solaris, so I can't solve this without power 
>> of haproxy developers.
>>
>> Is there any way to make this code compatible with Solaris?
> I had never heard about this function. Could you try with mktime() instead ?
> It takes the same prototype. If anybody knows what the difference is between
> the two, I'll appreciate any enlightment on this. The man pages are not clear
> enough for me on the subject.

There are two ways to build a struct tm to break down the time in hour,
minute, second and so on: calling localtime, which takes current
timezone into account, or calling gmtime to build an UTC time.

The reverse operation is done by calling mktime (which will give the
original time_t only if the current timezone is the same as when
localtime was called, since the timezone is not recorded in struct tm)
in the former case or timegm in the latter.

If you do the following operation : time_t => localtime() => struct tm
=> timegm() => time_t, your result will be shift by the timezone time
offset (but without any DST applied).

Technically, if you live in Great Britain, the operation will succeed
during winter (but will offset the result by 1 hour during summer, since
DST is applied here).


Benoît



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: Failed to compile haproxy with lua on Solaris 10

[Willy Tarreau]

On Thu, May 04, 2017 at 05:48:45AM +, Akhnin Nikita wrote:
> Well, the compilation was success.

OK that's a good point already.

> How to make sure that this change didn't
> broke anything? For what functional does this part of the code correspond?

We need to wait for Thierry to check, I have absolutely no idea where
nor why it is used.

Willy

RE: Failed to compile haproxy with lua on Solaris 10

[Akhnin Nikita]

Well, the compilation was success. How to make sure that this change didn't 
broke anything? For what functional does this part of the code correspond?

-Original Message-
From: Willy Tarreau [mailto:w...@1wt.eu] 
Sent: Thursday, May 4, 2017 12:15 PM
Cc: haproxy@formilux.org
Subject: Re: Failed to compile haproxy with lua on Solaris 10

Hi,

On Wed, May 03, 2017 at 06:17:40AM +, Akhnin Nikita wrote:
> Greetings!
> 
> I have a problem with compiling haproxy with lua support against Solaris 10.
> I'm using gcc v4.9 and making it with command (don't pay attention to the odd 
> paths to the gcc and libraries):
> gmake CC=/pub/site/opt/bin/gcc TARGET=solaris USE_OPENSSL=1 
> SSL_INC=/pub/site/opt/include/openssl SSL_LIB=/pub/site/opt/lib 
> USE_PCRE=1 PCREDIR=/pub/site/opt PREFIX=/pub/site/opt USE_PCRE_JIT=1 
> USE_STATIC_PCRE=1 USE_ZLIB=1 USE_LUA=1 ADDLIB="-R/pub/site/opt/lib" 
> LUA_LIB=/pub/site/opt/lib LUA_INC=/pub/site/opt/include
> 
> The error message is:
> 
> /pub/site/opt/bin/gcc -Iinclude -Iebtree -Wall  -O2 -g -fno-strict-aliasing 
> -Wdeclaration-after-statement -fomit-frame-pointer -DFD_SETSIZE=65536 
> -D_REENTRANT  -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H 
> -DUSE_GETADDRINFO -DUSE_ZLIB  -DENABLE_POLL -DUSE_OPENSSL 
> -I/pub/site/opt/include/openssl -DUSE_LUA  -DUSE_PCRE -I/pub/site/opt/include 
> -DUSE_PCRE_JIT  -DCONFIG_HAPROXY_VERSION=\"1.7.4\" 
> -DCONFIG_HAPROXY_DATE=\"2017/03/27\" -c -o src/hlua_fcn.o src/hlua_fcn.c
> src/hlua_fcn.c: In function 'hlua_parse_date':
> src/hlua_fcn.c:290:2: warning: implicit declaration of function 'timegm' 
> [-Wimplicit-function-declaration]
>   time = timegm();
>   ^
> 
> /pub/site/opt/bin/gcc  -g -o haproxy src/haproxy.o src/base64.o 
> src/protocol.o src/uri_auth.o src/standard.o src/buffer.o src/log.o 
> src/task.o src/chunk.o src/channel.o src/listener.o src/lru.o 
> src/xxhash.o src/time.o src/fd.o src/pipe.o src/regex.o src/cfgparse.o 
> src/server.o src/checks.o src/queue.o src/frontend.o src/proxy.o 
> src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o 
> src/connection.o src/proto_http.o src/raw_sock.o src/backend.o 
> src/tcp_rules.o src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o 
> src/lb_map.o src/lb_fas.o src/stream_interface.o src/stats.o 
> src/proto_tcp.o src/applet.o src/session.o src/stream.o src/hdr_idx.o 
> src/ev_select.o src/signal.o src/acl.o src/sample.o src/memory.o 
> src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o 
> src/payload.o src/hash.o src/pattern.o src/map.o src/namespace.o 
> src/mailers.o src/dns.o src/vars.o src/filters.o src/flt_http_comp.o 
> src/flt_trace.o src/flt_spoe.o src/cli.o src/ev_poll.o src/ssl_sock.o 
> src/shctx.o src/hlua.o src/hlua_fcn.o ebtree/ebtree.o 
> ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o 
> ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o -lnsl -lsocket  
> -lcrypt  -lz -L/pub/site/opt/lib -lssl -lcrypto -Wl,--export-dynamic  
> -llua -lm -L/pub/site/opt/lib -Wl,-Bstatic -lpcreposix -lpcre 
> -Wl,-Bdynamic -R/pub/site/opt/lib
> src/hlua_fcn.o: In function `hlua_parse_date':
> /pub/home/appadm/temp/haproxy-1.7.4/src/hlua_fcn.c:290: undefined reference 
> to `timegm'
> collect2: error: ld returned 1 exit status
> gmake: *** [haproxy] Error 1
> 
> According to 
> http://stackoverflow.com/questions/40904201/alternative-to-timegm-on-solaris, 
> there is no timegm function in Solaris, so I can't solve this without power 
> of haproxy developers.
> 
> Is there any way to make this code compatible with Solaris?

I had never heard about this function. Could you try with mktime() instead ?
It takes the same prototype. If anybody knows what the difference is between 
the two, I'll appreciate any enlightment on this. The man pages are not clear 
enough for me on the subject.

Willy

Re: Failed to compile haproxy with lua on Solaris 10

[Willy Tarreau]

Hi,

On Wed, May 03, 2017 at 06:17:40AM +, Akhnin Nikita wrote:
> Greetings!
> 
> I have a problem with compiling haproxy with lua support against Solaris 10.
> I'm using gcc v4.9 and making it with command (don't pay attention to the odd 
> paths to the gcc and libraries):
> gmake CC=/pub/site/opt/bin/gcc TARGET=solaris USE_OPENSSL=1 
> SSL_INC=/pub/site/opt/include/openssl SSL_LIB=/pub/site/opt/lib USE_PCRE=1 
> PCREDIR=/pub/site/opt PREFIX=/pub/site/opt USE_PCRE_JIT=1 USE_STATIC_PCRE=1 
> USE_ZLIB=1 USE_LUA=1 ADDLIB="-R/pub/site/opt/lib" LUA_LIB=/pub/site/opt/lib 
> LUA_INC=/pub/site/opt/include
> 
> The error message is:
> 
> /pub/site/opt/bin/gcc -Iinclude -Iebtree -Wall  -O2 -g -fno-strict-aliasing 
> -Wdeclaration-after-statement -fomit-frame-pointer -DFD_SETSIZE=65536 
> -D_REENTRANT  -DTPROXY -DCONFIG_HAP_CRYPT -DNEED_CRYPT_H 
> -DUSE_GETADDRINFO -DUSE_ZLIB  -DENABLE_POLL -DUSE_OPENSSL 
> -I/pub/site/opt/include/openssl -DUSE_LUA  -DUSE_PCRE -I/pub/site/opt/include 
> -DUSE_PCRE_JIT  -DCONFIG_HAPROXY_VERSION=\"1.7.4\" 
> -DCONFIG_HAPROXY_DATE=\"2017/03/27\" -c -o src/hlua_fcn.o src/hlua_fcn.c
> src/hlua_fcn.c: In function 'hlua_parse_date':
> src/hlua_fcn.c:290:2: warning: implicit declaration of function 'timegm' 
> [-Wimplicit-function-declaration]
>   time = timegm();
>   ^
> 
> /pub/site/opt/bin/gcc  -g -o haproxy src/haproxy.o src/base64.o 
> src/protocol.o src/uri_auth.o src/standard.o src/buffer.o src/log.o 
> src/task.o src/chunk.o src/channel.o src/listener.o src/lru.o src/xxhash.o 
> src/time.o src/fd.o src/pipe.o src/regex.o src/cfgparse.o src/server.o 
> src/checks.o src/queue.o src/frontend.o src/proxy.o src/peers.o src/arg.o 
> src/stick_table.o src/proto_uxst.o src/connection.o src/proto_http.o 
> src/raw_sock.o src/backend.o src/tcp_rules.o src/lb_chash.o src/lb_fwlc.o 
> src/lb_fwrr.o src/lb_map.o src/lb_fas.o src/stream_interface.o src/stats.o 
> src/proto_tcp.o src/applet.o src/session.o src/stream.o src/hdr_idx.o 
> src/ev_select.o src/signal.o src/acl.o src/sample.o src/memory.o 
> src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o src/payload.o 
> src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o src/dns.o 
> src/vars.o src/filters.o src/flt_http_comp.o src/flt_trace.o src/flt_spoe.o 
> src/cli.o src/ev_poll.o src/ssl_sock.o src/shctx.o src/hlua.o src/hlua_fcn.o 
> ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o ebtree/ebmbtree.o 
> ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o -lnsl -lsocket  -lcrypt 
>  -lz -L/pub/site/opt/lib -lssl -lcrypto -Wl,--export-dynamic  -llua -lm 
> -L/pub/site/opt/lib -Wl,-Bstatic -lpcreposix -lpcre -Wl,-Bdynamic 
> -R/pub/site/opt/lib
> src/hlua_fcn.o: In function `hlua_parse_date':
> /pub/home/appadm/temp/haproxy-1.7.4/src/hlua_fcn.c:290: undefined reference 
> to `timegm'
> collect2: error: ld returned 1 exit status
> gmake: *** [haproxy] Error 1
> 
> According to 
> http://stackoverflow.com/questions/40904201/alternative-to-timegm-on-solaris, 
> there is no timegm function in Solaris, so I can't solve this without power 
> of haproxy developers.
> 
> Is there any way to make this code compatible with Solaris?

I had never heard about this function. Could you try with mktime() instead ?
It takes the same prototype. If anybody knows what the difference is between
the two, I'll appreciate any enlightment on this. The man pages are not clear
enough for me on the subject.

Willy