Dear Alberto,

Hope this finds you well. Any quick/immediate ideas on what might be
behind this build failure? Note that this is on ARM architectures
rather than amd64 — I often misread and conflate them at speed. :) Oh,
and I can't reproduce this on amd64 locally, at least, so I don't think
it is, say, due to some *general* update to the GLIBC build toolchain.


Best wishes,

Chris


----- Original message -----
From: Sebastian Ramacher <sramacher@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
Date: Friday, 15 March 2024 6:50 PM

Source: libfiu
Version: 1.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramacher@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libfiu&arch=armhf&ver=1.2-2&stamp=1710292712&raw=0

cc -D_XOPEN_SOURCE=600 -fPIC -DFIU_ENABLE=1 -D_LARGEFILE64_SOURCE=1 -I. -I../../libfiu/ -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -
D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -D_GNU_SOURCE -c codegen.c -o codegen.o
/tmp/cc54dEva.s: Assembler messages:
/tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
/tmp/cchEoHpC.s: Assembler messages:
/tmp/cchEoHpC.s:474: Error: symbol `mmap64' is already defined
make[4]: *** [Makefile:67: modules/posix.mm.mod.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: *** [Makefile:67: modules/posix.custom.o] Error 1
/tmp/cct4HXD3.s: Assembler messages:
/tmp/cct4HXD3.s:1810: Error: symbol `pread64' is already defined /tmp/cct4HXD3.s:3995: Error: symbol `pwrite64' is already defined /tmp/cct4HXD3.s:5803: Error: symbol `truncate64' is already defined /tmp/cct4HXD3.s:6480: Error: symbol `ftruncate64' is already defined /tmp/ccInAMjZ.s: Assembler messages:
/tmp/ccInAMjZ.s:437: Error: symbol `fopen64' is already defined
make[4]: *** [Makefile:67: modules/posix.io.mod.o] Error 1 /tmp/ccInAMjZ.s:1099: Error: symbol `freopen64' is already defined /tmp/ccInAMjZ.s:3393: Error: symbol `tmpfile64' is already defined /tmp/ccInAMjZ.s:5973: Error: symbol `ftello64' is already defined /tmp/ccInAMjZ.s:7007: Error: symbol `fseeko64' is already defined /tmp/ccInAMjZ.s:7699: Error: symbol `fsetpos64' is already defined
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 18, 2024 at 12:29:40PM +0000, Chris Lamb wrote:

Dear Alberto,

Hi!

Hope this finds you well. Any quick/immediate ideas on what might be
behind this build failure? Note that this is on ARM architectures
rather than amd64 — I often misread and conflate them at speed. :) Oh,
and I can't reproduce this on amd64 locally, at least, so I don't think
it is, say, due to some *general* update to the GLIBC build toolchain.

Nothing obvious.

It's a bit strange because the "symbol X already defined" errors most
likely come from the assembler when building the individual files, not
from linking stage.

While it's impossible to be 100% sure because of the parallel build and
the lack of command-output correlation in the logs, everything points to
that being the case.

I'll try to get a debian install to boot for armhf, but it'll take me a
bit because it's not straightforward (to put it mildly :).

How urgent/important is this issue?

Thanks,
Alberto

----- Original message -----
From: Sebastian Ramacher <sramacher@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
Date: Friday, 15 March 2024 6:50 PM

Source: libfiu
Version: 1.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past) >X-Debbugs-Cc: sramacher@debian.org

https://buildd.debian.org/status/fetch.php?pkg=libfiu&arch=armhf&ver=1.2-2&stamp=1710292712&raw=0

cc -D_XOPEN_SOURCE=600 -fPIC -DFIU_ENABLE=1 -D_LARGEFILE64_SOURCE=1 -I. -I../../libfiu/ -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -

D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -D_GNU_SOURCE -c codegen.c -o codegen.o

