Re: cygwin compilation error
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
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
>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
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
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
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
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 must be miss
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
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=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=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/hapro
RE: cygwin compilation error
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=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=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
poll.h seems to be present at cygwin-devel: https://cygwin.com/cgi-bin2/package-grep.cgi?grep=poll.h=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
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
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
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
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
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
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
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
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
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
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
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
