Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Hi,

On Sat, 2025-11-29 at 12:46 +0100, Rene Engelhard wrote:
> Am 29.11.25 um 12:33 schrieb John Paul Adrian Glaubitz:
> > That's great! Hope you can make this change as suggested.
> Built on stadler, just doing a verification build here on amd64. Will then 
> push if it works.
> > Once a new version of the
> > libreoffice package has been uploaded, I'll look into debugging possible 
> > testsuite
> > failures on sparc64.
> 
> The "minimal set" done currently at least passes on stadler (including the 
> test-rust_uno-example
> autopkgtest which I massaged to run against the locally-built LO inside the 
> Debian tree), a full
> make check would need a build with the attached patch (also running on 
> stadler right now).

OK, that doesn't sound too bad then. Thanks for testing and let me know if I 
can be of any help!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[Rene Engelhard]

Hi,

Am 29.11.25 um 12:33 schrieb John Paul Adrian Glaubitz:

That's great! Hope you can make this change as suggested.

Built on stadler, just doing a verification build here on amd64. Will then push 
if it works.

Once a new version of the
libreoffice package has been uploaded, I'll look into debugging possible 
testsuite
failures on sparc64.


The "minimal set" done currently at least passes on stadler (including the 
test-rust_uno-example autopkgtest which I massaged to run against the locally-built LO 
inside the Debian tree), a full make check would need a build with the attached patch 
(also running on stadler right now).

Regards,


Rene
diff --git a/control b/control
index 33ed78a28..d776f5444 100644
--- a/control
+++ b/control
@@ -26,7 +26,7 @@ Build-Depends: autoconf,
gperf,
java-common (>= 0.75) ,
javahelper [!armel !armhf !hppa !kfreebsd-amd64 !kfreebsd-i386 !mips64 !powerpcspe !ppc64el !s390x !sparc] ,
-   junit4 [amd64 arm64] ,
+   junit4 [amd64 arm64 sparc64] ,
libabw-dev (<< 0.2~),
libabw-dev (>= 0.1),
libarchive-zip-perl [!armel !armhf !hppa !kfreebsd-amd64 !kfreebsd-i386 !mips64 !powerpcspe !ppc64el !s390x !sparc] ,
@@ -171,48 +171,48 @@ Build-Depends: autoconf,
zip,
zlib1g-dev
 Build-Depends-Arch: afdko-bin [alpha amd64 arm64 armel armhf hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 loong64 m68k mips mipsel mips64 mips64el powerpc powerpcspe ppc64 ppc64el riscv64 s390x sparc sparc64],
-at-spi2-core [!alpha !armel !armhf !hppa !i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386 !loong64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sparc !sparc64] ,
+at-spi2-core [!alpha !armel !armhf !hppa !i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386 !loong64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sparc] ,
 clang [!alpha !hppa !ia64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !s390x !sparc !sparc64],
 coinor-libcoinmp-dev,
 coinor-libcoinutils-dev,
-culmus [amd64 arm64 i386 ppc64el riscv64 s390x] ,
-dbus-x11 [!alpha !armel !armhf !hppa !i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386 !loong64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sparc !sparc64] ,
+culmus [amd64 arm64 sparc64 i386 ppc64el riscv64 s390x] ,
+dbus-x11 [!alpha !armel !armhf !hppa !i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386 !loong64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sparc] ,
 dh-cargo [!alpha !hppa !ia64 !kfreebsd-amd64 !kfreebsd-i386 !m68k !mips !mipsel !mips64 !powerpc !powerpcspe !sparc],
 firebird-dev (<< 5.0~) [!m68k],
 firebird-dev (>= 4.0) [!m68k],
 firebird4.0-server-core [!m68k] ,
-fontconfig [amd64 arm64 i386 ppc64el riscv64 s390x] ,
-fonts-crosextra-caladea [amd64 arm64 i386 ppc64el riscv64 s390x] ,
-fonts-crosextra-carlito (>= 20230309) [amd64 arm64 i386 ppc64el riscv64 s390x] ,
-fonts-dejavu [amd64 arm64 i386 ppc64el riscv64 s390x] ,
-fonts-hosny-amiri (>= 1.000) [amd64 arm64 i386 ppc64el riscv64 s390x] ,
-fonts-liberation (>= 1:2) [amd64 arm64 i386 ppc64el riscv64 s390x] ,
-fonts-linuxlibertine [amd64 arm64 i386 ppc64el riscv64 s390x] ,
-fonts-noto-core [amd64 arm64 i386 ppc64el riscv64 s390x] ,
+fontconfig [amd64 arm64 sparc64 i386 ppc64el riscv64 s390x] ,
+fonts-crosextra-caladea [amd64 arm64 sparc64 i386 ppc64el riscv64 s390x] ,
+fonts-crosextra-carlito (>= 20230309) [amd64 arm64 sparc64 i386 ppc64el riscv64 s390x] ,
+fonts-dejavu [amd64 arm64 sparc64 i386 ppc64el riscv64 s390x] ,
+fonts-hosny-amiri (>= 1.000) [amd64 arm64 sparc64 i386 ppc64el riscv64 s390x] ,
+fonts-liberation (>= 1:2) [amd64 arm64 sparc64 i386 ppc64el riscv64 s390x] ,
+fonts-linuxlibertine [amd64 arm64 sparc64 i386 ppc64el riscv64 s390x] ,
+fonts-noto-core [amd64 arm64 sparc64 i386 ppc64el riscv64 s390x] ,
 fonts-opensymbol ,