/tmp/cc54dEva.s: Assembler messages:
/tmp/cc54dEva.s:726: Error: symbol `open64' is already defined >/tmp/cchEoHpC.s: Assembler messages:
/tmp/cchEoHpC.s:474: Error: symbol `mmap64' is already defined
make[4]: *** [Makefile:67: modules/posix.mm.mod.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: *** [Makefile:67: modules/posix.custom.o] Error 1
/tmp/cct4HXD3.s: Assembler messages:
/tmp/cct4HXD3.s:1810: Error: symbol `pread64' is already defined >/tmp/cct4HXD3.s:3995: Error: symbol `pwrite64' is already defined >/tmp/cct4HXD3.s:5803: Error: symbol `truncate64' is already defined >/tmp/cct4HXD3.s:6480: Error: symbol `ftruncate64' is already defined >/tmp/ccInAMjZ.s: Assembler messages:
/tmp/ccInAMjZ.s:437: Error: symbol `fopen64' is already defined
make[4]: *** [Makefile:67: modules/posix.io.mod.o] Error 1 >/tmp/ccInAMjZ.s:1099: Error: symbol `freopen64' is already defined >/tmp/ccInAMjZ.s:3393: Error: symbol `tmpfile64' is already defined >/tmp/ccInAMjZ.s:5973: Error: symbol `ftello64' is already defined >/tmp/ccInAMjZ.s:7007: Error: symbol `fseeko64' is already defined >/tmp/ccInAMjZ.s:7699: Error: symbol `fsetpos64' is already defined
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1

Alberto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Alberto Bertogli wrote:

If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.

Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer)
actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.

Hm, googling the actual error message a little, I think this might be
a bigger issue... or perhaps more accurately, at least one that has
potentially been also solved elsewhere:

* Same think in lightdm: <https://bugs.debian.org/1067561>

* Some kind of "_FILE_OFFSET_BITS"-related patch for v4l-utils
<https://www.spinics.net/lists/linux-media/msg230147.html>

etc.

Does this spark anything worth trying? :-)


Regards,

--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org 🍥 chris-lamb.co.uk
`-

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Mar 25, 2024 at 07:12:24PM +0000, Chris Lamb wrote:

Alberto Bertogli wrote:

If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.

Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer) >actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.

I totally understand the access part, that's very reasonable on Debian's
part.

But unfortunately, if I can't even run a local VM to try to reproduce
the problem, it's too limiting for me. Especially considering the kind
of issues libfiu often runs into, which tend to be a bit on the esoteric
side :)

Hm, googling the actual error message a little, I think this might be
a bigger issue... or perhaps more accurately, at least one that has >potentially been also solved elsewhere:

* Same think in lightdm: <https://bugs.debian.org/1067561>

* Some kind of "_FILE_OFFSET_BITS"-related patch for v4l-utils
<https://www.spinics.net/lists/linux-media/msg230147.html>

Thank you for looking at this!

I think they could be similar; in particular the second one.

Maybe there's something like `#define pread pread64` in the
architecture's headers that is triggering these errors?

Does this spark anything worth trying? :-)

Maybe seeing the preprocessor output and the actual (temporary) file
getting the complaints could be useful in figuring out what's going on.

That said, even if we find what the problem is, we may keep finding
other issues in the future. If I'm not able to have a VM for this
platform where I can try to reproduce problems, I'm not sure it's viable
to support the package on it :(

Thanks!
Alberto

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El 25/3/24 a las 20:12, Chris Lamb escribió:

Alberto Bertogli wrote:

If you know of a functional official image that I can use to try to
reproduce the problem, or recently-tested steps I can follow to get
a working qemu install, please let me know.

Alas, I can't actually be helpful here. There are no official images
as far as I know… and somewhat annoyingly I (ie. a Debian Developer) actually have access to some machines set aside for this purpose. I
call this "annoying" because I naturally can't then give you direct
SSH access transitively — but I can proxy ideas, of course.

Hi.

I can't offer ssh access either (for now), but I've checked and
this error may be reproduced easily on an arm64 machine using an
armel chroot.

Several cloud vendors (like GCP, AWS or Hetzner) offer arm64 machines,
billed hourly and relatively cheap.

Also (but only if your stomach allows it :-), Oracle Cloud has arm64 machines in
their Free Tier. In this case I think they only have Ubuntu and not Debian,
but this would be not matter if you are using a Debian chroot.

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)