Re: cygwin compilation error

[Willy Tarreau]

Hi Bob,

On Mon, Jun 10, 2019 at 09:54:29PM +, Zakharychev, Bob wrote:
> FWIW: after a bit of experimentation and a quick dumb behavior comparison
> program I found that FD_SET is compiled incorrectly by GCC 8.3.0 under Cygwin
> with optimization level of -O2 and up. I compared native FD_SET/FD_ISSET with
> hap_fd_set/hap_fd_isset and while the latter always functions correctly, the
> former broke with -O2 and beyond. Further playing with optimizations enabled
> by -O2 I was able to narrow the offender down to -ftree-pre, which enables
> partial redundancy elimination (PRE) on trees. When tree PRE is enabled, GCC
> generates wrong code for inlined FD_SET in map initialization loop which
> results in most, and eventually all, bits of the map set when they shouldn't,
> which explains those superfluous escapes that caused reg-tests failures. When
> compiled with -fno-tree-pre, most reg-tests now pass. Still, since there is
> already native implementation of bit address lookup and it seems to work
> correctly with all optimizations enabled, maybe it's better just to switch to
> it.

Very interesting analysis, thank you for sharing it. In the mean time,
as I mentioned in the ticket, I got rid of FD_SET/FD_ISSET(). The relevant
commit is :

  commit 1bfd6020ce5f54120efd87906fd3675515ce4b8e
  Author: Willy Tarreau 
  Date:   Fri Jun 7 11:10:07 2019 +0200

MINOR: logs: use the new bitmap functions instead of fd_sets for encoding 
maps

The fd_sets we've been using in the log encoding functions are not portable
and were shown to break at least under Cygwin. This patch gets rid of them
in favor of the new bitmap functions. (...)

It's in latest 2.0-dev, was merged just after dev6. It should work just
fine in your situation.

Thanks!
Willy

RE: cygwin compilation error

[Zakharychev, Bob]

Willy,

> > Looks like it decided that non-letter characters had to be encoded. 
> > We're using FD_ISSET() to look up the characters in the character 
> > encoding map because this was convenient in the past, but maybe it's 
> > time to have a native implementation of a bit address lookup and get rid of 
> > this now.
>
> I've just created an issue about this one so we don't forget it.
>
> Willy

FWIW: after a bit of experimentation and a quick dumb behavior comparison 
program I found that FD_SET is compiled incorrectly by GCC 8.3.0 under Cygwin 
with optimization level of -O2 and up. I compared native FD_SET/FD_ISSET with 
hap_fd_set/hap_fd_isset and while the latter always functions correctly, the 
former broke with -O2 and beyond. Further playing with optimizations enabled by 
-O2 I was able to narrow the offender down to -ftree-pre, which enables partial 
redundancy elimination (PRE) on trees. When tree PRE is enabled, GCC generates 
wrong code for inlined FD_SET in map initialization loop which results in most, 
and eventually all, bits of the map set when they shouldn't, which explains 
those superfluous escapes that caused reg-tests failures. When compiled with 
-fno-tree-pre, most reg-tests now pass. Still, since there is already native 
implementation of bit address lookup and it seems to work correctly with all 
optimizations enabled, maybe it's better just to switch to it.

Bob

RE: cygwin compilation error

[Zakharychev, Bob]

>On Tue, Jun 04, 2019 at 09:46:04PM +, Zakharychev, Bob wrote:
>> I mean it returns 0. What happens is that as soon as the other side 
>> (haproxy) terminates, poll() starts returning immediately with 
>> positive return value and POLLIN being the only flag set in 
>> fd->revents as if there's something to read and descriptor is still open. 
>> read() then returns 0. Rinse, repeat.
>
>OK so this is a valid detection of end of response.
>
>> Since original VTest code only breaks the poll/read loop if either 
>> POLLHUP or POLLERR are also set in revents, which doesn't happen here 
>> for some reason,
>
> You should see POLLHUP and POLLERR as optimizations : when the system already 
> knows there will be such events it may place them, but similarly they could 
> also 
> happen between the moment you check the events and the moment you decide
> to read, so really a read() should always check for error and for zero.

Thanks for the explanation. I was under impression I'm missing something 
obvious here, but if this is expected behavior then I guess my workaround is 
not really a workaround. 😊

>> the loop never breaks until the thread itself times out (10 seconds) 
>> and gets killed. This, however, results in a "failed" test from VTest 
>> perspective. I think I can #ifdef __CYGWIN__ my changes to keep 
>> original behavior intact where it's known to work.

> I'd say "s/is known to work/happens to work/" :-) Probably that an issue 
> should be
> filed on this specific point for vtest to improve it (and its portability). 
> After all, nothing
> prevents poll() from being implemented using select() and it should work in 
> this situation.

Looking at Cygwin poll() source code it's actually the way it's implemented: 
using cygwin_select(), which seems to be a wrapper around pselect(). I'll 
suggest my patch to vtest.

Bob

Re: cygwin compilation error

[Илья Шипицин]

Bob,

we have added very basic cygwin CI

https://travis-ci.com/haproxy/haproxy/jobs/205561046

it is "build only". feel free to improve it :)

ср, 5 июн. 2019 г. в 02:49, Zakharychev, Bob :

