Re: [squid-dev] bizarre build behaviour from PoolingAllocator on OpenBSD/clang
On 8/16/21 10:44 AM, Alex Rousskov wrote: > On 8/16/21 7:29 AM, Stuart Henderson wrote: > >> -c .../src/log/access_log.cc -fPIC -DPIC -o .libs/access_log.o >> In file included from .../src/log/access_log.cc:12: >> In file included from .../src/AccessLogEntry.h:19: >> In file included from .../src/HttpHeader.h:13: >> In file included from .../src/base/LookupTable.h:15: > >> /usr/include/c++/v1/unordered_map:857:5: error: static_assert failed >> due to requirement 'is_same> long>, std::__1::pair>::value' "Invalid >> allocator::value_type" > >> static_assert((is_same> allocator_type::value_type>::value), >> ^ >> ~~~ > > Yes, that could be the smoking gun missing from the earlier error log, > thank you, Stuart! > > Francesco, can you reproduce the same false is_same<> result using a toy > example? You might not even need Squid-specific types. > > If you can reproduce it, is the result valid/expected or is that a clang > bug? BTW, since LookupTable.h was mentioned in the above error, I think it might be important to mention that the unordered_map declaration in that file (lookupTable_t) is probably buggy because it is missing the custom equality operator. I have recently discovered that bug but did not have the time to properly report or address it. BTW, LookupTable.h is unrelated to PoolingAllocator -- lookupTable_t does not pool (yet?). HTH, Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] bizarre build behaviour from PoolingAllocator on OpenBSD/clang
On 8/16/21 7:29 AM, Stuart Henderson wrote: > -c .../src/log/access_log.cc -fPIC -DPIC -o .libs/access_log.o > In file included from .../src/log/access_log.cc:12: > In file included from .../src/AccessLogEntry.h:19: > In file included from .../src/HttpHeader.h:13: > In file included from .../src/base/LookupTable.h:15: > /usr/include/c++/v1/unordered_map:857:5: error: static_assert failed > due to requirement 'is_same long>, std::__1::pair>::value' "Invalid > allocator::value_type" > static_assert((is_same allocator_type::value_type>::value), > ^ > ~~~ Yes, that could be the smoking gun missing from the earlier error log, thank you, Stuart! Francesco, can you reproduce the same false is_same<> result using a toy example? You might not even need Squid-specific types. If you can reproduce it, is the result valid/expected or is that a clang bug? Alex. ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
Re: [squid-dev] bizarre build behaviour from PoolingAllocator on OpenBSD/clang
On Mon, Aug 16, 2021 at 12:29 PM Stuart Henderson
wrote:
> On 2021-08-15, Alex Rousskov wrote:
> > On 8/15/21 2:51 PM, Francesco Chemolli wrote:
> >> Hi all,
> >> I'm looking into OpenBSD compatibility for trunk, and there's a
> >> strange behaviour at build time on OpenBSD (6.9) / clang (10.0.1)
> >>
> >> When building src/log/access.log.cc, build fails with these errors:
> >>
> >> -- begin quote ---
> >> static_assert((is_same >> allocator_type::value_type>::value),
> >> ^
> >> ~~~
> >
> > Are some compiler messages missing in the above quote? It feels like the
> > above line is not directly related to the lines below, but perhaps I am
> > misinterpreting the messy output.
> >
> >> I'm puzzled: I wouldn't expect this to be an OS-specific failure.
> >
> > We cannot be sure it is OS-specific, but STL implementation is full of
> > hacks and optimizations that may be OS- or environment-specific. It is
> > also possible that there is a conflict between GCC and clang
> > installation; we have seen those before and they manifest in weird ways.
> >
> > It is strange that the error below mentions "unordered_map" when it
> > should say "std::unordered_map" or similar.
> >
> > Are you building with clang standard library or GCC standard library (I
> > believe -stdlib controls that, but it is not my area of expertise)? If
> > you are building with GCC stdlib, perhaps try building with
> > clang-provided stdlib?
>
> Hi, OpenBSD port maintainer here (I admit to not knowing much C++ though!).
> On OpenBSD, on all archs where the base system compiler is clang,
> it's configured to use the clang standard library (libc++) by default,
>
Hi Stuart,
Pleased to meet you
> >> /usr/include/c++/v1/initializer_list:99:1: note: candidate template
>
> and these are the correct headers for libc++. (Post-6.9 gcc is no longer
> installed in the base OS on any of the "base is clang" archs, it is
> present in ports but used only very rarely).
>
> I just gave it a spin, after adding a missed inclusion of sys/socket.h
> for SOL_SOCKET in Tcp.cc I hit the same problem with access.log.cc,
> there is a clue on the immediately previous line, which I think is
> pointing at something to do with const vs non-const SBuf, is that enough
> of a clue?
>
sys/socket inclusion is in PR#885, queued for landing any time soon.
I had patched the previous line to
for (auto i : TheGlobalContextStorage.storage) {
letting the compiler do the heavy lifting of type detection; but then the
other issues remained.
I will try some more variations.
egcc (gcc 8.4.0) builds that file just fine, so it might really be
libstdc++ related.
It fails when trying to use libcppunit, I suppose due to the fact that the
system-supplied libcppunit is built with clang++
>
>
> [...]
> Making all in log
> Making all in DB
> Making all in file
> depbase=`echo access_log.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;
> /usr/bin/libtool --tag=CXX--mode=compile c++ -DHAVE_CONFIG_H
> -DDEFAULT_CONFIG_FILE=\"/etc/squid/squid.conf\"
> -DDEFAULT_SQUID_DATA_DIR=\"/usr/local/share/squid\"
> -DDEFAULT_SQUID_CONFIG_DIR=\"/etc/squid\"
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/include
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/lib
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src
> -I../../include -I/usr/local/include-I/usr/local/include
> -I/usr/local/include/libxml2 -I/usr/local/include -Werror -Wextra
> -Wno-unused-private-field -Wpointer-arith -Wwrite-strings -Wcomments
> -Wshadow -Wmissing-declarations -D_REENTRANT -I/usr/local/include/libxml2
> -I/usr/local/include -I/usr/local/include -I/usr/local/include
> -I/usr/local/include/p11-k
> it-1 -O2 -pipe -MT access_log.lo -MD -MP -MF $depbase.Tpo -c -o
> access_log.lo
> /usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src/log/access_log.cc
> && mv -f $depbase.Tpo $depbase.Plo
> c++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE="/etc/squid/squid.conf"
> -DDEFAULT_SQUID_DATA_DIR="/usr/local/share/squid"
> -DDEFAULT_SQUID_CONFIG_DIR="/etc/squid"
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/include
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/lib
> -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src
> -I../../include -I/usr/local/include -I/usr/local/include
> -I/usr/local/include/libxml2 -I/usr/local/include -Werror -Wextra
> -Wno-unused-private-field -Wpointer-arith -Wwrite-strings -Wcomments
> -Wshadow -Wmissing-declarations -D_REENTRANT -I/usr/local/include/libxml2
> -I/usr/local/include
Re: [squid-dev] bizarre build behaviour from PoolingAllocator on OpenBSD/clang
On 2021-08-15, Alex Rousskov wrote: > On 8/15/21 2:51 PM, Francesco Chemolli wrote: >> Hi all, >> I'm looking into OpenBSD compatibility for trunk, and there's a >> strange behaviour at build time on OpenBSD (6.9) / clang (10.0.1) >> >> When building src/log/access.log.cc, build fails with these errors: >> >> -- begin quote --- >> static_assert((is_same> allocator_type::value_type>::value), >> ^ >> ~~~ > > Are some compiler messages missing in the above quote? It feels like the > above line is not directly related to the lines below, but perhaps I am > misinterpreting the messy output. > >> I'm puzzled: I wouldn't expect this to be an OS-specific failure. > > We cannot be sure it is OS-specific, but STL implementation is full of > hacks and optimizations that may be OS- or environment-specific. It is > also possible that there is a conflict between GCC and clang > installation; we have seen those before and they manifest in weird ways. > > It is strange that the error below mentions "unordered_map" when it > should say "std::unordered_map" or similar. > > Are you building with clang standard library or GCC standard library (I > believe -stdlib controls that, but it is not my area of expertise)? If > you are building with GCC stdlib, perhaps try building with > clang-provided stdlib? Hi, OpenBSD port maintainer here (I admit to not knowing much C++ though!). On OpenBSD, on all archs where the base system compiler is clang, it's configured to use the clang standard library (libc++) by default, >> /usr/include/c++/v1/initializer_list:99:1: note: candidate template and these are the correct headers for libc++. (Post-6.9 gcc is no longer installed in the base OS on any of the "base is clang" archs, it is present in ports but used only very rarely). I just gave it a spin, after adding a missed inclusion of sys/socket.h for SOL_SOCKET in Tcp.cc I hit the same problem with access.log.cc, there is a clue on the immediately previous line, which I think is pointing at something to do with const vs non-const SBuf, is that enough of a clue? [...] Making all in log Making all in DB Making all in file depbase=`echo access_log.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; /usr/bin/libtool --tag=CXX--mode=compile c++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE=\"/etc/squid/squid.conf\" -DDEFAULT_SQUID_DATA_DIR=\"/usr/local/share/squid\" -DDEFAULT_SQUID_CONFIG_DIR=\"/etc/squid\" -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/include -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/lib -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src -I../../include -I/usr/local/include-I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -Werror -Wextra -Wno-unused-private-field -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Wmissing-declarations -D_REENTRANT -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include/p11-k it-1 -O2 -pipe -MT access_log.lo -MD -MP -MF $depbase.Tpo -c -o access_log.lo /usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src/log/access_log.cc && mv -f $depbase.Tpo $depbase.Plo c++ -DHAVE_CONFIG_H -DDEFAULT_CONFIG_FILE="/etc/squid/squid.conf" -DDEFAULT_SQUID_DATA_DIR="/usr/local/share/squid" -DDEFAULT_SQUID_CONFIG_DIR="/etc/squid" -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/include -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/lib -I/usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src -I../../include -I/usr/local/include -I/usr/local/include -I/usr/local/include/libxml2 -I/usr/local/include -Werror -Wextra -Wno-unused-private-field -Wpointer-arith -Wwrite-strings -Wcomments -Wshadow -Wmissing-declarations -D_REENTRANT -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local/include/p11-kit-1 -O2 -pipe -MT access_log.lo -MD -MP -MF .deps/access_log.Tpo -c /usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a 889e0c37f327618e/src/log/access_log.cc -fPIC -DPIC -o .libs/access_log.o In file included from /usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src/log/access_log.cc:12: In file included from /usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src/AccessLogEntry.h:19: In file included from /usr/obj/ports/squid-5.1pl20210816/squid-742d042ea820b4ecac2a651a889e0c37f327618e/src/HttpHeader.h:13: In file included from
Re: [squid-dev] bizarre build behaviour from PoolingAllocator on OpenBSD/clang
On 8/15/21 2:51 PM, Francesco Chemolli wrote: > Hi all, > I'm looking into OpenBSD compatibility for trunk, and there's a > strange behaviour at build time on OpenBSD (6.9) / clang (10.0.1) > > When building src/log/access.log.cc, build fails with these errors: > > -- begin quote --- > static_assert((is_same allocator_type::value_type>::value), > ^ > ~~~ Are some compiler messages missing in the above quote? It feels like the above line is not directly related to the lines below, but perhaps I am misinterpreting the messy output. > I'm puzzled: I wouldn't expect this to be an OS-specific failure. We cannot be sure it is OS-specific, but STL implementation is full of hacks and optimizations that may be OS- or environment-specific. It is also possible that there is a conflict between GCC and clang installation; we have seen those before and they manifest in weird ways. It is strange that the error below mentions "unordered_map" when it should say "std::unordered_map" or similar. Are you building with clang standard library or GCC standard library (I believe -stdlib controls that, but it is not my area of expertise)? If you are building with GCC stdlib, perhaps try building with clang-provided stdlib? I wish I could be more helpful, Alex. > access_log.cc:66:26: note: in instantiation of template class > 'std::__1::unordered_map std::__1::hash, std::__1::equal_to, > PoolingAllocator > >' > requested here > static HeaderValueCounts TheViaCounts; > ^ > access_log.cc:460:25: error: type 'HeaderValueCounts' (aka > 'unordered_map, equal_to, > PoolingAllocator > >') does not provide > a subscript operator > ++TheForwardedCounts[key]; > ~~^~~~ > access_log.cc:467:24: error: invalid range expression of type 'const > std::__1::unordered_map std::__1::hash, std::__1::equal_to, > PoolingAllocator > >'; no > viable 'begin' function available > for (const auto : counts) >^ ~~ > /usr/include/c++/v1/initializer_list:99:1: note: candidate template > ignored: could not match 'initializer_list' against 'unordered_map' > begin(initializer_list<_Ep> __il) _NOEXCEPT > ^ > /usr/include/c++/v1/iterator:1753:1: note: candidate template ignored: > could not match '_Tp [_Np]' against 'const > std::__1::unordered_map std::__1::hash, std::__1::equal_to, > PoolingAllocator > >' > begin(_Tp (&__array)[_Np]) > ^ > /usr/include/c++/v1/iterator:1771:1: note: candidate template ignored: > substitution failure [with _Cp = const std::__1::unordered_map unsigned long long, std::__1::hash, std::__1::equal_to, > PoolingAllocator > >]: no > member named 'begin' in 'std::__1::unordered_map long, std::__1::hash, std::__1::equal_to, > PoolingAllocator > >' > begin(_Cp& __c) -> decltype(__c.begin()) > ^ ~ > /usr/include/c++/v1/iterator:1779:1: note: candidate template ignored: > substitution failure [with _Cp = std::__1::unordered_map unsigned long long, std::__1::hash, std::__1::equal_to, > PoolingAllocator > >]: no > member named 'begin' in 'std::__1::unordered_map long, std::__1::hash, std::__1::equal_to, > PoolingAllocator > >' > begin(const _Cp& __c) -> decltype(__c.begin()) > ^ ~ > access_log.cc:489:24: error: no member named 'clear' in > 'std::__1::unordered_map std::__1::hash, std::__1::equal_to, > PoolingAllocator > >' > TheForwardedCounts.clear(); > ~~ ^ > -- end quote --- > > But then, removing the reference to PoolingAllocator in the definition > of HeaderValueCounts, everything works. > """ > using HeaderValueCounts = std::unordered_map std::hash, std::equal_to >; > """ ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
[squid-dev] bizarre build behaviour from PoolingAllocator on OpenBSD/clang
Hi all, I'm looking into OpenBSD compatibility for trunk, and there's a strange behaviour at build time on OpenBSD (6.9) / clang (10.0.1) When building src/log/access.log.cc, build fails with these errors: -- begin quote --- static_assert((is_same::value), ^ ~~~ access_log.cc:66:26: note: in instantiation of template class 'std::__1::unordered_map, std::__1::equal_to, PoolingAllocator > >' requested here static HeaderValueCounts TheViaCounts; ^ access_log.cc:460:25: error: type 'HeaderValueCounts' (aka 'unordered_map, equal_to, PoolingAllocator > >') does not provide a subscript operator ++TheForwardedCounts[key]; ~~^~~~ access_log.cc:467:24: error: invalid range expression of type 'const std::__1::unordered_map, std::__1::equal_to, PoolingAllocator > >'; no viable 'begin' function available for (const auto : counts) ^ ~~ /usr/include/c++/v1/initializer_list:99:1: note: candidate template ignored: could not match 'initializer_list' against 'unordered_map' begin(initializer_list<_Ep> __il) _NOEXCEPT ^ /usr/include/c++/v1/iterator:1753:1: note: candidate template ignored: could not match '_Tp [_Np]' against 'const std::__1::unordered_map, std::__1::equal_to, PoolingAllocator > >' begin(_Tp (&__array)[_Np]) ^ /usr/include/c++/v1/iterator:1771:1: note: candidate template ignored: substitution failure [with _Cp = const std::__1::unordered_map, std::__1::equal_to, PoolingAllocator > >]: no member named 'begin' in 'std::__1::unordered_map, std::__1::equal_to, PoolingAllocator > >' begin(_Cp& __c) -> decltype(__c.begin()) ^ ~ /usr/include/c++/v1/iterator:1779:1: note: candidate template ignored: substitution failure [with _Cp = std::__1::unordered_map, std::__1::equal_to, PoolingAllocator > >]: no member named 'begin' in 'std::__1::unordered_map, std::__1::equal_to, PoolingAllocator > >' begin(const _Cp& __c) -> decltype(__c.begin()) ^ ~ access_log.cc:489:24: error: no member named 'clear' in 'std::__1::unordered_map, std::__1::equal_to, PoolingAllocator > >' TheForwardedCounts.clear(); ~~ ^ -- end quote --- But then, removing the reference to PoolingAllocator in the definition of HeaderValueCounts, everything works. """ using HeaderValueCounts = std::unordered_map, std::equal_to >; """ I'm puzzled: I wouldn't expect this to be an OS-specific failure. Any clue? -- Francesco ___ squid-dev mailing list squid-dev@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-dev