-gdb [!alpha !armel !armhf !hppa !i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386 !loong64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !powerpcspe !ppc64 !ppc64el !riscv64 !s390x !sparc !sparc64] ,
-ghostscript [!alpha !armel !armhf !hppa !i386 !ia64 !kfreebsd-amd64 !kfreebsd-i386 !loong64 !m68k !mips !mipsel !mips64 !mips64el !powerpc !power

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Hi Rene,

On Sat, 2025-11-29 at 09:20 +0100, Rene Engelhard wrote:
> Am 28.11.25 12:02, schrieb John Paul Adrian Glaubitz:
> > 
> > The attached patch replaces "-fpic" with "-fPIC" in the lp-solve build 
> > script which
> > seems to be enough to fix this particular build issue on sparc64.
> 
> Can you please do some care in your "patches" so that one doesn't need to
> replicate anything in them which makes the patch moot in the first place?

I'm not familiar with the libreoffice as you are, so that patch was just a 
suggestion.

> Here even a new patch patching ccc is not needed at all. In this case
> external/lpsolve/lp_solve_5.5.patch already adds
> + pic=-fpic
> itself. Which is used.
> 
> So the correct patch is
> --- external/lpsolve/lp_solve_5.5.patch-old   2025-11-28 19:18:23.702374716 
> +0100
> +++ external/lpsolve/lp_solve_5.5.patch   2025-11-28 19:18:33.730426860 
> +0100
> @@ -28,7 +28,7 @@
>  + a=a
>  + soprefix=lib
>  + libs="-lm"
> -+ pic=-fpic
> ++ pic=-fPIC
>  + ldflags="-Wl,-Bsymbolic -Wl,-soname,liblpsolve55.$so"
>   fi

That's great! Hope you can make this change as suggested. Once a new version of 
the
libreoffice package has been uploaded, I'll look into debugging possible 
testsuite
failures on sparc64.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Hi Rene,

On Sat, 2025-11-29 at 09:19 +0100, Rene Engelhard wrote:
> Hi,
> 
> Am 28.11.25 02:44, schrieb John Paul Adrian Glaubitz:
> > On Fri, 2025-11-28 at 14:29 +0100, Rene Engelhard wrote:
> > > I wouldn't be so.sure. Everywhere where rust is enabled it builds. 
> > > See the OOO_RUST_ARCHS setting in rules (im git: OOO_RUST_UNO_ARCHS)
> > > See the experimental buildlogs. (Working is something else, see -powerpc).
> > > 
> > > If it didn't on sparc64 and the extension makefile assumes it's there 
> > > without
> > > a proper dependency (don't think it does, but..). 
> > > 
> > > In any case that would be an other bug :) We will see with beta1. Or you 
> > > try
> > > on sid if you report against sid...
> > 
> > It could be a result of me resuming the failed dpkg build manually after 
> > making
> > the two changes to pdfium and lp_solve.
> 
> Or "too much" parallelity. 48 on stadler seems to be too much, too, 4
> works :). Didn't test more.

OK, then this sounds like a bug that should be reported upstream.

Thanks for figuring out what's wrong!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[Rene Engelhard]

Hi,

Am 28.11.25 12:02, schrieb John Paul Adrian Glaubitz:
> On Fri, 2025-11-28 at 09:46 +0100, John Paul Adrian Glaubitz wrote:
> > On Fri, 2025-11-28 at 09:34 +0100, Rene Engelhard wrote:
> > > Upstream patches related to/for lp-solve I mean:
> > > 
> > > 
> > 
> > Yes, I'm aware of this.
> > 
> > > In any way you need to teach ccc -fPIE. But then I'd wonder why lp-solve 
> > > in
> > > Debian built... That one has "just" -fPIC.
> > 
> > Please see my other mail. I said, I'm going to replace "-fpic" with "-fPIC".
> > 
> > -fpic/-fPIC is for libraries, -fpie/-fPIE for executables.
> > 
> > > See salsa.debian.org/math-team/lp-solve
> > 
> > Which confirms my theory ;-).
> 
> The attached patch replaces "-fpic" with "-fPIC" in the lp-solve build script 
> which
> seems to be enough to fix this particular build issue on sparc64.