> Willy,
>
> On Tue, Jun 04, 2019 at 05:52:12PM +, Zakharychev, Bob wrote:
> >> Finally got VTest compiling and working as expected (I think) under
> Cygwin.
> >> config.h had to be adjusted and vtc_syslog.c needed 
> >> included, but nothing big. However, there's some weird poll() behavior
> >> where it never raises POLLHUP or POLLERR and returns immediately with
> >> POLLIN flag raised when the other side disconnects but read()
> >> consistently returns no error and no data,
>
> > Note, by "no error and no data", do you mean "-1, EAGAIN" or "0" ?
> Because
> > the only case read() should return zero is when the end was reached.
> POLLHUP
> > is not even guaranteed to be presented at all. That's why most of the
> time you
> > see POLLHUP|POLLIN registered for the same handler.
>
> I mean it returns 0. What happens is that as soon as the other side
> (haproxy) terminates, poll() starts returning immediately with positive
> return value and POLLIN being the only flag set in fd->revents as if
> there's something to read and descriptor is still open. read() then returns
> 0. Rinse, repeat. Since original VTest code only breaks the poll/read loop
> if either POLLHUP or POLLERR are also set in revents, which doesn't happen
> here for some reason, the loop never breaks until the thread itself times
> out (10 seconds) and gets killed. This, however, results in a "failed" test
> from VTest perspective. I think I can #ifdef __CYGWIN__ my changes to keep
> original behavior intact where it's known to work.
>
> >> so when haproxy gets killed vtc_record() keeps polling its STDOUT
> >> until the thread itself times out because poll() doesn't seem to
> >> return correct flags.
> >>
> >> I hacked vtc_record() to exit the loop when poll() returns with POLLIN
> >> raised, but read() returns 0 bytes two times in a row. This got most
> >> of the reg-tests running successfully. Now some of them fail because
> >> the expected syslog format doesn't match what HA-Proxy actually logs:
> >>
> >>  Slog_1  0.2 syslog|<6>127.0.0.1:61336 [04/Jun/2019:12:56:28.053]
> ssl-offload-http~ ssl-offload-http/http 0/0/-1/-1/0 503 220 - - SC--
> 1/1/0/0/3 0/0 "POST#20#2F#31#20HTTP#2F#31#2E#31"
> >> **   Slog_1  0.2 === expect ~ "ssl-offload-http/http .* \"POST /[1-8]
> HTTP/(2\\.0...
> >>  Slog_1  0.2 EXPECT FAILED ~ "ssl-offload-http/http .* "POST /[1-8]
> HTTP/(2\.0|1\.1)""
>
> > Looks like it decided that non-letter characters had to be encoded.
> We're using FD_ISSET()
> > to look up the characters in the character encoding map because this was
> convenient in
> > the past, but maybe it's time to have a native implementation of a bit
> address lookup and
> > get rid of this now.
>
> > Good job!
> > Willy
>
> Thanks 😊
> Bob
>

Re: cygwin compilation error

[Willy Tarreau]

On Tue, Jun 04, 2019 at 09:46:04PM +, Zakharychev, Bob wrote:
> I mean it returns 0. What happens is that as soon as the other side (haproxy)
> terminates, poll() starts returning immediately with positive return value
> and POLLIN being the only flag set in fd->revents as if there's something to
> read and descriptor is still open. read() then returns 0. Rinse, repeat.

OK so this is a valid detection of end of response.

> Since original VTest code only breaks the poll/read loop if either POLLHUP or
> POLLERR are also set in revents, which doesn't happen here for some reason,

You should see POLLHUP and POLLERR as optimizations : when the system already
knows there will be such events it may place them, but similarly they could
also happen between the moment you check the events and the moment you decide
to read, so really a read() should always check for error and for zero.

> the loop never breaks until the thread itself times out (10 seconds) and gets
> killed. This, however, results in a "failed" test from VTest perspective. I
> think I can #ifdef __CYGWIN__ my changes to keep original behavior intact
> where it's known to work.

I'd say "s/is known to work/happens to work/" :-)
Probably that an issue should be filed on this specific point for vtest
to improve it (and its portability). After all, nothing prevents poll()
from being implemented using select() and it should work in this situation.

> > Looks like it decided that non-letter characters had to be encoded. We're 
> > using FD_ISSET() 
> > to look up the characters in the character encoding map because this was 
> > convenient in 
> > the past, but maybe it's time to have a native implementation of a bit 
> > address lookup and
> > get rid of this now.

I've just created an issue about this one so we don't forget it.

Willy

RE: cygwin compilation error

[Zakharychev, Bob]

Willy,

On Tue, Jun 04, 2019 at 05:52:12PM +, Zakharychev, Bob wrote:
>> Finally got VTest compiling and working as expected (I think) under Cygwin.
>> config.h had to be adjusted and vtc_syslog.c needed  
>> included, but nothing big. However, there's some weird poll() behavior 
>> where it never raises POLLHUP or POLLERR and returns immediately with 
>> POLLIN flag raised when the other side disconnects but read() 
>> consistently returns no error and no data,

> Note, by "no error and no data", do you mean "-1, EAGAIN" or "0" ? Because 
> the only case read() should return zero is when the end was reached. POLLHUP
> is not even guaranteed to be presented at all. That's why most of the time you
> see POLLHUP|POLLIN registered for the same handler.

I mean it returns 0. What happens is that as soon as the other side (haproxy) 
terminates, poll() starts returning immediately with positive return value and 
POLLIN being the only flag set in fd->revents as if there's something to read 
and descriptor is still open. read() then returns 0. Rinse, repeat. Since 
original VTest code only breaks the poll/read loop if either POLLHUP or POLLERR 
are also set in revents, which doesn't happen here for some reason, the loop 
never breaks until the thread itself times out (10 seconds) and gets killed. 
This, however, results in a "failed" test from VTest perspective. I think I can 
#ifdef __CYGWIN__ my changes to keep original behavior intact where it's known 
to work.

>> so when haproxy gets killed vtc_record() keeps polling its STDOUT 
>> until the thread itself times out because poll() doesn't seem to 
>> return correct flags.
>> 
>> I hacked vtc_record() to exit the loop when poll() returns with POLLIN 
>> raised, but read() returns 0 bytes two times in a row. This got most 
>> of the reg-tests running successfully. Now some of them fail because 
>> the expected syslog format doesn't match what HA-Proxy actually logs:
>> 
>>  Slog_1  0.2 syslog|<6>127.0.0.1:61336 [04/Jun/2019:12:56:28.053] 
>> ssl-offload-http~ ssl-offload-http/http 0/0/-1/-1/0 503 220 - - SC-- 
>> 1/1/0/0/3 0/0 "POST#20#2F#31#20HTTP#2F#31#2E#31"
>> **   Slog_1  0.2 === expect ~ "ssl-offload-http/http .* \"POST /[1-8] 
>> HTTP/(2\\.0...
>>  Slog_1  0.2 EXPECT FAILED ~ "ssl-offload-http/http .* "POST /[1-8] 
>> HTTP/(2\.0|1\.1)""

> Looks like it decided that non-letter characters had to be encoded. We're 
> using FD_ISSET() 
> to look up the characters in the character encoding map because this was 
> convenient in 
> the past, but maybe it's time to have a native implementation of a bit 
> address lookup and
> get rid of this now.

> Good job!
> Willy

Thanks 😊
Bob

Re: cygwin compilation error

[Willy Tarreau]

Hi Bob,

On Tue, Jun 04, 2019 at 05:52:12PM +, Zakharychev, Bob wrote:
> Finally got VTest compiling and working as expected (I think) under Cygwin.
> config.h had to be adjusted and vtc_syslog.c needed  included,
> but nothing big. However, there's some weird poll() behavior where it never
> raises POLLHUP or POLLERR and returns immediately with POLLIN flag raised
> when the other side disconnects but read() consistently returns no error and
> no data,

Note, by "no error and no data", do you mean "-1, EAGAIN" or "0" ? Because
the only case read() should return zero is when the end was reached. POLLHUP
is not even guaranteed to be presented at all. That's why most of the time
you see POLLHUP|POLLIN registered for the same handler.

> so when haproxy gets killed vtc_record() keeps polling its STDOUT
> until the thread itself times out because poll() doesn't seem to return
> correct flags.
> 
> I hacked vtc_record() to exit the loop when poll() returns with POLLIN
> raised, but read() returns 0 bytes two times in a row. This got most of the
> reg-tests running successfully. Now some of them fail because the expected
> syslog format doesn't match what HA-Proxy actually logs:
> 
>  Slog_1  0.2 syslog|<6>127.0.0.1:61336 [04/Jun/2019:12:56:28.053] 
> ssl-offload-http~ ssl-offload-http/http 0/0/-1/-1/0 503 220 - - SC-- 
> 1/1/0/0/3 0/0 "POST#20#2F#31#20HTTP#2F#31#2E#31"
> **   Slog_1  0.2 === expect ~ "ssl-offload-http/http .* \"POST /[1-8] 
> HTTP/(2\\.0...
>  Slog_1  0.2 EXPECT FAILED ~ "ssl-offload-http/http .* "POST /[1-8] 
> HTTP/(2\.0|1\.1)""

Looks like it decided that non-letter characters had to be encoded. We're
using FD_ISSET() to look up the characters in the character encoding map
because this was convenient in the past, but maybe it's time to have a
native implementation of a bit address lookup and get rid of this now.

Good job!
Willy

RE: cygwin compilation error

[Zakharychev, Bob]

Finally got VTest compiling and working as expected (I think) under Cygwin. 
config.h had to be adjusted and vtc_syslog.c needed  included, 
but nothing big. However, there’s some weird poll() behavior where it never 
raises POLLHUP or POLLERR and returns immediately with POLLIN flag raised when 
the other side disconnects but read() consistently returns no error and no 
data, so when haproxy gets killed vtc_record() keeps polling its STDOUT until 
the thread itself times out because poll() doesn’t seem to return correct flags.

I hacked vtc_record() to exit the loop when poll() returns with POLLIN raised, 
but read() returns 0 bytes two times in a row. This got most of the reg-tests 
running successfully. Now some of them fail because the expected syslog format 
doesn’t match what HA-Proxy actually logs:

 Slog_1  0.2 syslog|<6>127.0.0.1:61336 [04/Jun/2019:12:56:28.053] 
ssl-offload-http~ ssl-offload-http/http 0/0/-1/-1/0 503 220 - - SC-- 1/1/0/0/3 
0/0 "POST#20#2F#31#20HTTP#2F#31#2E#31"
**   Slog_1  0.2 === expect ~ "ssl-offload-http/http .* \"POST /[1-8] 
HTTP/(2\\.0...
 Slog_1  0.2 EXPECT FAILED ~ "ssl-offload-http/http .* "POST /[1-8] 
HTTP/(2\.0|1\.1)""

or

 S 0.2 syslog|<134>Jun  4 13:40:59 haproxy[49078]: 127.0.0.1:62880 
[04/Jun/2019:13:40:59.348] fe be/srv 0/0/0/34/34 200 17477 - -  1/1/0/0/0 
0/0 {#48#50#68#78#38#6E#35#39#71#6A#6A#4E#42#4C#6A#50} 
{#68#74#62#35#36#71#44#64#43#63#62#52#56#54#66#53} 
"GET#20#2F#20HTTP#2F#31#2E#31"
**   S 0.2 === expect ~ "[^:\\[ ]\\[${h_pid}\\]: .* .* fe be/srv .* 200 
1[0...
 S 0.2 EXPECT FAILED ~ "[^:\[ ]\[49078\]: .* .* fe be/srv .* 200 
1[0-9]{4} - -  .* .* {HPhx8n59qjjNBLjP} {htb56qDdCcbRVTfS} "GET / 
HTTP/1\.1""

I’ve no idea why it logs literals encoded like this and what should be changed 
in log configuration or maybe in build options to get it logging in expected 
format.

Bob

From: Илья Шипицин 
Sent: Monday, June 3, 2019 4:21 PM
To: Zakharychev, Bob 
Cc: HAProxy 
Subject: Re: cygwin compilation error

btw, Bob, can you run reg-tests on cygwin ? maybe you can prepare travis-ci 
config for cygwin ?

вт, 4 июн. 2019 г. в 00:57, Zakharychev, Bob 
mailto:bob.zakharyc...@spirent.com>>:
Ilya,

FWIW: I tried to build 2.0-dev5 on my working copy of Cygwin-64 3.0.7 with GCC 
toolchain 8.3.0 running just

make TARGET=cygwin

and it compiled successfully, but initially didn’t link due to

src/mux_h2.o: In function `h2s_frt_make_resp_data':
/build/haproxy-2.0-dev5/src/mux_h2.c:4405: undefined reference to `trace'
/build/haproxy-2.0-dev5/src/mux_h2.c:4405:(.text+0xce79): relocation truncated 
to fit: R_X86_64_PC32 against undefined symbol `trace'
collect2: error: ld returned 1 exit status
make: *** [Makefile:821: haproxy] Error 1

I think this is due to lack of support for weak function attribute in the 
Cygwin GCC linker – one comment about USE_OBSOLETE_LINKER in the code seems to 
be mentioning this as well. I added a crude workaround and successfully linked 
the executable with it. Here’s the patch, maybe you folks can improve it or 
just accept it as is. It just uses the TRACE flag and conditionally defines the 
dummy trace() in standard.c if the flag is not present (which is essentially 
the same as having the linker override a weak function).

diff -uw a/src/standard.c b/src/standard.c
--- a/src/standard.c  2019-06-02 06:06:08.0 -0400
+++ b/src/standard.c  2019-06-03 14:23:15.437931700 -0400
@@ -4298,10 +4298,12 @@
}
 /* do nothing, just a placeholder for debugging calls, the real one is in 
trace.c */
-__attribute__((weak,format(printf, 1, 2)))
+#ifndef TRACE
+__attribute__((format(printf, 1, 2)))
void trace(char *msg, ...)
{
}
+#endif
 /*
  * Local variables:

I also ran into a linker warning when building with Lua support:

/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld: 
warning: --export-dynamic is not supported for PE+ targets, did you mean 
--export-all-symbols?

I was able to get rid of it with the following modification to the Makefile 
(what the warning suggested):

diff -uw a/Makefile b/Makefile
--- a/Makefile  2019-06-02 06:06:08.0 -0400
+++ b/Makefile  2019-06-03 14:48:47.098917100 -0400
@@ -406,6 +406,8 @@
 USE_POLL USE_TPROXY USE_OBSOLETE_LINKER)
   # Cygwin adds IPv6 support only in version 1.7 (in beta right now).
   TARGET_CFLAGS  = $(if $(filter 1.5.%, $(shell uname -r)), -DUSE_IPV6 
-DAF_INET6=23 -DINET6_ADDRSTRLEN=46, )
+  # --export-dynamic is not the right way to export symbols in Cygwin
+  EXPORT_SYMBOL = --export-all-symbols
endif

# set the default settings according to the target above

Other than these two rather small issues 2.0-dev5 built successfully on my 
Cygwin (and I then also successfully built it with threading support, PCRE, 
ZLib, OpenSSL and Lua 5.3 by enabling corresponding flags though I didn’t run 
any tests), so something 

Re: cygwin compilation error

[Илья Шипицин]

вт, 4 июн. 2019 г. в 01:23, Zakharychev, Bob :

> Ilya,
>
>
>
> Try pulling in gcc-core libgcc1 binutils. I can’t actually see how it’s
> compiling without a compiler :), but worth trying. Also, check output from
>

it had picked gcc from windows :)


installing "gcc-core" resolved that


>
> cpp -v /dev/null -o /dev/null
>
>
>
> This should print the search path – we can then verify that /usr/include
> and other dirs are in it.
>
>
>
> Bob
>
>
>
> *From:* Илья Шипицин 
> *Sent:* Monday, June 3, 2019 4:09 PM
> *To:* Zakharychev, Bob 
> *Cc:* HAProxy 
> *Subject:* Re: cygwin compilation error
>
>
>
>
>
> I use the following command to build environment:
>
>
>
> https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L10
>
>
>
>
>
> "poll.h" is located in /usr/include
>
>
>
> https://travis-ci.com/chipitsine/haproxy/builds/114162585#L231
>

RE: cygwin compilation error

[Zakharychev, Bob]

Ilya,

Try pulling in gcc-core libgcc1 binutils. I can’t actually see how it’s 
compiling without a compiler :), but worth trying. Also, check output from

cpp -v /dev/null -o /dev/null

This should print the search path – we can then verify that /usr/include and 
other dirs are in it.

Bob

From: Илья Шипицин 
Sent: Monday, June 3, 2019 4:09 PM
To: Zakharychev, Bob 
Cc: HAProxy 
Subject: Re: cygwin compilation error


I use the following command to build environment:

https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L10


"poll.h" is located in /usr/include

https://travis-ci.com/chipitsine/haproxy/builds/114162585#L231

Re: cygwin compilation error

[Илья Шипицин]

btw, Bob, can you run reg-tests on cygwin ? maybe you can prepare travis-ci
config for cygwin ?

вт, 4 июн. 2019 г. в 00:57, Zakharychev, Bob :

> Ilya,
>
>
>
> FWIW: I tried to build 2.0-dev5 on my working copy of Cygwin-64 3.0.7 with
> GCC toolchain 8.3.0 running just
>
>
>
> make TARGET=cygwin
>
>
>
> and it compiled successfully, but initially didn’t link due to
>
>
>
> src/mux_h2.o: In function `h2s_frt_make_resp_data':
>
> /build/haproxy-2.0-dev5/src/mux_h2.c:4405: undefined reference to `trace'
>
> /build/haproxy-2.0-dev5/src/mux_h2.c:4405:(.text+0xce79): relocation
> truncated to fit: R_X86_64_PC32 against undefined symbol `trace'
>
> collect2: error: ld returned 1 exit status
>
> make: *** [Makefile:821: haproxy] Error 1
>
>
>
> I think this is due to lack of support for weak function attribute in the
> Cygwin GCC linker – one comment about USE_OBSOLETE_LINKER in the code seems
> to be mentioning this as well. I added a crude workaround and successfully
> linked the executable with it. Here’s the patch, maybe you folks can
> improve it or just accept it as is. It just uses the TRACE flag and
> conditionally defines the dummy trace() in standard.c if the flag is not
> present (which is essentially the same as having the linker override a weak
> function).
>
>
>
> diff -uw a/src/standard.c b/src/standard.c
>
> --- a/src/standard.c  2019-06-02 06:06:08.0 -0400
>
> +++ b/src/standard.c  2019-06-03 14:23:15.437931700 -0400
>
> @@ -4298,10 +4298,12 @@
>
> }
>
>  /* do nothing, just a placeholder for debugging calls, the real one is in
> trace.c */
>
> -__attribute__((weak,format(printf, 1, 2)))
>
> +#ifndef TRACE
>
> +__attribute__((format(printf, 1, 2)))
>
> void trace(char *msg, ...)
>
> {
>
> }
>
> +#endif
>
>  /*
>
>   * Local variables:
>
>
>
> I also ran into a linker warning when building with Lua support:
>
>
>
> /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> warning: --export-dynamic is not supported for PE+ targets, did you mean
> --export-all-symbols?
>
>
>
> I was able to get rid of it with the following modification to the
> Makefile (what the warning suggested):
>
>
>
> diff -uw a/Makefile b/Makefile
>
> --- a/Makefile  2019-06-02 06:06:08.0 -0400
>
> +++ b/Makefile  2019-06-03 14:48:47.098917100 -0400
>
> @@ -406,6 +406,8 @@
>
>  USE_POLL USE_TPROXY USE_OBSOLETE_LINKER)
>
># Cygwin adds IPv6 support only in version 1.7 (in beta right now).
>
>TARGET_CFLAGS  = $(if $(filter 1.5.%, $(shell uname -r)), -DUSE_IPV6
> -DAF_INET6=23 -DINET6_ADDRSTRLEN=46, )
>
> +  # --export-dynamic is not the right way to export symbols in Cygwin
>
> +  EXPORT_SYMBOL = --export-all-symbols
>
> endif
>
>
>
> # set the default settings according to the target above
>
>
>
> Other than these two rather small issues 2.0-dev5 built successfully on my
> Cygwin (and I then also successfully built it with threading support, PCRE,
> ZLib, OpenSSL and Lua 5.3 by enabling corresponding flags though I didn’t
> run any tests), so something must be missing in your build environment.
> Most system headers should be in /usr/include if cygwin-devel is installed,
> so you might want to start with checking if expected header files are there…
>
>
>
> Hth,
>
>Bob
>
>
>
> *From:* Илья Шипицин 
> *Sent:* Monday, June 3, 2019 11:03 AM
> *To:* Gil Bahat 
> *Cc:* Willy Tarreau ; HAProxy 
> *Subject:* Re: cygwin compilation error
>
>
>
>
>
>
>
> пн, 3 июн. 2019 г. в 20:00, Gil Bahat :
>
> poll.h seems to be present at cygwin-devel:
>
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h&arch=x86_64
>
>
>
> hope that helps.
>
>
>
>
>
>
>
> cygwin-devel is installed
>
>
>
> https://travis-ci.com/chipitsine/haproxy/builds/114061737#L165-L172
>
>
>
>
>
> Regards,
>
>
>
> Gil
>
>
>
> On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин  wrote:
>
>
>
>
>
> пн, 3 июн. 2019 г. в 17:56, Willy Tarreau :
>
> Hi Ilya,
>
> On Mon, Jun 03, 2019 at 01:57:48PM +0500,  ??? wrote:
> > Hello, Gil Bahat!
> >
> > can you help with troubleshooting?
> >
> > I created some basic cygwin CI:
> >
> > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
> >
> > it fails with
> >
> > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
> >  #include 
> >   ^~~~
> > compilation terminated.
> > make: *** [Makefile:830: src/ev_poll.o] Error 1
> >
> > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
> >
> > do you know which package does "poll.h" belongs to ?
>
> Interesting, maybe poll() should be disabled on cygwin and we'd only
> keep select ? (just build with "USE_POLL=" for this).
>
>
>
> I'll try that.
>
>
>
> Actually, I think that I need to install some missing cygwin package
>
> (I installed very few of them using "choco install bash make
> openssl-devel cygwin-devel --source cygwin")
>
>
>
>
> Willy
>
>

Re: cygwin compilation error

[Илья Шипицин]

вт, 4 июн. 2019 г. в 00:57, Zakharychev, Bob :

> Ilya,
>
>
>
> FWIW: I tried to build 2.0-dev5 on my working copy of Cygwin-64 3.0.7 with
> GCC toolchain 8.3.0 running just
>
>
>
> make TARGET=cygwin
>
>
>
> and it compiled successfully, but initially didn’t link due to
>
>
>
> src/mux_h2.o: In function `h2s_frt_make_resp_data':
>
> /build/haproxy-2.0-dev5/src/mux_h2.c:4405: undefined reference to `trace'
>
> /build/haproxy-2.0-dev5/src/mux_h2.c:4405:(.text+0xce79): relocation
> truncated to fit: R_X86_64_PC32 against undefined symbol `trace'
>
> collect2: error: ld returned 1 exit status
>
> make: *** [Makefile:821: haproxy] Error 1
>
>
>
> I think this is due to lack of support for weak function attribute in the
> Cygwin GCC linker – one comment about USE_OBSOLETE_LINKER in the code seems
> to be mentioning this as well. I added a crude workaround and successfully
> linked the executable with it. Here’s the patch, maybe you folks can
> improve it or just accept it as is. It just uses the TRACE flag and
> conditionally defines the dummy trace() in standard.c if the flag is not
> present (which is essentially the same as having the linker override a weak
> function).
>
>
>
> diff -uw a/src/standard.c b/src/standard.c
>
> --- a/src/standard.c  2019-06-02 06:06:08.0 -0400
>
> +++ b/src/standard.c  2019-06-03 14:23:15.437931700 -0400
>
> @@ -4298,10 +4298,12 @@
>
> }
>
>  /* do nothing, just a placeholder for debugging calls, the real one is in
> trace.c */
>
> -__attribute__((weak,format(printf, 1, 2)))
>
> +#ifndef TRACE
>
> +__attribute__((format(printf, 1, 2)))
>
> void trace(char *msg, ...)
>
> {
>
> }
>
> +#endif
>
>  /*
>
>   * Local variables:
>
>
>
> I also ran into a linker warning when building with Lua support:
>
>
>
> /usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld:
> warning: --export-dynamic is not supported for PE+ targets, did you mean
> --export-all-symbols?
>
>
>
> I was able to get rid of it with the following modification to the
> Makefile (what the warning suggested):
>
>
>
> diff -uw a/Makefile b/Makefile
>
> --- a/Makefile  2019-06-02 06:06:08.0 -0400
>
> +++ b/Makefile  2019-06-03 14:48:47.098917100 -0400
>
> @@ -406,6 +406,8 @@
>
>  USE_POLL USE_TPROXY USE_OBSOLETE_LINKER)
>
># Cygwin adds IPv6 support only in version 1.7 (in beta right now).
>
>TARGET_CFLAGS  = $(if $(filter 1.5.%, $(shell uname -r)), -DUSE_IPV6
> -DAF_INET6=23 -DINET6_ADDRSTRLEN=46, )
>
> +  # --export-dynamic is not the right way to export symbols in Cygwin
>
> +  EXPORT_SYMBOL = --export-all-symbols
>
> endif
>
>
>
> # set the default settings according to the target above
>
>
>
> Other than these two rather small issues 2.0-dev5 built successfully on my
> Cygwin (and I then also successfully built it with threading support, PCRE,
> ZLib, OpenSSL and Lua 5.3 by enabling corresponding flags though I didn’t
> run any tests), so something must be missing in your build environment.
> Most system headers should be in /usr/include if cygwin-devel is installed,
> so you might want to start with checking if expected header files are there…
>


"something must be missing in your build environment" ... travis-ci is an
ephemeral environment. it is built from scratch every time.


I use the following command to build environment:

https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L10


"poll.h" is located in /usr/include

https://travis-ci.com/chipitsine/haproxy/builds/114162585#L231


>
>
> Hth,
>
>Bob
>
>
>
> *From:* Илья Шипицин 
> *Sent:* Monday, June 3, 2019 11:03 AM
> *To:* Gil Bahat 
> *Cc:* Willy Tarreau ; HAProxy 
> *Subject:* Re: cygwin compilation error
>
>
>
>
>
>
>
> пн, 3 июн. 2019 г. в 20:00, Gil Bahat :
>
> poll.h seems to be present at cygwin-devel:
>
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h&arch=x86_64
>
>
>
> hope that helps.
>
>
>
>
>
>
>
> cygwin-devel is installed
>
>
>
> https://travis-ci.com/chipitsine/haproxy/builds/114061737#L165-L172
>
>
>
>
>
> Regards,
>
>
>
> Gil
>
>
>
> On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин  wrote:
>
>
>
>
>
> пн, 3 июн. 2019 г. в 17:56, Willy Tarreau :
>
> Hi Ilya,
>
> On Mon, Jun 03, 2019 at 01:57:48PM +0500,  ??? wrote:
> > Hello, Gil Bahat!
> >
> > can you help with troubleshooting?
> >
> > I created some basic cygwin CI:
> >
> > https://g

RE: cygwin compilation error

[Zakharychev, Bob]

Ilya,

FWIW: I tried to build 2.0-dev5 on my working copy of Cygwin-64 3.0.7 with GCC 
toolchain 8.3.0 running just

make TARGET=cygwin

and it compiled successfully, but initially didn’t link due to

src/mux_h2.o: In function `h2s_frt_make_resp_data':
/build/haproxy-2.0-dev5/src/mux_h2.c:4405: undefined reference to `trace'
/build/haproxy-2.0-dev5/src/mux_h2.c:4405:(.text+0xce79): relocation truncated 
to fit: R_X86_64_PC32 against undefined symbol `trace'
collect2: error: ld returned 1 exit status
make: *** [Makefile:821: haproxy] Error 1

I think this is due to lack of support for weak function attribute in the 
Cygwin GCC linker – one comment about USE_OBSOLETE_LINKER in the code seems to 
be mentioning this as well. I added a crude workaround and successfully linked 
the executable with it. Here’s the patch, maybe you folks can improve it or 
just accept it as is. It just uses the TRACE flag and conditionally defines the 
dummy trace() in standard.c if the flag is not present (which is essentially 
the same as having the linker override a weak function).

diff -uw a/src/standard.c b/src/standard.c
--- a/src/standard.c  2019-06-02 06:06:08.0 -0400
+++ b/src/standard.c  2019-06-03 14:23:15.437931700 -0400
@@ -4298,10 +4298,12 @@
}
 /* do nothing, just a placeholder for debugging calls, the real one is in 
trace.c */
-__attribute__((weak,format(printf, 1, 2)))
+#ifndef TRACE
+__attribute__((format(printf, 1, 2)))
void trace(char *msg, ...)
{
}
+#endif
 /*
  * Local variables:

I also ran into a linker warning when building with Lua support:

/usr/lib/gcc/x86_64-pc-cygwin/8.3.0/../../../../x86_64-pc-cygwin/bin/ld: 
warning: --export-dynamic is not supported for PE+ targets, did you mean 
--export-all-symbols?

I was able to get rid of it with the following modification to the Makefile 
(what the warning suggested):

diff -uw a/Makefile b/Makefile
--- a/Makefile  2019-06-02 06:06:08.0 -0400
+++ b/Makefile  2019-06-03 14:48:47.098917100 -0400
@@ -406,6 +406,8 @@
 USE_POLL USE_TPROXY USE_OBSOLETE_LINKER)
   # Cygwin adds IPv6 support only in version 1.7 (in beta right now).
   TARGET_CFLAGS  = $(if $(filter 1.5.%, $(shell uname -r)), -DUSE_IPV6 
-DAF_INET6=23 -DINET6_ADDRSTRLEN=46, )
+  # --export-dynamic is not the right way to export symbols in Cygwin
+  EXPORT_SYMBOL = --export-all-symbols
endif

# set the default settings according to the target above

Other than these two rather small issues 2.0-dev5 built successfully on my 
Cygwin (and I then also successfully built it with threading support, PCRE, 
ZLib, OpenSSL and Lua 5.3 by enabling corresponding flags though I didn’t run 
any tests), so something must be missing in your build environment. Most system 
headers should be in /usr/include if cygwin-devel is installed, so you might 
want to start with checking if expected header files are there…

Hth,
   Bob

From: Илья Шипицин 
Sent: Monday, June 3, 2019 11:03 AM
To: Gil Bahat 
Cc: Willy Tarreau ; HAProxy 
Subject: Re: cygwin compilation error



пн, 3 июн. 2019 г. в 20:00, Gil Bahat 
mailto:bahat@gmail.com>>:
poll.h seems to be present at cygwin-devel:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h&arch=x86_64

hope that helps.



cygwin-devel is installed

https://travis-ci.com/chipitsine/haproxy/builds/114061737#L165-L172


Regards,

Gil

On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин 
mailto:chipits...@gmail.com>> wrote:


пн, 3 июн. 2019 г. в 17:56, Willy Tarreau mailto:w...@1wt.eu>>:
Hi Ilya,

On Mon, Jun 03, 2019 at 01:57:48PM +0500,  ??? wrote:
> Hello, Gil Bahat!
>
> can you help with troubleshooting?
>
> I created some basic cygwin CI:
>
> https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
>
> it fails with
>
> src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
>  #include 
>   ^~~~
> compilation terminated.
> make: *** [Makefile:830: src/ev_poll.o] Error 1
>
> (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
>
> do you know which package does "poll.h" belongs to ?

Interesting, maybe poll() should be disabled on cygwin and we'd only
keep select ? (just build with "USE_POLL=" for this).

I'll try that.

Actually, I think that I need to install some missing cygwin package
(I installed very few of them using "choco install bash make openssl-devel 
cygwin-devel --source cygwin")


Willy

Re: cygwin compilation error

[Илья Шипицин]

пн, 3 июн. 2019 г. в 20:00, Gil Bahat :

> poll.h seems to be present at cygwin-devel:
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h&arch=x86_64
>
> hope that helps.
>
>

cygwin-devel is installed

https://travis-ci.com/chipitsine/haproxy/builds/114061737#L165-L172



> Regards,
>
> Gil
>
> On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин  wrote:
>
>>
>>
>> пн, 3 июн. 2019 г. в 17:56, Willy Tarreau :
>>
>>> Hi Ilya,
>>>
>>> On Mon, Jun 03, 2019 at 01:57:48PM +0500,  ??? wrote:
>>> > Hello, Gil Bahat!
>>> >
>>> > can you help with troubleshooting?
>>> >
>>> > I created some basic cygwin CI:
>>> >
>>> > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
>>> >
>>> > it fails with
>>> >
>>> > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
>>> >  #include 
>>> >   ^~~~
>>> > compilation terminated.
>>> > make: *** [Makefile:830: src/ev_poll.o] Error 1
>>> >
>>> > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
>>> >
>>> > do you know which package does "poll.h" belongs to ?
>>>
>>> Interesting, maybe poll() should be disabled on cygwin and we'd only
>>> keep select ? (just build with "USE_POLL=" for this).
>>>
>>
>> I'll try that.
>>
>> Actually, I think that I need to install some missing cygwin package
>> (I installed very few of them using "choco install bash make
>> openssl-devel cygwin-devel --source cygwin")
>>
>>
>>>
>>> Willy
>>>
>>

Re: cygwin compilation error

[Gil Bahat]

poll.h seems to be present at cygwin-devel:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h&arch=x86_64

hope that helps.

Regards,

Gil

On Mon, Jun 3, 2019 at 5:53 PM Илья Шипицин  wrote:

>
>
> пн, 3 июн. 2019 г. в 17:56, Willy Tarreau :
>
>> Hi Ilya,
>>
>> On Mon, Jun 03, 2019 at 01:57:48PM +0500,  ??? wrote:
>> > Hello, Gil Bahat!
>> >
>> > can you help with troubleshooting?
>> >
>> > I created some basic cygwin CI:
>> >
>> > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
>> >
>> > it fails with
>> >
>> > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
>> >  #include 
>> >   ^~~~
>> > compilation terminated.
>> > make: *** [Makefile:830: src/ev_poll.o] Error 1
>> >
>> > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
>> >
>> > do you know which package does "poll.h" belongs to ?
>>
>> Interesting, maybe poll() should be disabled on cygwin and we'd only
>> keep select ? (just build with "USE_POLL=" for this).
>>
>
> I'll try that.
>
> Actually, I think that I need to install some missing cygwin package
> (I installed very few of them using "choco install bash make
> openssl-devel cygwin-devel --source cygwin")
>
>
>>
>> Willy
>>
>

Re: cygwin compilation error

[Илья Шипицин]

пн, 3 июн. 2019 г. в 17:56, Willy Tarreau :

> Hi Ilya,
>
> On Mon, Jun 03, 2019 at 01:57:48PM +0500,  ??? wrote:
> > Hello, Gil Bahat!
> >
> > can you help with troubleshooting?
> >
> > I created some basic cygwin CI:
> >
> > https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
> >
> > it fails with
> >
> > src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
> >  #include 
> >   ^~~~
> > compilation terminated.
> > make: *** [Makefile:830: src/ev_poll.o] Error 1
> >
> > (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
> >
> > do you know which package does "poll.h" belongs to ?
>
> Interesting, maybe poll() should be disabled on cygwin and we'd only
> keep select ? (just build with "USE_POLL=" for this).
>

I'll try that.

Actually, I think that I need to install some missing cygwin package
(I installed very few of them using "choco install bash make openssl-devel
cygwin-devel --source cygwin")


>
> Willy
>

Re: cygwin compilation error

[Willy Tarreau]

Hi Ilya,

On Mon, Jun 03, 2019 at 01:57:48PM +0500,  ??? wrote:
> Hello, Gil Bahat!
> 
> can you help with troubleshooting?
> 
> I created some basic cygwin CI:
> 
> https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
> 
> it fails with
> 
> src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
>  #include 
>   ^~~~
> compilation terminated.
> make: *** [Makefile:830: src/ev_poll.o] Error 1
> 
> (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
> 
> do you know which package does "poll.h" belongs to ?

Interesting, maybe poll() should be disabled on cygwin and we'd only
keep select ? (just build with "USE_POLL=" for this).

Willy

Re: cygwin compilation error

[Илья Шипицин]

I forgot to notice - haproxy is very close to 2.0 release (about 2 weeks or
so).
we wish to be sure it works on cygwin before 2.0 released

пн, 3 июн. 2019 г. в 13:57, Илья Шипицин :

> Hello, Gil Bahat!
>
> can you help with troubleshooting?
>
> I created some basic cygwin CI:
>
> https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30
>
> it fails with
>
> src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
>  #include 
>   ^~~~
> compilation terminated.
> make: *** [Makefile:830: src/ev_poll.o] Error 1
>
> (full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )
>
> do you know which package does "poll.h" belongs to ?
>
>
> пн, 6 мая 2019 г. в 14:57, Gil Bahat :
>
>> Hi,
>>
>> is cygwin still supported anymore? the target seems to be present in the
>> Makefiles and I'd love to be able to use it. I'm running into what seems to
>> be a workable linker error:
>>
>> $ make TARGET=cygwin
>>   LD  haproxy
>> src/http_act.o:http_act.c:(.rdata+0x340): multiple definition of
>> `.weak.ist_uc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
>> src/http_act.o:http_act.c:(.rdata+0x440): multiple definition of
>> `.weak.ist_lc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
>> src/raw_sock.o:raw_sock.c:(.rdata+0x0): multiple definition of
>> `.weak.ist_uc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
>> src/raw_sock.o:raw_sock.c:(.rdata+0x100): multiple definition of
>> `.weak.ist_lc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
>> src/proto_uxst.o:proto_uxst.c:(.rdata+0x560): multiple definition of
>> `.weak.ist_uc.___chkstk_ms'
>> src/mux_h2.o:mux_h2.c:(.rdata+0x800): first defined here
>> src/proto_uxst.o:proto_uxst.c:(.rdata+0x660): multiple definition of
>> `.weak.ist_lc.___chkstk_ms'
>> src/mux_h2.o:mux_h2.c:(.rdata+0x900): first defined here
>> src/ev_select.o:ev_select.c:(.rdata+0x20): multiple definition of
>> `.weak.ist_uc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
>> src/ev_select.o:ev_select.c:(.rdata+0x120): multiple definition of
>> `.weak.ist_lc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
>> src/http_conv.o:http_conv.c:(.rdata+0x60): multiple definition of
>> `.weak.ist_uc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
>> src/http_conv.o:http_conv.c:(.rdata+0x160): multiple definition of
>> `.weak.ist_lc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
>> src/http_acl.o:http_acl.c:(.rdata+0x280): multiple definition of
>> `.weak.ist_uc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
>> src/http_acl.o:http_acl.c:(.rdata+0x380): multiple definition of
>> `.weak.ist_lc.'
>> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
>> collect2: error: ld returned 1 exit status
>> make: *** [Makefile:994: haproxy] Error 1
>>
>> it feels like it's something trivial but I'm not versed enough to get a
>> hold on it. any help would be appreciated.
>>
>> Regards,
>>
>> Gil
>>
>

Re: cygwin compilation error

[Илья Шипицин]

Hello, Gil Bahat!

can you help with troubleshooting?

I created some basic cygwin CI:

https://github.com/chipitsine/haproxy/blob/master/.travis.yml#L25-L30

it fails with

src/ev_poll.c:16:10: fatal error: poll.h: No such file or directory
 #include 
  ^~~~
compilation terminated.
make: *** [Makefile:830: src/ev_poll.o] Error 1

(full log: https://travis-ci.com/chipitsine/haproxy/builds/114061737 )

do you know which package does "poll.h" belongs to ?


пн, 6 мая 2019 г. в 14:57, Gil Bahat :

> Hi,
>
> is cygwin still supported anymore? the target seems to be present in the
> Makefiles and I'd love to be able to use it. I'm running into what seems to
> be a workable linker error:
>
> $ make TARGET=cygwin
>   LD  haproxy
> src/http_act.o:http_act.c:(.rdata+0x340): multiple definition of
> `.weak.ist_uc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
> src/http_act.o:http_act.c:(.rdata+0x440): multiple definition of
> `.weak.ist_lc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
> src/raw_sock.o:raw_sock.c:(.rdata+0x0): multiple definition of
> `.weak.ist_uc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
> src/raw_sock.o:raw_sock.c:(.rdata+0x100): multiple definition of
> `.weak.ist_lc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
> src/proto_uxst.o:proto_uxst.c:(.rdata+0x560): multiple definition of
> `.weak.ist_uc.___chkstk_ms'
> src/mux_h2.o:mux_h2.c:(.rdata+0x800): first defined here
> src/proto_uxst.o:proto_uxst.c:(.rdata+0x660): multiple definition of
> `.weak.ist_lc.___chkstk_ms'
> src/mux_h2.o:mux_h2.c:(.rdata+0x900): first defined here
> src/ev_select.o:ev_select.c:(.rdata+0x20): multiple definition of
> `.weak.ist_uc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
> src/ev_select.o:ev_select.c:(.rdata+0x120): multiple definition of
> `.weak.ist_lc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
> src/http_conv.o:http_conv.c:(.rdata+0x60): multiple definition of
> `.weak.ist_uc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
> src/http_conv.o:http_conv.c:(.rdata+0x160): multiple definition of
> `.weak.ist_lc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
> src/http_acl.o:http_acl.c:(.rdata+0x280): multiple definition of
> `.weak.ist_uc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
> src/http_acl.o:http_acl.c:(.rdata+0x380): multiple definition of
> `.weak.ist_lc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x120): first defined here
> collect2: error: ld returned 1 exit status
> make: *** [Makefile:994: haproxy] Error 1
>
> it feels like it's something trivial but I'm not versed enough to get a
> hold on it. any help would be appreciated.
>
> Regards,
>
> Gil
>

Re: cygwin compilation error

[Gil Bahat]

it turns out 1.8.20 does compile neatly, this should suffice for us for the
time being. this is also a strong indication that whatever needs fixing is
minor enough.

Gil

On Sun, May 12, 2019 at 11:12 AM Willy Tarreau  wrote:

> On Sun, May 12, 2019 at 09:26:18AM +0300, Gil Bahat wrote:
> > none of these work for me to resolve the problem. guess it's a bit more
> > complicated than that.
>
> OK, thanks for trying at least.
>
> willy
>

Re: cygwin compilation error

[Willy Tarreau]

On Sun, May 12, 2019 at 09:26:18AM +0300, Gil Bahat wrote:
> none of these work for me to resolve the problem. guess it's a bit more
> complicated than that.

OK, thanks for trying at least.

willy

Re: cygwin compilation error

[Gil Bahat]

none of these work for me to resolve the problem. guess it's a bit more
complicated than that.

On Wed, May 8, 2019 at 8:49 AM Willy Tarreau  wrote:

> Hi,
>
> On Mon, May 06, 2019 at 12:54:47PM +0300, Gil Bahat wrote:
> > Hi,
> >
> > is cygwin still supported anymore?
>
> Well, we never know :-)  I mean, we're always open to fixes to make it
> work as long as they don't impact other platforms.
>
> > the target seems to be present in the
> > Makefiles and I'd love to be able to use it. I'm running into what seems
> to
> > be a workable linker error:
> >
> > $ make TARGET=cygwin
> >   LD  haproxy
> > src/http_act.o:http_act.c:(.rdata+0x340): multiple definition of
> > `.weak.ist_uc.'
> > src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
>
> Aie that's really bad, it means the linker doesn't support weak symbols :-(
> Weak symbols are very handy as they are able to be included and linked in
> only once if they are used, and not linked if unused. The info I'm finding
> on the net suggest that symbols must be resolved at link time, which is the
> case here. So maybe it's just a matter of definition.
>
> I can suggest a few things to try in include/common/ist.h :
>
>   - replace "__weak__" with "weak" just in case it's different there
> (I don't even know why I marked it "__weak__", probably just by
> mimetism with "__attribute__" and because it worked
>
>   - add "#pragma weak ist_lc" and "#pragma weak ist_uc" in ist.h,
> before the definitions
>
>   - add "extern const unsigned char ist_lc[256];" and
> "extern const unsigned char ist_uc[256];" before the definitions
>
> In case one of them is enough to work, we can merge them.
>
> Thanks,
> Willy
>

Re: cygwin compilation error

[Willy Tarreau]

Hello!

On Wed, May 08, 2019 at 10:13:38PM +, Zakharychev, Bob wrote:
> I wouldn't bother even trying to add support for BoringSSL - they themselves
> discourage people from doing so in their mission statement:
> 
> "Although BoringSSL is an open source project, it is not intended for general
> use, as OpenSSL is. We don't recommend that third parties depend upon it.
> Doing so is likely to be frustrating because there are no guarantees of API
> or ABI stability.
> 
> Programs ship their own copies of BoringSSL when they use it and we update
> everything as needed when deciding to make API changes. This allows us to
> mostly avoid compromises in the name of compatibility. It works for us, but
> it may not work for you."

These are pretty valid points! Actually I'd say that we know some people
do use BoringSSL with haproxy and provide regular fixes for it, so the
maintenance cost for others remains low. If it starts to break here and
there, or to trigger false alarms on the CI, then it will be time to 1)
remove it from the CI, and maybe 2) stop supporting it. But as long as
it works it's an inexpensive indicator of the probability of forthcoming
user reports ;-)

Thanks,
Willy

RE: cygwin compilation error

[Zakharychev, Bob]

Ilya Shipitsin wrote on Wed, 08 May 2019 03:22:20 -0700:

>I guess the same would be with BoringSSL. It exposes OPENSSL_VERSION_NUMBER
>and it is not openssl itself.
>
>yes, we can add warning.

I wouldn't bother even trying to add support for BoringSSL - they themselves 
discourage people from doing so in their mission statement:

"Although BoringSSL is an open source project, it is not intended for general 
use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing 
so is likely to be frustrating because there are no guarantees of API or ABI 
stability.

Programs ship their own copies of BoringSSL when they use it and we update 
everything as needed when deciding to make API changes. This allows us to 
mostly avoid compromises in the name of compatibility. It works for us, but it 
may not work for you."

Regards,
Bob

Re: cygwin compilation error

[Илья Шипицин]

ср, 8 мая 2019 г. в 14:50, Willy Tarreau :

> On Wed, May 08, 2019 at 02:06:31PM +0500,  ??? wrote:
> > > Ilya, could you please instead change the test like this and test
> again :
> > >
> > > -#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L)
> > > +#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x1010100fL)
> > >
> >
> > LibreSSL defines is
> >
> > #define OPENSSL_VERSION_NUMBER0x2000L
> >
> > it is bigger then any released OpenSSL (yet, for openssl master it is
> 3.0.0)
>
> So this behaviour from them make them complete bastards and will
> constantly break each and every program trying to build with it :-(
>
> This stupidity really makes me want to completely remove support for
> libressl.
>


I guess the same would be with BoringSSL. It exposes OPENSSL_VERSION_NUMBER
and it is not openssl itself.

yes, we can add warning.


>
> I don't know when they forked nor what is the latest version they are
> *really* compatible with, but what we should probably do is to change
> their marketing version to a real version in the compat.h file to do
> something like this :
>
> #if defined(LIBRESSL_VERSION_NUMBER)
> #undef OPENSSL_VERSION_NUMBER
> #define OPENSSL_VERSION_NUMBER 0x10something
> #endif
>
> This way we won't have to guard ourselves against these lies each and
> every time we add something to deal with some openssl-specific issues
> or features. Ideas welcome, of course. If for any reason we can't do
> something like the above, we should at least add a big fat warning when
> building with it to explicitly mention that it uses fake version numbers
> overlapping with openssl versions and may trigger API incompatibility
> issues that might result in runtime problems, so that users are warned.
>
> Willy
>

Re: cygwin compilation error

[Willy Tarreau]

On Wed, May 08, 2019 at 02:06:31PM +0500,  ??? wrote:
> > Ilya, could you please instead change the test like this and test again :
> >
> > -#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L)
> > +#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x1010100fL)
> >
> 
> LibreSSL defines is
> 
> #define OPENSSL_VERSION_NUMBER0x2000L
> 
> it is bigger then any released OpenSSL (yet, for openssl master it is 3.0.0)

So this behaviour from them make them complete bastards and will
constantly break each and every program trying to build with it :-(

This stupidity really makes me want to completely remove support for
libressl.

I don't know when they forked nor what is the latest version they are
*really* compatible with, but what we should probably do is to change
their marketing version to a real version in the compat.h file to do
something like this :

#if defined(LIBRESSL_VERSION_NUMBER)
#undef OPENSSL_VERSION_NUMBER
#define OPENSSL_VERSION_NUMBER 0x10something
#endif

This way we won't have to guard ourselves against these lies each and
every time we add something to deal with some openssl-specific issues
or features. Ideas welcome, of course. If for any reason we can't do
something like the above, we should at least add a big fat warning when
building with it to explicitly mention that it uses fake version numbers
overlapping with openssl versions and may trigger API incompatibility
issues that might result in runtime problems, so that users are warned.

Willy

Re: cygwin compilation error

[Илья Шипицин]

ср, 8 мая 2019 г. в 13:55, Willy Tarreau :

> On Wed, May 08, 2019 at 01:13:56PM +0500,  ??? wrote:
> > > libressl ? My understanding of this thing is that this problem is not
> > > easy to detect by accident and causes a mess for people who reload
> often.
> > > If libressl is affected by this we probably need to find a different
> > > fix. And if it's not affected, at least the tested version(s) must be
> > > mentioned in the commit message so that we can reconsider or refine
> this
> > > choice later if/when the problem appears with a subsequent version.
> > > CCing William and Emeric who worked on addressing this issue for
> OpenSSL.
> > >
> >
> > I planned to have a look at it actually. The idea is to write some reg
> test
> > which will reload and watch for open FDs.
> > not sure whether it is easy or not
>
> But before writing reg tests, it's important not to revert part of a patch
> without knowing if it brings the issue back. Otherwise you end up with a
> patch merged into a branch, making users believe their bug is fixed since
> the patch is there, while in fact it was later silently reverted as a
> "build fix".
>
> > the idea behind quick patch is "if you use LibreSSL you are on your own
> and
> > you have been warned"
> > (yes, we did our best to make it work with LibreSSL, but it is still a
> > niche solution, not very well tested)
>
> Some of the users here do rely on it. However, seeing that you had to
> turn off this test makes me think that LibreSSL pretends to be openssl
> 1.1.1 but is not compatible with it. I suspect that instead the OpenSSL
> test version is wrong in the original patch. It seems to be testing for
> 1.1.1-dev instead of testing for 1.1.1-release. So probably that this
> RAND_* function appears late in the development process and that libressl
> only complies with an early 1.1.1-dev version.
>
> Surprisingly I'm seeing that *all* of our tests for 1.1.1 are wrong. I
> suspect that one was either wrong or deliberate initially and that it
> got copy-pasted everywhere :-(
>
> Ilya, could you please instead change the test like this and test again :
>
> -#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L)
> +#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x1010100fL)
>

LibreSSL defines is

#define OPENSSL_VERSION_NUMBER0x2000L

it is bigger then any released OpenSSL (yet, for openssl master it is 3.0.0)


>
> Thanks,
> Willy
>

Re: cygwin compilation error

[Willy Tarreau]

On Wed, May 08, 2019 at 01:13:56PM +0500,  ??? wrote:
> > libressl ? My understanding of this thing is that this problem is not
> > easy to detect by accident and causes a mess for people who reload often.
> > If libressl is affected by this we probably need to find a different
> > fix. And if it's not affected, at least the tested version(s) must be
> > mentioned in the commit message so that we can reconsider or refine this
> > choice later if/when the problem appears with a subsequent version.
> > CCing William and Emeric who worked on addressing this issue for OpenSSL.
> >
> 
> I planned to have a look at it actually. The idea is to write some reg test
> which will reload and watch for open FDs.
> not sure whether it is easy or not

But before writing reg tests, it's important not to revert part of a patch
without knowing if it brings the issue back. Otherwise you end up with a
patch merged into a branch, making users believe their bug is fixed since
the patch is there, while in fact it was later silently reverted as a
"build fix".

> the idea behind quick patch is "if you use LibreSSL you are on your own and
> you have been warned"
> (yes, we did our best to make it work with LibreSSL, but it is still a
> niche solution, not very well tested)

Some of the users here do rely on it. However, seeing that you had to
turn off this test makes me think that LibreSSL pretends to be openssl
1.1.1 but is not compatible with it. I suspect that instead the OpenSSL
test version is wrong in the original patch. It seems to be testing for
1.1.1-dev instead of testing for 1.1.1-release. So probably that this
RAND_* function appears late in the development process and that libressl
only complies with an early 1.1.1-dev version.

Surprisingly I'm seeing that *all* of our tests for 1.1.1 are wrong. I
suspect that one was either wrong or deliberate initially and that it
got copy-pasted everywhere :-(

Ilya, could you please instead change the test like this and test again :

-#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L)
+#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x1010100fL)

Thanks,
Willy

Re: cygwin compilation error

[Илья Шипицин]

Frederic, can you help with some "haproxy reg test getting started" doc ?


ср, 8 мая 2019 г. в 13:13, Илья Шипицин :

>
>
> ср, 8 мая 2019 г. в 13:03, Willy Tarreau :
>
>> Hi Ilya,
>>
>> On Wed, May 08, 2019 at 11:34:57AM +0500,  ??? wrote:
>> > From ad9961e92c692430272c9088a49759c889dac6f1 Mon Sep 17 00:00:00 2001
>> > From: Ilya Shipitsin 
>> > Date: Wed, 8 May 2019 11:32:02 +0500
>> > Subject: [PATCH] BUILD: do not use "RAND_keep_random_devices_open" when
>> >  building against LibreSSL
>> >
>> > ---
>> >  src/haproxy.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/src/haproxy.c b/src/haproxy.c
>> > index 4c371254..c8a8aaf0 100644
>> > --- a/src/haproxy.c
>> > +++ b/src/haproxy.c
>> > @@ -590,7 +590,7 @@ void mworker_reload()
>> >   ptdf->fct();
>> >   if (fdtab)
>> >   deinit_pollers();
>> > -#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L)
>> > +#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L) &&
>> !defined LIBRESSL_VERSION_NUMBER)
>>
>> A parenthesis is missing here, please be careful to always try to build
>> the code with submitted patches.
>>
>> >   if (global.ssl_used_frontend || global.ssl_used_backend)
>> >   /* close random device FDs */
>> >   RAND_keep_random_devices_open(0);
>>
>> Did you verify if this has an impact on FD leaks upon reloads when using
>>
>
> I did a mess two times :)
>
>
>
>> libressl ? My understanding of this thing is that this problem is not
>> easy to detect by accident and causes a mess for people who reload often.
>> If libressl is affected by this we probably need to find a different
>> fix. And if it's not affected, at least the tested version(s) must be
>> mentioned in the commit message so that we can reconsider or refine this
>> choice later if/when the problem appears with a subsequent version.
>> CCing William and Emeric who worked on addressing this issue for OpenSSL.
>>
>
> I planned to have a look at it actually. The idea is to write some reg
> test which will reload and watch for open FDs.
> not sure whether it is easy or not
>
>
> the idea behind quick patch is "if you use LibreSSL you are on your own
> and you have been warned"
> (yes, we did our best to make it work with LibreSSL, but it is still a
> niche solution, not very well tested)
>
>
>> Thanks,
>> Willy
>>
>

Re: cygwin compilation error

[Илья Шипицин]

ср, 8 мая 2019 г. в 13:03, Willy Tarreau :

> Hi Ilya,
>
> On Wed, May 08, 2019 at 11:34:57AM +0500,  ??? wrote:
> > From ad9961e92c692430272c9088a49759c889dac6f1 Mon Sep 17 00:00:00 2001
> > From: Ilya Shipitsin 
> > Date: Wed, 8 May 2019 11:32:02 +0500
> > Subject: [PATCH] BUILD: do not use "RAND_keep_random_devices_open" when
> >  building against LibreSSL
> >
> > ---
> >  src/haproxy.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/haproxy.c b/src/haproxy.c
> > index 4c371254..c8a8aaf0 100644
> > --- a/src/haproxy.c
> > +++ b/src/haproxy.c
> > @@ -590,7 +590,7 @@ void mworker_reload()
> >   ptdf->fct();
> >   if (fdtab)
> >   deinit_pollers();
> > -#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L)
> > +#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L) &&
> !defined LIBRESSL_VERSION_NUMBER)
>
> A parenthesis is missing here, please be careful to always try to build
> the code with submitted patches.
>
> >   if (global.ssl_used_frontend || global.ssl_used_backend)
> >   /* close random device FDs */
> >   RAND_keep_random_devices_open(0);
>
> Did you verify if this has an impact on FD leaks upon reloads when using
>

I did a mess two times :)



> libressl ? My understanding of this thing is that this problem is not
> easy to detect by accident and causes a mess for people who reload often.
> If libressl is affected by this we probably need to find a different
> fix. And if it's not affected, at least the tested version(s) must be
> mentioned in the commit message so that we can reconsider or refine this
> choice later if/when the problem appears with a subsequent version.
> CCing William and Emeric who worked on addressing this issue for OpenSSL.
>

I planned to have a look at it actually. The idea is to write some reg test
which will reload and watch for open FDs.
not sure whether it is easy or not


the idea behind quick patch is "if you use LibreSSL you are on your own and
you have been warned"
(yes, we did our best to make it work with LibreSSL, but it is still a
niche solution, not very well tested)


> Thanks,
> Willy
>

Re: cygwin compilation error

[Willy Tarreau]

Hi Ilya,

On Wed, May 08, 2019 at 11:34:57AM +0500,  ??? wrote:
> From ad9961e92c692430272c9088a49759c889dac6f1 Mon Sep 17 00:00:00 2001
> From: Ilya Shipitsin 
> Date: Wed, 8 May 2019 11:32:02 +0500
> Subject: [PATCH] BUILD: do not use "RAND_keep_random_devices_open" when
>  building against LibreSSL
> 
> ---
>  src/haproxy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/haproxy.c b/src/haproxy.c
> index 4c371254..c8a8aaf0 100644
> --- a/src/haproxy.c
> +++ b/src/haproxy.c
> @@ -590,7 +590,7 @@ void mworker_reload()
>   ptdf->fct();
>   if (fdtab)
>   deinit_pollers();
> -#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L)
> +#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L) && 
> !defined LIBRESSL_VERSION_NUMBER)

A parenthesis is missing here, please be careful to always try to build
the code with submitted patches.

>   if (global.ssl_used_frontend || global.ssl_used_backend)
>   /* close random device FDs */
>   RAND_keep_random_devices_open(0);

Did you verify if this has an impact on FD leaks upon reloads when using
libressl ? My understanding of this thing is that this problem is not
easy to detect by accident and causes a mess for people who reload often.
If libressl is affected by this we probably need to find a different
fix. And if it's not affected, at least the tested version(s) must be
mentioned in the commit message so that we can reconsider or refine this
choice later if/when the problem appears with a subsequent version.
CCing William and Emeric who worked on addressing this issue for OpenSSL.

Thanks,
Willy

Re: cygwin compilation error

[Илья Шипицин]

I messed up with commit message. One more try

ср, 8 мая 2019 г. в 11:33, Илья Шипицин :

> small fix
>
> ср, 8 мая 2019 г. в 11:12, Willy Tarreau :
>
>> On Wed, May 08, 2019 at 11:09:04AM +0500,  ??? wrote:
>> > ??, 8 ??? 2019 ?. ? 11:06, Willy Tarreau :
>> >
>> > > On Wed, May 08, 2019 at 10:59:20AM +0500,  ??? wrote:
>> > > > travis-ci supports windows builds.
>> > >
>> > > cool!
>> > >
>> >
>> > my current roadmap is
>> >
>> > 1) patch fixes SSL variants (already sent to list). without it we are
>> NOT
>> > building LibreSSL at all (i.e. we use default openssl-1.0.2 for all
>> builds)
>>
>> Pushed just now.
>>
>> > 2) BoringSSL
>> >
>> > 3) update gcc, clang, enable sanitizers
>> >
>> > 4) cygwin
>>
>> OK, sounds good.
>>
>> Thanks,
>> Willy
>>
>
From ad9961e92c692430272c9088a49759c889dac6f1 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Wed, 8 May 2019 11:32:02 +0500
Subject: [PATCH] BUILD: do not use "RAND_keep_random_devices_open" when
 building against LibreSSL

