Re: c32width gives incorrect return values in C locale

Hi, > Am 19.11.2023 um 00:55 schrieb Patrice Dumas : > On Sun, Nov 19, 2023 at 12:26:02AM +0100, Patrice Dumas wrote: >> On Sat, Nov 18, 2023 at 09:10:09PM +, Gavin Smith wrote: >>> On Wed, Nov 15, 2023 at 09:42:21AM +0100, Patrice Dumas wrote: On Wed, Nov 15, 2023 at 12:22:24AM -0800, Pa

Re: buildbot failure in OpenCSW Buildbot on ggrep-solaris10-i386

Hi Bruno, Am 10.08.2021 um 09:58 schrieb Bruno Haible : >> On Mon, Aug 9, 2021 at 9:54 PM wrote: >>> The Buildbot has detected a new failure on builder ggrep-solaris10-i386 >>> while building ggrep. Full details are available at: >>> >>> https://buildfarm.opencsw.org/buildbot/builders/ggrep-

Re: recursion limit of 1024 exceeded

Hi Paul, Am 12.12.2020 um 20:29 schrieb Paul Eggert : > On 12/12/20 4:13 AM, Dagobert Michelsen wrote: >> m4 should be current, meanwhile I tried to update autoconf to 2.70 with >> 3 unexpected failures and automake to 14 unexpected failures which I will >> report on the res

Re: recursion limit of 1024 exceeded

Hi Bruno, Am 11.12.2020 um 17:01 schrieb Bruno Haible : >> dam@experimental10x [global]:/home/dam/work/gnulib > PATH=/opt/csw/gnu:$PATH >> ./gnulib-tool --create-testdir --dir=./testdir --single-configure >> --without-privileged-tests > > On a glibc system, this command line works fine. It take

Re: recursion limit of 1024 exceeded

Hi Bruno, Am 12.12.2020 um 17:25 schrieb Bruno Haible : gm4:configure.ac:4574: recursion limit of 1024 exceeded, use -L to change it > > The maximum recursion limit of m4 depends how it was built. Mine has > > $ m4 --help|grep limit >-L, --nesting-limit=NUMBER change nesting li

recursion limit of 1024 exceeded

Hi, I am currently trying to bootstrap gnulib on Solaris 10 x86 and get a m4 error "recursion limit of 1024 exceeded“, the m4 version is 1.4.18 and should be the most recent one. It would be great if someone could have a look. Best regards — Dago dam@experimental10x [global]:/home/dam/work

Re: Build issues with gettext 0.20.2 and 0.21 on Solaris 10 i386 with 64 bit

Hi Bruno, Am 01.12.2020 um 23:13 schrieb Bruno Haible : >> Nope, neither —host nor —cache-file, but what differs is that I pass -m64 in >> CFLAGS >> and not as part of CC. > > I see. > > I have submitted a patch to improve the Autoconf documentation on this topic: >

Re: Build issues with gettext 0.20.2 and 0.21 on Solaris 10 i386 with 64 bit

Hi Bruno, Am 01.12.2020 um 20:46 schrieb Bruno Haible : > But the $host_cpu value from the canonical triplet $host allows to do so. This is the triplet I get for my 64 bit build: checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 These are the fla

Re: Build issues with gettext 0.20.2 and 0.21 on Solaris 10 i386 with 64 bit

Hi Bruno, Am 22.11.2020 um 12:22 schrieb Dagobert Michelsen : > Am 17.11.2020 um 22:55 schrieb Bruno Haible : >>> I am currently trying to compile the most recent gettext on Solaris 10 and >>> found an issue. >>> The error shows on Solaris 10 i386 64 bit only, spar

Re: Build issues with gettext 0.20.2 and 0.21 on Solaris 10 i386 with 64 bit

Hi Bruno, Am 17.11.2020 um 22:55 schrieb Bruno Haible : >> I am currently trying to compile the most recent gettext on Solaris 10 and >> found an issue. >> The error shows on Solaris 10 i386 64 bit only, sparc and i386 32 bit are >> not affected: >> >> gmake[4]: Entering directory >> '/home/da