Can you please do some care in your "patches" so that one doesn't need to
replicate anything in them which makes the patch moot in the first place?

Here even a new patch patching ccc is not needed at all. In this case
external/lpsolve/lp_solve_5.5.patch already adds
+ pic=-fpic
itself. Which is used.

So the correct patch is
--- external/lpsolve/lp_solve_5.5.patch-old 2025-11-28 19:18:23.702374716 
+0100
+++ external/lpsolve/lp_solve_5.5.patch 2025-11-28 19:18:33.730426860 +0100
@@ -28,7 +28,7 @@
 + a=a
 + soprefix=lib
 + libs="-lm"
-+ pic=-fpic
++ pic=-fPIC
 + ldflags="-Wl,-Bsymbolic -Wl,-soname,liblpsolve55.$so"
  fi

Regards,

Ren

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[Rene Engelhard]

Hi,

Am 28.11.25 02:44, schrieb John Paul Adrian Glaubitz:
> On Fri, 2025-11-28 at 14:29 +0100, Rene Engelhard wrote:
> > I wouldn't be so.sure. Everywhere where rust is enabled it builds. 
> > See the OOO_RUST_ARCHS setting in rules (im git: OOO_RUST_UNO_ARCHS)
> > See the experimental buildlogs. (Working is something else, see -powerpc).
> > 
> > If it didn't on sparc64 and the extension makefile assumes it's there 
> > without
> > a proper dependency (don't think it does, but..). 
> > 
> > In any case that would be an other bug :) We will see with beta1. Or you try
> > on sid if you report against sid...
> 
> It could be a result of me resuming the failed dpkg build manually after 
> making
> the two changes to pdfium and lp_solve.

Or "too much" parallelity. 48 on stadler seems to be too much, too, 4
works :). Didn't test more.

Regards,

Rene

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[Rene Engelhard]

Hi,

I wouldn't be so.sure. Everywhere where rust is enabled it builds.  See the 
OOO_RUST_ARCHS setting in rules (im git: OOO_RUST_UNO_ARCHS) See the 
experimental buildlogs. (Working is something else, see -powerpc).

 If it didn't on sparc64 and the extension makefile assumes it's there without 
a proper dependency (don't think it does, but..). 

In any case that would be an other bug :) We will see with beta1. Or you try on 
sid if you report against sid...

Regards 

Rene