---
 src/haproxy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 4c371254..c8a8aaf0 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -590,7 +590,7 @@ void mworker_reload()
 		ptdf->fct();
 	if (fdtab)
 		deinit_pollers();
-#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L)
+#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L) && !defined LIBRESSL_VERSION_NUMBER)
 	if (global.ssl_used_frontend || global.ssl_used_backend)
 		/* close random device FDs */
 		RAND_keep_random_devices_open(0);
-- 
2.20.1

Re: cygwin compilation error

[Илья Шипицин]

small fix

ср, 8 мая 2019 г. в 11:12, Willy Tarreau :

> On Wed, May 08, 2019 at 11:09:04AM +0500,  ??? wrote:
> > ??, 8 ??? 2019 ?. ? 11:06, Willy Tarreau :
> >
> > > On Wed, May 08, 2019 at 10:59:20AM +0500,  ??? wrote:
> > > > travis-ci supports windows builds.
> > >
> > > cool!
> > >
> >
> > my current roadmap is
> >
> > 1) patch fixes SSL variants (already sent to list). without it we are NOT
> > building LibreSSL at all (i.e. we use default openssl-1.0.2 for all
> builds)
>
> Pushed just now.
>
> > 2) BoringSSL
> >
> > 3) update gcc, clang, enable sanitizers
> >
> > 4) cygwin
>
> OK, sounds good.
>
> Thanks,
> Willy
>
From ad9961e92c692430272c9088a49759c889dac6f1 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Wed, 8 May 2019 11:32:02 +0500
Subject: [PATCH] BUILD: do not use && !defined LIBRESSL_VERSION_NUMBER) when
 building against LibreSSL

