Link failure (CCLD pq) building versions 3.2.1/3.2.3 on 64-bit raspberry pi

[LemoUtan]

OS is Debian GNU/Linux 11 (bullseye) on 64bit raspberry pi 4b aarch64 GNU/Linux and I'm building GAP 4.11.1 thereupon. Everything gappy makes ok except for half a dozen outliers amongst the pkg inclusions, all of which are fixable except, sadly, anupq which fails to complete the build after its successful compilations.

This package makes fine on both a 32 bit raspberry pi under standard (i.e. not raspbian) ubuntu and also a 64 bit x86amd64 system (i.e. not even a raspberry pi). As a matter of possible interest I've tried making the most recent version (anupq 3.2.3) and exactly the same link fails turn up.

Something about raspberry pi 64bit is wonky, wrt certain declared variables, and I'm getting

  CCLD     pq
/usr/bin/ld: src/pq-CloseFile.o:/home/paul/gittage/gap-4.11.1/pkg/anupq-3.2.1/./include/pcp_vars.h:81:
    multiple definition of `y_address'; src/pq-AllocateSpace.o:/home/paul/gittage/gap-4.11.1/pkg/anupq-3.2.1/./include/pcp_vars.h:81: first defined here
/usr/bin/ld: src/pq-Extend_Auts.o:/home/paul/gittage/gap-4.11.1/pkg/anupq-3.2.1/./include/pcp_vars.h:81:
    multiple definition of `y_address'; src/pq-AllocateSpace.o:/home/paul/gittage/gap-4.11.1/pkg/anupq-3.2.1/./include/pcp_vars.h:81: first defined here

(a whole slew of over 100 similar messages about variables Group_library, Compact_Description, Compact_Order, Group_library_file, y_address ending with ...)

/usr/bin/ld: src/pq-main.o:/home/paul/gittage/gap-4.11.1/pkg/anupq-3.2.1/./include/global.h:17:
    multiple definition of `Group_library'; src/pq-GAP_link_via_file.o:/home/paul/gittage/gap-4.11.1/pkg/anupq-3.2.1/./include/global.h:17: first defined here
/usr/bin/ld: src/pq-main.o:/home/paul/gittage/gap-4.11.1/pkg/anupq-3.2.1/./include/pcp_vars.h:81:
    multiple definition of `y_address'; src/pq-AllocateSpace.o:/home/paul/gittage/gap-4.11.1/pkg/anupq-3.2.1/./include/pcp_vars.h:81: first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:1001: pq] Error 1

Doubtless something silly I've forgotten. Any ideas why this bunch would fail to link on a 64 bit raspi where they do on a 32 bit raspi or a 64 bit non-raspi?

[fingolfin]

How do you build it? Just plain ./configure && make ?

[LemoUtan]

Yup. Plain old. Works fine on the other two machines. Need a config.log?

[fingolfin]

Yes, please

[LemoUtan]

config.log

note possible distraction from grepping the above for 'fatal' which yields

gcc: fatal error: no input files
gcc: fatal error: no input files
conftest.c:11:10: fatal error: ac_nonexistent.h: No such file or directory
conftest.c:11:10: fatal error: ac_nonexistent.h: No such file or directory
conftest.c:62:10: fatal error: vfork.h: No such file or directory
conftest.c:29:10: fatal error: vfork.h: No such file or directory

but the exact same obtains for the config.log files from the other two successful builds. And thanks for your attention btw!

[fingolfin]

The messages about vfork.h etc. are normal and harmless.

By chance we have two Raspberry Pis set up in our research group, one with 32bit and one with 64bit.

I can reproduce the issue on the 32bit one, which runs Raspbian GNU/Linux 11 (bullseye) with gcc (Raspbian 10.2.1-6+rpi1) 10.2.1 20210110.

It works fine on the 64bit one, which runs Ubuntu 20.04.3 LTS (Focal Fossa) with gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0.

In your config log, it says that it uses gcc (Debian 10.2.1-6) 10.2.1 20210110.

Perhaps a compiler bug?

[fingolfin]

Could also be an issue with ld, of course.

On the working 64 bit system, ld --version reports GNU ld (GNU Binutils for Ubuntu) 2.34

On the broken 32 bit system it reports GNU ld (GNU Binutils for Raspbian) 2.35.2.

[LemoUtan]

compiler on my 32bit π (also a 20.04.3 focal fossa) is gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)

linkerwise my πs I have ld --version returning, respectively, working 32 bit : GNU ld (GNU Binutils for Ubuntu) 2.34 broken 64 bit : GNU ld (GNU Binutils for Debian) 2.35.2

I suppose the error messages coming from ld doesn't necessarily mean that gcc is blameless. Annoyingly I was hosting a 64-bit hirsute hippo until recently, but the new 'official 64 bit' OS for the pi came out, so I switched to it.

Rats. Looks like it's raspbian then. Probably to be expected (though its 32 bit builder's been out a while).

[ChrisJefferson]

51 happens to fix the multiple definition problem (I also found it in cygwin). I believe the code is broken by the C standard (it violates the one definition rule), but many linkers "helpfully" handle this case by merging the variables, particularly if they take the value 0.

[LemoUtan]

Thanks, everyone. Anupq 3.2.4 now successfully pkg'd into gap 4.11.1 on new 64 bit raspi OS.