Am 28. November 2025 13:22:43 MEZ schrieb John Paul Adrian Glaubitz 
:
>Hi,
>
>On Fri, 2025-11-28 at 12:02 +0100, John Paul Adrian Glaubitz wrote:
>> On Fri, 2025-11-28 at 09:46 +0100, John Paul Adrian Glaubitz wrote:
>> > On Fri, 2025-11-28 at 09:34 +0100, Rene Engelhard wrote:
>> > > Upstream patches related to/for lp-solve I mean:
>> > > 
>> > > 
>> > 
>> > Yes, I'm aware of this.
>> > 
>> > > In any way you need to teach ccc -fPIE. But then I'd wonder why lp-solve 
>> > > in
>> > > Debian built... That one has "just" -fPIC.
>> > 
>> > Please see my other mail. I said, I'm going to replace "-fpic" with 
>> > "-fPIC".
>> > 
>> > -fpic/-fPIC is for libraries, -fpie/-fPIE for executables.
>> > 
>> > > See salsa.debian.org/math-team/lp-solve
>> > 
>> > Which confirms my theory ;-).
>> 
>> The attached patch replaces "-fpic" with "-fPIC" in the lp-solve build 
>> script which
>> seems to be enough to fix this particular build issue on sparc64.
>
>So, it gets beyond the previous linker problem now but fails while linking 
>Rust code:
>
>[LNK] ExtensionLibrary/rust_uno-example.uno.so
>/usr/bin/ld: cannot find -lrust_uno: No such file or directory
>collect2: error: ld returned 1 exit status
>make[1]: *** 
>[/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/solenv/gbuild/LinkTarget.mk:869:
> 
>/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/workdir/LinkTarget/ExtensionLibrary/rust_uno-
>example.uno.so] Error 1
>make[1]: *** Waiting for unfinished jobs
>make: *** [Makefile:301: build] Error 2
>
>I assume that this is unrelated to sparc64.
>
>Adrian
>
>-- 
> .''`.  John Paul Adrian Glaubitz
>: :' :  Debian Developer
>`. `'   Physicist
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Hello,

On Fri, 2025-11-28 at 14:29 +0100, Rene Engelhard wrote:
> I wouldn't be so.sure. Everywhere where rust is enabled it builds. 
> See the OOO_RUST_ARCHS setting in rules (im git: OOO_RUST_UNO_ARCHS)
> See the experimental buildlogs. (Working is something else, see -powerpc).
> 
> If it didn't on sparc64 and the extension makefile assumes it's there without
> a proper dependency (don't think it does, but..). 
> 
> In any case that would be an other bug :) We will see with beta1. Or you try
> on sid if you report against sid...

It could be a result of me resuming the failed dpkg build manually after making
the two changes to pdfium and lp_solve.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Hi,

On Fri, 2025-11-28 at 12:02 +0100, John Paul Adrian Glaubitz wrote:
> On Fri, 2025-11-28 at 09:46 +0100, John Paul Adrian Glaubitz wrote:
> > On Fri, 2025-11-28 at 09:34 +0100, Rene Engelhard wrote:
> > > Upstream patches related to/for lp-solve I mean:
> > > 
> > > 
> > 
> > Yes, I'm aware of this.
> > 
> > > In any way you need to teach ccc -fPIE. But then I'd wonder why lp-solve 
> > > in
> > > Debian built... That one has "just" -fPIC.
> > 
> > Please see my other mail. I said, I'm going to replace "-fpic" with "-fPIC".
> > 
> > -fpic/-fPIC is for libraries, -fpie/-fPIE for executables.
> > 
> > > See salsa.debian.org/math-team/lp-solve
> > 
> > Which confirms my theory ;-).
> 
> The attached patch replaces "-fpic" with "-fPIC" in the lp-solve build script 
> which
> seems to be enough to fix this particular build issue on sparc64.

So, it gets beyond the previous linker problem now but fails while linking Rust 
code:

[LNK] ExtensionLibrary/rust_uno-example.uno.so
/usr/bin/ld: cannot find -lrust_uno: No such file or directory
collect2: error: ld returned 1 exit status
make[1]: *** 
[/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/solenv/gbuild/LinkTarget.mk:869:
 
/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/workdir/LinkTarget/ExtensionLibrary/rust_uno-
example.uno.so] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:301: build] Error 2

I assume that this is unrelated to sparc64.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Hello,

On Fri, 2025-11-28 at 09:46 +0100, John Paul Adrian Glaubitz wrote:
> On Fri, 2025-11-28 at 09:34 +0100, Rene Engelhard wrote:
> > Upstream patches related to/for lp-solve I mean:
> > 
> > 
> 
> Yes, I'm aware of this.
> 
> > In any way you need to teach ccc -fPIE. But then I'd wonder why lp-solve in
> > Debian built... That one has "just" -fPIC.
> 
> Please see my other mail. I said, I'm going to replace "-fpic" with "-fPIC".
> 
> -fpic/-fPIC is for libraries, -fpie/-fPIE for executables.
> 
> > See salsa.debian.org/math-team/lp-solve
> 
> Which confirms my theory ;-).

The attached patch replaces "-fpic" with "-fPIC" in the lp-solve build script 
which
seems to be enough to fix this particular build issue on sparc64.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- /home/glaubitz/loffice/libreoffice-26.2.0~alpha1/workdir/UnpackedTarball/lpsolve/lpsolve55/ccc.orig	2025-11-28 10:13:07.347841660 +0100
+++ /home/glaubitz/loffice/libreoffice-26.2.0~alpha1/workdir/UnpackedTarball/lpsolve/lpsolve55/ccc	2025-11-28 10:29:28.092478983 +0100
@@ -22,7 +22,7 @@
  a=a
  soprefix=lib
  libs="-lm"
- pic=-fpic
+ pic=-fPIC
  ldflags="-Wl,-Bsymbolic -Wl,-soname,liblpsolve55.$so"
 fi
 

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[Rene Engelhard]

Hi,

Upstream patches related to/for lp-solve I mean:



In any way you need to teach ccc -fPIE. But then I'd wonder why lp-solve in 
Debian built... That one has "just" -fPIC.

See salsa.debian.org/math-team/lp-solve

Regards 

Rene

Am 28. November 2025 09:23:26 MEZ schrieb Rene Engelhard 
:
>Hi,
>
>The internal lp-solve probably just doesn't honour the system env buildflags. 
>It's a crude shell script used for building (ccc), see the existing 
>lp-solve-related patches.
>
>Regards 
>
>Rene
>
>Am 28. November 2025 08:53:17 MEZ schrieb John Paul Adrian Glaubitz 
>:
>>Hi Jan,
>>
>>On Fri, 2025-11-28 at 00:17 +0100, Jan Engelhardt wrote:
>>> On Thursday 2025-11-27 22:13, John Paul Adrian Glaubitz wrote:
>>> > --- debian/rules.orig   2025-11-08 21:28:26.0 +0100
>>> > +++ debian/rules2025-11-27 22:11:18.063514133 +0100
>>> > @@ -1146,6 +1146,11 @@
>>> >DEB_CXXFLAGS_MAINT_APPEND = -ffp-contract=off
>>> > endif
>>> > 
>>> > +ifneq (,$(filter sparc64,$(DEB_HOST_ARCH)))
>>> > +   DEB_CFLAGS_MAINT_APPEND = -fPIE
>>> > +   DEB_CXXFLAGS_MAINT_APPEND = -fPIE
>>> > +endif
>>> 
>>> If all you have a "hammer" (e.g. `./configure CFLAGS=-fPIC`), that CFLAGS
>>> variable may be used by the software project for both executables and shared
>>> libraries.
>>> 
>>> It is possible for the build to fail, since PIE is not meant to
>>> be used when building shared libraries.
>>> 
>>> If that happens, you have to switch from PIE to PIC (that latter is more
>>> general).
>>> 
>>> On the other hand, if the software project uses libtool, you are in good 
>>> hands:
>>> libtool forces -fPIC on shared libs anyway and transparently strips any
>>> conflicting -fPIE internally (it also eats the small model -fpic/-fpie
>>> in favor of -fPIC).
>>
>>Yeah, you seem to be correct with your analysis as the -fPIE didn't help and 
>>the
>>error still occurs:
>>
>>../shared/commonlib.c: In function 'timeNow':
>>../shared/commonlib.c:705:3: warning: 'ftime' is deprecated: Use gettimeofday 
>>or clock_gettime instead [-Wdeprecated-declarations]
>>  705 |   ftime(&buf);
>>  |   ^
>>In file included from ../shared/commonlib.c:7:
>>/usr/include/sparc64-linux-gnu/sys/timeb.h:29:12: note: declared here
>>   29 | extern int ftime (struct timeb *__timebuf)
>>  |^
>>lp_MDO.o: in function `getMDO':
>>lp_MDO.c:(.text+0x6f4): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `mdo_free' defined in .text section in lp_MDO.o
>>lp_MDO.c:(.text+0x6fc): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `mdo_calloc' defined in .text section in lp_MDO.o
>>mmio.o: in function `mm_read_mtx_crd':
>>mmio.c:(.text+0x938): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `stdin@@GLIBC_2.2' defined in .data section in 
>>/lib/sparc64-linux-gnu/libc.so.6
>>mmio.c:(.text+0x9f8): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `stdin@@GLIBC_2.2' defined in .data section in 
>>/lib/sparc64-linux-gnu/libc.so.6
>>mmio.c:(.text+0xa7c): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `stdin@@GLIBC_2.2' defined in .data section in 
>>/lib/sparc64-linux-gnu/libc.so.6
>>mmio.o: in function `mm_read_unsymmetric_sparse':
>>mmio.c:(.text+0xce8): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `stderr@@GLIBC_2.2' defined in .data section in 
>>/lib/sparc64-linux-gnu/libc.so.6
>>mmio.c:(.text+0xd24): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `stderr@@GLIBC_2.2' defined in .data section in 
>>/lib/sparc64-linux-gnu/libc.so.6
>>mmio.o: in function `mm_write_mtx_crd':
>>mmio.c:(.text+0xdd0): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `stdout@@GLIBC_2.2' defined in .data section in 
>>/lib/sparc64-linux-gnu/libc.so.6
>>mmio.c:(.text+0xf44): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `stdout@@GLIBC_2.2' defined in .data section in 
>>/lib/sparc64-linux-gnu/libc.so.6
>>myblas.o: in function `is_nativeBLAS':
>>myblas.c:(.text+0x7a0): relocation truncated to fit: R_SPARC_GOT13 against 
>>symbol `hBLAS' defined in .bss section in myblas.o
>>myblas.o: in function `load_BLAS':
>>myblas.c:(.text+0x7c0): additional relocation overflows omitted from the 
>>output
>>collect2: error: ld returned 1 exit status
>>make: *** 
>>[/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/external/lpsolve/ExternalProject_lpsolve.mk:27:
>> 
>>/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/workdir/ExternalProject/lpsolve/build]
>>Error 1
>>
>>So, I'll have to dig deeper in the build system where I need to pass -fPIE.
>>
>>Adrian
>>
>>-- 
>> .''`.  John Paul Adrian Glaubitz
>>: :' :  Debian Developer
>>`. `'   Physicist
>>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>>

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Hello,