---
 src/haproxy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 4c371254..c8a8aaf0 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -590,7 +590,7 @@ void mworker_reload()
 		ptdf->fct();
 	if (fdtab)
 		deinit_pollers();
-#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L)
+#if defined(USE_OPENSSL) && (OPENSSL_VERSION_NUMBER >= 0x10101000L) && !defined LIBRESSL_VERSION_NUMBER)
 	if (global.ssl_used_frontend || global.ssl_used_backend)
 		/* close random device FDs */
 		RAND_keep_random_devices_open(0);
-- 
2.20.1

Re: cygwin compilation error

[Willy Tarreau]

On Wed, May 08, 2019 at 11:09:04AM +0500,  ??? wrote:
> ??, 8 ??? 2019 ?. ? 11:06, Willy Tarreau :
> 
> > On Wed, May 08, 2019 at 10:59:20AM +0500,  ??? wrote:
> > > travis-ci supports windows builds.
> >
> > cool!
> >
> 
> my current roadmap is
> 
> 1) patch fixes SSL variants (already sent to list). without it we are NOT
> building LibreSSL at all (i.e. we use default openssl-1.0.2 for all builds)

Pushed just now.

> 2) BoringSSL
> 
> 3) update gcc, clang, enable sanitizers
> 
> 4) cygwin

