public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: "Martin Liška" <mliska@suse.cz>
Cc: elfutils-devel@sourceware.org
Subject: Re: ☠ Buildbot (GNU Toolchain): elfutils-try-debian-armhf - failed compile (failure) (users/marxin/try-zstd-support-v2)
Date: Wed, 21 Dec 2022 15:42:18 +0100	[thread overview]
Message-ID: <20e14ca61f27119efca8e1e38292d82ac3048ec8.camel@klomp.org> (raw)
In-Reply-To: <3bfe6caf-c08e-583e-a98c-4acdb47530f9@suse.cz>

Hi Martin,

On Wed, 2022-12-21 at 15:20 +0100, Martin Liška wrote:
> On 12/21/22 12:15, builder@sourceware.org wrote:
> > A failed build has been detected on builder elfutils-try-debian-
> > armhf while building elfutils.
> > 
> > Full details are available at:
> >     https://builder.sourceware.org/buildbot/#builders/201/builds/47
> > 
> > Build state: failed compile (failure)
> > Revision: 1b845fdf4ca4d5367969cc5b33cbfa60338cf51b
> > Worker: debian-armhf
> > Build Reason: (unknown)
> > Blamelist: Martin Liska <mliska@suse.cz>
> > 
> > Steps:
> > 
> > - 0: worker_preparation ( success )
> > 
> > - 1: set package name ( success )
> > 
> > - 2: git checkout ( success )
> >     Logs:
> >         - stdio: 
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/2/logs/stdio
> > 
> > - 3: autoreconf ( success )
> >     Logs:
> >         - stdio: 
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/3/logs/stdio
> > 
> > - 4: configure ( success )
> >     Logs:
> >         - stdio: 
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/4/logs/stdio
> > 
> > - 5: get version ( success )
> >     Logs:
> >         - stdio: 
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/5/logs/stdio
> >         - property changes: 
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/5/logs/property_changes
> > 
> > - 6: make ( failure )
> >     Logs:
> >         - stdio: 
> > https://builder.sourceware.org/buildbot/#builders/201/builds/47/steps/6/logs/stdio
> > 
> 
> Mark, do you know what can be wrong about the configure test:
> 
> elf_compress.c: In function ‘__libelf_compress_zstd’:
> elf_compress.c:205:3: error: unknown type name ‘ZSTD_EndDirective’;
> did you mean ‘ZSTD_DDict’?
>    ZSTD_EndDirective mode = ZSTD_e_continue;
>    ^~~~~~~~~~~~~~~~~
>    ZSTD_DDict
> elf_compress.c:205:28: error: ‘ZSTD_e_continue’ undeclared (first use
> in this function)
>    ZSTD_EndDirective mode = ZSTD_e_continue;
>                             ^~~~~~~~~~~~~~~
> elf_compress.c:205:28: note: each undeclared identifier is reported
> only once for each function it appears in
> elf_compress.c:237:9: error: ‘ZSTD_e_end’ undeclared (first use in
> this function); did you mean ‘ZSTD_DDict’?
>   mode = ZSTD_e_end;
>          ^~~~~~~~~~
>          ZSTD_DDict
> elf_compress.c:243:17: error: implicit declaration of function
> ‘ZSTD_compressStream2’; did you mean ‘ZSTD_compressStream’? [-
> Werror=implicit-function-declaration]
>     size_t ret = ZSTD_compressStream2 (cctx, &ob, &ib, mode);
>                  ^~~~~~~~~~~~~~~~~~~~
>                  ZSTD_compressStream

Heay cool, the try buildbot worked.

The configure test seems to succeed (from the configure log):
checking for library containing ZSTD_compressStream2... -lzstd

Unfortunately buildbot itself doesn't show the config.log.
Trying to get that...

configure:6961: checking for library containing ZSTD_compressStream2
configure:6992: gcc -o conftest -D_FORTIFY_SOURCE=3 -g -O2
-fsanitize=undefined 
-fno-sanitize-recover -fsanitize=address -fno-sanitize-
recover   conftest.c -llz
ma -lbz2  >&5
/usr/bin/ld: /tmp/ccKZnuYA.o: in function `main':
/var/lib/buildbot/workers/wildebeest/elfutils-try-debian-
armhf/build/conftest.c:
30: undefined reference to `ZSTD_compressStream2'
collect2: error: ld returned 1 exit status
configure:6992: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "elfutils"
| #define PACKAGE_TARNAME "elfutils"
| #define PACKAGE_VERSION "0.188"
| #define PACKAGE_STRING "elfutils 0.188"
| #define PACKAGE_BUGREPORT "https://sourceware.org/bugzilla"
| #define PACKAGE_URL "http://elfutils.org/"
| #define PACKAGE "elfutils"
| #define VERSION "0.188"
| #define DEFAULT_AR_DETERMINISTIC false
| #define HAVE_VISIBILITY 1
| #define HAVE_STDATOMIC_H 1
| #define _FILE_OFFSET_BITS 64
| #define CHECK_UNDEFINED 1
| #define USE_ZLIB 1
| #define USE_BZLIB 1
| #define USE_LZMA 1
| /* end confdefs.h.  */
| 
| /* Override any GCC internal prototype to avoid an error.
|    Use char because int might match the return type of a GCC
|    builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char ZSTD_compressStream2 ();
| int
| main ()
| {
| return ZSTD_compressStream2 ();
|   ;
|   return 0;
| }
configure:6992: gcc -o conftest -D_FORTIFY_SOURCE=3 -g -O2
-fsanitize=undefined 
-fno-sanitize-recover -fsanitize=address -fno-sanitize-
recover   conftest.c -lzs
td  -llzma -lbz2  >&5
configure:6992: $? = 0
configure:7009: result: -lzstd

ehe? So it fails and then succeeds anyway?

Strangely the same happens for the other compression library checks...
lzma_auto_decoder and BZ2_bzdopen

I don't fully understand this. Oddly the same seems to happen locally
on my x86_64 box. So maybe the configure macros we have been using have
always been bad/broken?

Cheers,

Mark

  reply	other threads:[~2022-12-21 14:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20221221111547.74C4C385B50B@sourceware.org>
2022-12-21 14:20 ` Martin Liška
2022-12-21 14:42   ` Mark Wielaard [this message]
2022-12-21 14:54     ` Frank Ch. Eigler
2022-12-21 15:21     ` Mark Wielaard
2022-12-21 18:29       ` Martin Liška
2022-12-21 23:38         ` Mark Wielaard
2022-12-22  9:09           ` Martin Liška
2022-12-22 18:17             ` Mark Wielaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20e14ca61f27119efca8e1e38292d82ac3048ec8.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=elfutils-devel@sourceware.org \
    --cc=mliska@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).