On Fri, 2025-11-28 at 09:34 +0100, Rene Engelhard wrote:
> Upstream patches related to/for lp-solve I mean:
> 
> 

Yes, I'm aware of this.

> In any way you need to teach ccc -fPIE. But then I'd wonder why lp-solve in
> Debian built... That one has "just" -fPIC.

Please see my other mail. I said, I'm going to replace "-fpic" with "-fPIC".

-fpic/-fPIC is for libraries, -fpie/-fPIE for executables.

> See salsa.debian.org/math-team/lp-solve

Which confirms my theory ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[Rene Engelhard]

Hi,

The internal lp-solve probably just doesn't honour the system env buildflags. 
It's a crude shell script used for building (ccc), see the existing 
lp-solve-related patches.

Regards 

Rene

Am 28. November 2025 08:53:17 MEZ schrieb John Paul Adrian Glaubitz 
:
>Hi Jan,
>
>On Fri, 2025-11-28 at 00:17 +0100, Jan Engelhardt wrote:
>> On Thursday 2025-11-27 22:13, John Paul Adrian Glaubitz wrote:
>> > --- debian/rules.orig   2025-11-08 21:28:26.0 +0100
>> > +++ debian/rules2025-11-27 22:11:18.063514133 +0100
>> > @@ -1146,6 +1146,11 @@
>> >DEB_CXXFLAGS_MAINT_APPEND = -ffp-contract=off
>> > endif
>> > 
>> > +ifneq (,$(filter sparc64,$(DEB_HOST_ARCH)))
>> > +   DEB_CFLAGS_MAINT_APPEND = -fPIE
>> > +   DEB_CXXFLAGS_MAINT_APPEND = -fPIE
>> > +endif
>> 
>> If all you have a "hammer" (e.g. `./configure CFLAGS=-fPIC`), that CFLAGS
>> variable may be used by the software project for both executables and shared
>> libraries.
>> 
>> It is possible for the build to fail, since PIE is not meant to
>> be used when building shared libraries.
>> 
>> If that happens, you have to switch from PIE to PIC (that latter is more
>> general).
>> 
>> On the other hand, if the software project uses libtool, you are in good 
>> hands:
>> libtool forces -fPIC on shared libs anyway and transparently strips any
>> conflicting -fPIE internally (it also eats the small model -fpic/-fpie
>> in favor of -fPIC).
>
>Yeah, you seem to be correct with your analysis as the -fPIE didn't help and 
>the
>error still occurs:
>
>../shared/commonlib.c: In function 'timeNow':
>../shared/commonlib.c:705:3: warning: 'ftime' is deprecated: Use gettimeofday 
>or clock_gettime instead [-Wdeprecated-declarations]
>  705 |   ftime(&buf);
>  |   ^
>In file included from ../shared/commonlib.c:7:
>/usr/include/sparc64-linux-gnu/sys/timeb.h:29:12: note: declared here
>   29 | extern int ftime (struct timeb *__timebuf)
>  |^
>lp_MDO.o: in function `getMDO':
>lp_MDO.c:(.text+0x6f4): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `mdo_free' defined in .text section in lp_MDO.o
>lp_MDO.c:(.text+0x6fc): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `mdo_calloc' defined in .text section in lp_MDO.o
>mmio.o: in function `mm_read_mtx_crd':
>mmio.c:(.text+0x938): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `stdin@@GLIBC_2.2' defined in .data section in 
>/lib/sparc64-linux-gnu/libc.so.6
>mmio.c:(.text+0x9f8): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `stdin@@GLIBC_2.2' defined in .data section in 
>/lib/sparc64-linux-gnu/libc.so.6
>mmio.c:(.text+0xa7c): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `stdin@@GLIBC_2.2' defined in .data section in 
>/lib/sparc64-linux-gnu/libc.so.6
>mmio.o: in function `mm_read_unsymmetric_sparse':
>mmio.c:(.text+0xce8): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `stderr@@GLIBC_2.2' defined in .data section in 
>/lib/sparc64-linux-gnu/libc.so.6
>mmio.c:(.text+0xd24): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `stderr@@GLIBC_2.2' defined in .data section in 
>/lib/sparc64-linux-gnu/libc.so.6
>mmio.o: in function `mm_write_mtx_crd':
>mmio.c:(.text+0xdd0): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `stdout@@GLIBC_2.2' defined in .data section in 
>/lib/sparc64-linux-gnu/libc.so.6
>mmio.c:(.text+0xf44): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `stdout@@GLIBC_2.2' defined in .data section in 
>/lib/sparc64-linux-gnu/libc.so.6
>myblas.o: in function `is_nativeBLAS':
>myblas.c:(.text+0x7a0): relocation truncated to fit: R_SPARC_GOT13 against 
>symbol `hBLAS' defined in .bss section in myblas.o
>myblas.o: in function `load_BLAS':
>myblas.c:(.text+0x7c0): additional relocation overflows omitted from the output
>collect2: error: ld returned 1 exit status
>make: *** 
>[/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/external/lpsolve/ExternalProject_lpsolve.mk:27:
> 
>/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/workdir/ExternalProject/lpsolve/build]
>Error 1
>
>So, I'll have to dig deeper in the build system where I need to pass -fPIE.
>
>Adrian
>
>-- 
> .''`.  John Paul Adrian Glaubitz
>: :' :  Debian Developer
>`. `'   Physicist
>  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Hello,

On Fri, 2025-11-28 at 09:23 +0100, Rene Engelhard wrote:
> The internal lp-solve probably just doesn't honour the system env buildflags. 
> It's a
> crude shell script used for building (ccc), see the existing lp-solve-related 
> patches.

Yes, I just discovered that. I have replaced "pic" with "PIC" there and see if 
that helps.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Hi Jan,

On Fri, 2025-11-28 at 00:17 +0100, Jan Engelhardt wrote:
> On Thursday 2025-11-27 22:13, John Paul Adrian Glaubitz wrote:
> > --- debian/rules.orig   2025-11-08 21:28:26.0 +0100
> > +++ debian/rules2025-11-27 22:11:18.063514133 +0100
> > @@ -1146,6 +1146,11 @@
> >DEB_CXXFLAGS_MAINT_APPEND = -ffp-contract=off
> > endif
> > 
> > +ifneq (,$(filter sparc64,$(DEB_HOST_ARCH)))
> > +   DEB_CFLAGS_MAINT_APPEND = -fPIE
> > +   DEB_CXXFLAGS_MAINT_APPEND = -fPIE
> > +endif
> 
> If all you have a "hammer" (e.g. `./configure CFLAGS=-fPIC`), that CFLAGS
> variable may be used by the software project for both executables and shared
> libraries.
> 
> It is possible for the build to fail, since PIE is not meant to
> be used when building shared libraries.
> 
> If that happens, you have to switch from PIE to PIC (that latter is more
> general).
> 
> On the other hand, if the software project uses libtool, you are in good 
> hands:
> libtool forces -fPIC on shared libs anyway and transparently strips any
> conflicting -fPIE internally (it also eats the small model -fpic/-fpie
> in favor of -fPIC).

Yeah, you seem to be correct with your analysis as the -fPIE didn't help and the
error still occurs:

../shared/commonlib.c: In function 'timeNow':
../shared/commonlib.c:705:3: warning: 'ftime' is deprecated: Use gettimeofday 
or clock_gettime instead [-Wdeprecated-declarations]
  705 |   ftime(&buf);
  |   ^
In file included from ../shared/commonlib.c:7:
/usr/include/sparc64-linux-gnu/sys/timeb.h:29:12: note: declared here
   29 | extern int ftime (struct timeb *__timebuf)
  |^
lp_MDO.o: in function `getMDO':
lp_MDO.c:(.text+0x6f4): relocation truncated to fit: R_SPARC_GOT13 against 
symbol `mdo_free' defined in .text section in lp_MDO.o
lp_MDO.c:(.text+0x6fc): relocation truncated to fit: R_SPARC_GOT13 against 
symbol `mdo_calloc' defined in .text section in lp_MDO.o
mmio.o: in function `mm_read_mtx_crd':
mmio.c:(.text+0x938): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdin@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.c:(.text+0x9f8): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdin@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.c:(.text+0xa7c): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdin@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.o: in function `mm_read_unsymmetric_sparse':
mmio.c:(.text+0xce8): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stderr@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.c:(.text+0xd24): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stderr@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.o: in function `mm_write_mtx_crd':
mmio.c:(.text+0xdd0): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdout@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.c:(.text+0xf44): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdout@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
myblas.o: in function `is_nativeBLAS':
myblas.c:(.text+0x7a0): relocation truncated to fit: R_SPARC_GOT13 against 
symbol `hBLAS' defined in .bss section in myblas.o
myblas.o: in function `load_BLAS':
myblas.c:(.text+0x7c0): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
make: *** 
[/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/external/lpsolve/ExternalProject_lpsolve.mk:27:
 
/home/glaubitz/loffice/libreoffice-26.2.0~alpha1/workdir/ExternalProject/lpsolve/build]
Error 1