OK, sounds good.

Thanks,
Willy

Re: cygwin compilation error

[Илья Шипицин]

ср, 8 мая 2019 г. в 11:06, Willy Tarreau :

> On Wed, May 08, 2019 at 10:59:20AM +0500,  ??? wrote:
> > travis-ci supports windows builds.
>
> cool!
>

my current roadmap is

1) patch fixes SSL variants (already sent to list). without it we are NOT
building LibreSSL at all (i.e. we use default openssl-1.0.2 for all builds)

2) BoringSSL

3) update gcc, clang, enable sanitizers

4) cygwin


>
> > I will add such build a bit later (after
> > we settle with current travis-ci fixes)
>
> ...and this cygwin build issue :-)
>
> Willy
>

Re: cygwin compilation error

[Willy Tarreau]

On Wed, May 08, 2019 at 10:59:20AM +0500,  ??? wrote:
> travis-ci supports windows builds.

cool!

> I will add such build a bit later (after
> we settle with current travis-ci fixes)

...and this cygwin build issue :-)

Willy

Re: cygwin compilation error

[Илья Шипицин]

travis-ci supports windows builds. I will add such build a bit later (after
we settle with current travis-ci fixes)

ср, 8 мая 2019 г. в 10:52, Willy Tarreau :

> Hi,
>
> On Mon, May 06, 2019 at 12:54:47PM +0300, Gil Bahat wrote:
> > Hi,
> >
> > is cygwin still supported anymore?
>
> Well, we never know :-)  I mean, we're always open to fixes to make it
> work as long as they don't impact other platforms.
>
> > the target seems to be present in the
> > Makefiles and I'd love to be able to use it. I'm running into what seems
> to
> > be a workable linker error:
> >
> > $ make TARGET=cygwin
> >   LD  haproxy
> > src/http_act.o:http_act.c:(.rdata+0x340): multiple definition of
> > `.weak.ist_uc.'
> > src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here
>
> Aie that's really bad, it means the linker doesn't support weak symbols :-(
> Weak symbols are very handy as they are able to be included and linked in
> only once if they are used, and not linked if unused. The info I'm finding
> on the net suggest that symbols must be resolved at link time, which is the
> case here. So maybe it's just a matter of definition.
>
> I can suggest a few things to try in include/common/ist.h :
>
>   - replace "__weak__" with "weak" just in case it's different there
> (I don't even know why I marked it "__weak__", probably just by
> mimetism with "__attribute__" and because it worked
>
>   - add "#pragma weak ist_lc" and "#pragma weak ist_uc" in ist.h,
> before the definitions
>
>   - add "extern const unsigned char ist_lc[256];" and
> "extern const unsigned char ist_uc[256];" before the definitions
>
> In case one of them is enough to work, we can merge them.
>
> Thanks,
> Willy
>
>

Re: cygwin compilation error

[Willy Tarreau]

Hi,

On Mon, May 06, 2019 at 12:54:47PM +0300, Gil Bahat wrote:
> Hi,
> 
> is cygwin still supported anymore?

Well, we never know :-)  I mean, we're always open to fixes to make it
work as long as they don't impact other platforms.

> the target seems to be present in the
> Makefiles and I'd love to be able to use it. I'm running into what seems to
> be a workable linker error:
> 
> $ make TARGET=cygwin
>   LD  haproxy
> src/http_act.o:http_act.c:(.rdata+0x340): multiple definition of
> `.weak.ist_uc.'
> src/ev_poll.o:ev_poll.c:(.rdata+0x20): first defined here

Aie that's really bad, it means the linker doesn't support weak symbols :-(
Weak symbols are very handy as they are able to be included and linked in
only once if they are used, and not linked if unused. The info I'm finding
on the net suggest that symbols must be resolved at link time, which is the
case here. So maybe it's just a matter of definition.

I can suggest a few things to try in include/common/ist.h :

  - replace "__weak__" with "weak" just in case it's different there
(I don't even know why I marked it "__weak__", probably just by
mimetism with "__attribute__" and because it worked

  - add "#pragma weak ist_lc" and "#pragma weak ist_uc" in ist.h,
before the definitions

  - add "extern const unsigned char ist_lc[256];" and
"extern const unsigned char ist_uc[256];" before the definitions

In case one of them is enough to work, we can merge them.

Thanks,
Willy