Re: Failed test "test-fopen-gnu" on Solaris 10

Hi Bruno, Am 16.11.2020 um 16:31 schrieb Bruno Haible : >> I am currently trying to build gettext 0.21 on Solaris 10 and encountered a >> failed test >> in gnulib: >> >> FAIL: test-fopen-gnu >> >> >> test-fopen-gnu.c:59: assertion 'f' failed >> FAIL test-fopen-gnu (exit sta

Failed test "test-fopen-gnu" on Solaris 10

Hi, I am currently trying to build gettext 0.21 on Solaris 10 and encountered a failed test in gnulib: FAIL: test-fopen-gnu test-fopen-gnu.c:59: assertion 'f' failed FAIL test-fopen-gnu (exit status: 134) Essentially this is failing: /* Create the file and check the 'e'

Re: CI/CD testing of gnulib?

Hi Bruno, Am 11.11.2020 um 17:21 schrieb Bruno Haible : > * Some platforms are not covered by CI testing platforms (e.g. AIX, Solaris, >Minix, but also Alpine Linux). […] > I occasionally do testing of all of gnulib or, more frequently, the POSIX > related part of gnulib. But it's really occa

Re: release process analysis

Hi Paul, Am 29.09.2020 um 22:56 schrieb Paul Eggert : > On 9/29/20 12:00 AM, Dagobert Michelsen wrote: >> This is not correct: there is continous integration on Solaris >> for quite some time now > > Yes, and I used that with this patch. Unfortunately the failure mod

Re: release process analysis

Hi Bruno, Am 29.09.2020 um 04:28 schrieb Bruno Haible : >- we don't have continuous integration on Solaris, This is not correct: there is continous integration on Solaris for quite some time now and status changes are reported automatically to grep-de...@gnu.org as well: https://buildfarm.o

Re: nl_langinfo-mt failure on Solaris 10 x86

Hi Bruno, Am 03.01.2020 um 23:28 schrieb Bruno Haible : >> I have one failing test on Solaris 10 x86: >> >> FAIL: test-nl_langinfo-mt >> = >> >> thread5 disturbed by threadN! >> FAIL test-nl_langinfo-mt (exit status: 134) >> >> >> This looks like a new failure to me. >

Re: Space separator missing in gnulib when building wget2

Hi Tim, hi Bruno, Am 30.11.2019 um 16:28 schrieb Tim Rühsen : > On 30.11.19 15:15, Bruno Haible wrote: >>> There is one LF at the end of the diff file (taken from the email I >>> received via mailing list, also cross-checked with bug-gnulib archive). >> >> Indeed, the one in bug-gnulib archive an

Re: Space separator missing in gnulib when building wget2

Hi Tim, Am 29.11.2019 um 10:16 schrieb Tim Rühsen : > But first let's get the algorithm straight. > In modules/getaddrinfo (and some other modules) are 2 'Link' libraries > given: > > Link: > $(GETADDRINFO_LIB) > $(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise > > So "libgnu_la_LDFL

Space separator missing in gnulib when building wget2

Hi, building of wget2 fails on Solaris 10 x86 with the error gmake[2]: Entering directory '/home/dam/work/wget2/libwget' /bin/bash ../libtool --tag=CC --mode=link gcc -DBUILDING_LIBWGET -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include -I/opt/csw/include

Re: Error compiling bison 3.4.2 on Solaris

Hi Paul, Am 17.10.2019 um 21:49 schrieb Paul Eggert : > I built and and ran the Bison tests with Bison HEAD on Solaris 10 sparc with > Studio 12.3 (which supports C89 and C++03 by default, if I'm not mistaken) > and found one failure that was definitely a C++ compiler bug, another one > where I

Re: Error compiling bison 3.4.2 on Solaris

Hi Paul, Am 15.10.2019 um 22:04 schrieb Paul Eggert : > On 10/15/19 4:07 AM, Dagobert Michelsen wrote: >> It seems to be a compiler issue: >> Studio 12.6: works >> Studio 12.5: works >> Studio 12.4: works >> Studio 12.3: broken with the error above >> S

Re: Error compiling bison 3.4.2 on Solaris

Hi Paul, Am 15.10.2019 um 06:08 schrieb Paul Eggert : > On 10/14/19 1:32 AM, Dagobert Michelsen wrote: >> I guess nowadays int is always 64 bit > > No, it's 32 bits on that platform. > >> I am trying to compile the most recent bison 3.4.2 on Solaris 10 Sparc and &

Error compiling bison 3.4.2 on Solaris

Hi, I am trying to compile the most recent bison 3.4.2 on Solaris 10 Sparc and i386 with Sun Studio and get the error CC src/bison-state.o "./lib/inttypes.h", line 61: #error: "This file assumes that 'int' has exactly 32 bits. Please report your platform and compiler to ." cc: acomp fai

Re: [Grep-devel] buildbot failure in OpenCSW Buildbot on ggrep-solaris10-sparc

Hi Paul, Am 21.08.2017 um 02:08 schrieb Paul Eggert : > Dagobert Michelsen wrote: >> The error lies in #72 in your configure.ac > > Thanks for helping to debug it. configure.ac is itself OK; the problem is > that build-aux/git-version-gen is a shell script that uses the constr

Re: bug#16380: Failing tests on Solaris in 2.16

Hi, sorry for the early post, I should be reading the whole thread first. This fixed all open issues for me. Best regards — Dago Am 08.01.2014 um 06:49 schrieb Paul Eggert : > And Jim pointed out a bug in that patch, so I pushed the following > further patch into grep (with the init.sh part

Re: GNU gettext 0.18.3.1 fails with undefined _Bool on Solaris

Hi Paul, thanks for the quick answer! Am 11.11.2013 um 09:46 schrieb Paul Eggert : > I wouldn't worry about the ACL checks, as gettext doesn't rely on ACLs. The problem is if one test fails our package system will not install. As a workaround I can disable the testsuite as a whole but would pre

GNU gettext 0.18.3.1 fails with undefined _Bool on Solaris

Hi, I am trying to compile GNU gettext 0.18.3.1 on Solaris 10 Sparc with Sun Studio 12 and get the following error: > /bin/bash ../libtool --tag=CC --mode=compile /opt/SUNWspro/bin/cc > -DLOCALEDIR=\"/opt/csw/share/locale\" > -DBISON_LOCALEDIR=\"/opt/csw/share/locale\" > -DLOCALE_ALIAS_PAT

Re: [ANN] m4-1.4.17 released [stable]

Hi Erik, Am 23.09.2013 um 16:27 schrieb Paul Eggert : > Eric Blake wrote: >> On 09/22/2013 07:08 AM, Dagobert Michelsen wrote: >> >>>> >>>> The latest release is no longer compilable with Sun Studio 12.3 compiler >>>> as it >>>> a

Re: [platform-testers] new snapshot available: diffutils-3.2.37-f0b0

Hi Paul, Am 31.10.2012 um 17:31 schrieb Paul Eggert : > Thanks, but I'm afraid that's still not enough information. > I don't know which assertion has failed, or why. > > Perhaps you can single-step through the failed programs? > They shouldn't take long to run. It looks like that SIGABRT does n

Re: [platform-testers] new snapshot available: diffutils-3.2.37-f0b0

Hi Paul, Am 30.10.2012 um 19:32 schrieb Paul Eggert : > Unfortunately the stack traces that you sent do not provide enough > info for me to see what the problem is on Solaris 9 with test-raise > and with test-sigaction. Perhaps you can try again, compiling with > -g and without -O, and get more i

Re: [platform-testers] new snapshot available: diffutils-3.2.37-f0b0

Hi Jim, Am 30.10.2012 um 16:44 schrieb Jim Meyering : > Wow. I've just realized it's been more than a year > since the last diffutils release. So here's a snapshot > of the latest sources: > > diffutils snapshot: > http://meyering.net/diff/diffutils-ss.tar.xz 1.2 MB > http://meyering.ne

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc

Hi, Am 08.05.2012 um 23:17 schrieb Paul Eggert: > On 05/08/2012 01:05 PM, Niels Möller wrote: >> I think it should work fine to just get the gnutls release and apply >> Paul's patch to the file gnutls-3.0.9/gl/stdint.in.h before running the >> configure script. > > Yes, that's the idea. Thanks.

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc

Hi Niels, Am 08.05.2012 um 10:55 schrieb Niels Möller: > Paul Eggert writes: >> Thanks. This seems to be a win regardless of whether it >> fixes the nettle problems, > > Dago, can you test if it solves the SunOS-5.9 problem for you? I.e., > apply Paul's patch to gnutls/gnulib, then *unapply* th

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc

Hi Niels, Am 06.05.2012 um 07:02 schrieb Paul Eggert: > On 05/05/2012 12:19 PM, Niels Möller wrote: >> So code which uses the int_fast*_t types and relies on gnulib will get a >> slightly different ABI > > Generally speaking, it's unwise to use > the int_fast*_t types in a public header file. > T

Re: Problem with int types persists on nettle 2.4 and gnutls 3.0.19 on Solaris 9 Sparc

Hi Niels, (adding bug-gnulib@) Am 27.04.2012 um 17:24 schrieb Niels Möller: > Simon Josefsson writes: >> Yes. Understanding what the differences is, and which one is right, >> seems useful first though. If the problem is in gnulib, we can fix >> that and GnuTLS will have the new variant soon. >

Problem compiling latest gnulib on Solaris 9 i386 with Sun Studio

Hi, I just tried to build a static gnulib as described in http://www.gnu.org/software/gnulib/manual/html_node/POSIX-Substitutes-Library.html#POSIX-Substitutes-Library on Solaris 9 i386 with Sun Studio 12 and got the following error: source='openat.c' object='openat.o' libtool=no \ DEPDIR=.deps

Re: [Platform-testers] new snapshot available: grep-2.9.69-f91c

Hi Jim, Am 11.11.2011 um 14:42 schrieb Jim Meyering: > Thanks for investigating. > I've pushed the following fix to gnulib; > I'll update grep to use it before the release. Excellent! Please let me know if you have an updated tarball for me to try. Best regards -- Dago -- "You don't become

Re: Failed test on Solaris 8 Sparc

Hi Simon, Am 21.04.2010 um 08:36 schrieb Simon Josefsson: > Dagobert Michelsen writes: >> Am 31.03.2009 um 12:23 schrieb Simon Josefsson: >>> Dagobert Michelsen writes: >>>> I am getting a test failure on Solaris 8 Sparc w/Sun Studio 11: >>> >>

Re: Problem detecting libsigsegv on gawk 4.0.0 on Solaris 9 Sparc w/Sun Studio 12

Hi Bruno, Am 07.07.2011 um 19:40 schrieb Bruno Haible: > Dagobert Michelsen wrote: >> Maybe the test in awk.h is too strict and should be something like this? > > Do you mean that 'cc' on Solaris cannot be put into a mode where it > 1) Accepts C99 syntax (declarati

Re: Problem detecting libsigsegv on gawk 4.0.0 on Solaris 9 Sparc w/Sun Studio 12

before or at: * > "/usr/include/ucontext.h", line 52: syntax error before or at: * > cc: acomp failed for foo.c Maybe the test in awk.h is too strict and should be something like this? With this patch libsigsegv is properly detected and I get a clean compile and a passing testsui

Re: Problem detecting libsigsegv on gawk 4.0.0 on Solaris 9 Sparc w/Sun Studio 12

Hi, Am 02.07.2011 um 11:18 schrieb Dagobert Michelsen: > I am trying to compile gawk 4.0.0 on Solaris 9 Sparc with Sun Studio 12 and > noticed that the presence of libsigsegv is not properly detected: > >> configure:9825: checking for libsigsegv >> configure:9847: /o

Problem detecting libsigsegv on gawk 4.0.0 on Solaris 9 Sparc w/Sun Studio 12

Hi, I am trying to compile gawk 4.0.0 on Solaris 9 Sparc with Sun Studio 12 and noticed that the presence of libsigsegv is not properly detected: > configure:9825: checking for libsigsegv > configure:9847: /opt/SUNWspro/bin/cc -o conftest -xO3 -m32 -xarch=386 -Xc > -I/opt/csw/include -m32 -xarch

Re: Testsuite of libidn 1.20 fails in gnulib

Hi Simon, Am 05.03.2011 um 12:22 schrieb Simon Josefsson: > Thanks Dagobert for the report and Paul for debugging this. > > Paul Eggert writes: > >> That problem is occurring because libidn is using an old >> version of gnulib's m4/longlong.m4. This bug was fixed >> on 2007-11-12 in gnulib. T

Re: Testsuite of libidn 1.20 fails in gnulib

Hi Eric, Am 04.03.2011 um 21:30 schrieb Eric Blake: > On 03/04/2011 01:21 PM, Dagobert Michelsen wrote: >> Hi, >> >> I am trying to compile libidn 1.20 on Solaris 9 Sparc with Sun Studio 12 >> and I get a failing test in the gnulib-part (cc'ed bug-gnulib@ for thi

Testsuite of libidn 1.20 fails in gnulib

Hi, I am trying to compile libidn 1.20 on Solaris 9 Sparc with Sun Studio 12 and I get a failing test in the gnulib-part (cc'ed bug-gnulib@ for this): > DEPDIR=.deps depmode=none /bin/bash ../../build-aux/depcomp \ > /opt/SUNWspro/bin/cc -DHAVE_CONFIG_H -I. -I../.. -DIN_LIBIDN_GNULIB_TESTS=1 >

Re: [GNU Bison 2.4.2] testsuite: Failing tests of bison 2.4.2 on Solaris 8+9 w/Sun Studio 11+12

Hi Bruno, Am 26.04.2010 um 00:51 schrieb Bruno Haible: To summarize so far: - The problem arises in /opt/csw/include/getopt.h, which is non- standard on Solaris. Not a problem gnulib is to be blamed for. - It arises in C++ mode only. In C mode the header file works fine. As I understand it

Re: [GNU Bison 2.4.2] testsuite: Failing tests of bison 2.4.2 on Solaris 8+9 w/Sun Studio 11+12

Hi Joel, Am 23.04.2010 um 05:24 schrieb Joel E. Denny: > On Wed, 21 Apr 2010, Paolo Bonzini wrote: >> Having OpenCSW regenerate the libgnugetopt package with "gnulib-tool >> --create-testdir --dir=libgnugetopt getopt-gnu" and dropping support >> for the old package seems easiest, and does not requ

Re: Failed test on Solaris 8 Sparc

Hi Simon, Am 31.03.2009 um 12:23 schrieb Simon Josefsson: Dagobert Michelsen writes: I am getting a test failure on Solaris 8 Sparc w/Sun Studio 11: Hi! Thanks for the report. The problem is actually in a self-test from gnulib. Your GNU SASL library build should still be fine, if this

Re: [GNU Bison 2.4.2] testsuite: Failing tests of bison 2.4.2 on Solaris 8+9 w/Sun Studio 11+12

Hi Joel, Am 20.04.2010 um 06:46 schrieb Joel E. Denny: On Thu, 15 Apr 2010, Eric Blake wrote: On 04/15/2010 03:39 PM, Joel E. Denny wrote: % cat > tmp.cc #define __EXTENSIONS__ 1 #include #include % CC -I/opt/csw/include tmp.cc "/opt/csw/include/getopt.h", line 122: Error: Only one of a set