So, I'll have to dig deeper in the build system where I need to pass -fPIE.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[Jan Engelhardt]

On Thursday 2025-11-27 22:13, John Paul Adrian Glaubitz wrote:
>--- debian/rules.orig   2025-11-08 21:28:26.0 +0100
>+++ debian/rules2025-11-27 22:11:18.063514133 +0100
>@@ -1146,6 +1146,11 @@
>DEB_CXXFLAGS_MAINT_APPEND = -ffp-contract=off
> endif
> 
>+ifneq (,$(filter sparc64,$(DEB_HOST_ARCH)))
>+   DEB_CFLAGS_MAINT_APPEND = -fPIE
>+   DEB_CXXFLAGS_MAINT_APPEND = -fPIE
>+endif

If all you have a "hammer" (e.g. `./configure CFLAGS=-fPIC`), that CFLAGS
variable may be used by the software project for both executables and shared
libraries.

It is possible for the build to fail, since PIE is not meant to
be used when building shared libraries.

If that happens, you have to switch from PIE to PIC (that latter is more
general).

On the other hand, if the software project uses libtool, you are in good hands:
libtool forces -fPIC on shared libs anyway and transparently strips any
conflicting -fPIE internally (it also eats the small model -fpic/-fpie
in favor of -fPIC).

Bug#1121530: libreoffice: Please build with -fPIE on sparc64 to fix FTBFS

[John Paul Adrian Glaubitz]

Source: libreoffice
Version: 4:25.8.3-1
Severity: normal
Tags: patch
User: debian-sparc@lists.debian.org
Usertags: sparc64
X-Debbugs-Cc: debian-sparc@lists.debian.org

Hi,

on sparc64, libreoffice fails to build from source due to some GOT offsets
being too large for the dynamic linker:

lp_MDO.o: in function `getMDO':
lp_MDO.c:(.text+0x6f4): relocation truncated to fit: R_SPARC_GOT13 against 
symbol `mdo_free' defined in .text section in lp_MDO.o
lp_MDO.c:(.text+0x6fc): relocation truncated to fit: R_SPARC_GOT13 against 
symbol `mdo_calloc' defined in .text section in lp_MDO.o
mmio.o: in function `mm_read_mtx_crd':
mmio.c:(.text+0x938): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdin@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.c:(.text+0x9f8): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdin@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.c:(.text+0xa7c): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdin@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.o: in function `mm_read_unsymmetric_sparse':
mmio.c:(.text+0xce8): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stderr@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.c:(.text+0xd24): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stderr@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.o: in function `mm_write_mtx_crd':
mmio.c:(.text+0xdd0): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdout@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
mmio.c:(.text+0xf44): relocation truncated to fit: R_SPARC_GOT13 against symbol 
`stdout@@GLIBC_2.2' defined in .data section in /lib/sparc64-linux-gnu/libc.so.6
myblas.o: in function `is_nativeBLAS':
myblas.c:(.text+0x7a0): relocation truncated to fit: R_SPARC_GOT13 against 
symbol `hBLAS' defined in .bss section in myblas.o
myblas.o: in function `load_BLAS':
myblas.c:(.text+0x7c0): additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status

This can be fixed by passing "-fPIE" which makes sure the compiler makes sure
that the GOT entries are capable of handling large offsets.

I propose the following patch:

--- debian/rules.orig   2025-11-08 21:28:26.0 +0100
+++ debian/rules2025-11-27 22:11:18.063514133 +0100
@@ -1146,6 +1146,11 @@
DEB_CXXFLAGS_MAINT_APPEND = -ffp-contract=off
 endif
 
+ifneq (,$(filter sparc64,$(DEB_HOST_ARCH)))
+   DEB_CFLAGS_MAINT_APPEND = -fPIE
+   DEB_CXXFLAGS_MAINT_APPEND = -fPIE
+endif
+
 ifneq (,$(filter s390x,$(DEB_HOST_ARCH)))
   ifeq (,$(shell gcc -v 2>&1 | grep disable-s390-excess-float-precision))
DEB_CFLAGS_MAINT_APPEND = -fexcess-precision=fast

I'm attaching the patch to this bug report as well.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- debian/rules.orig   2025-11-08 21:28:26.0 +0100
+++ debian/rules2025-11-27 22:11:18.063514133 +0100
@@ -1146,6 +1146,11 @@
DEB_CXXFLAGS_MAINT_APPEND = -ffp-contract=off
 endif
 
+ifneq (,$(filter sparc64,$(DEB_HOST_ARCH)))
+   DEB_CFLAGS_MAINT_APPEND = -fPIE
+   DEB_CXXFLAGS_MAINT_APPEND = -fPIE
+endif
+
 ifneq (,$(filter s390x,$(DEB_HOST_ARCH)))
   ifeq (,$(shell gcc -v 2>&1 | grep disable-s390-excess-float-precision))
DEB_CFLAGS_MAINT_APPEND = -fexcess-precision=fast