Re: [macppc, all archs] net/echoping wants libm
Charlene Wendling: > > util.o: In function `tvstddev': > > util.c:(.text+0x6f4): undefined reference to `sqrt' > > The autoconf stuff really detects the need for`-lm' as seen in > config.log: 'ac_cv_lib_m_sqrt=yes', but is not used anywhere at all. No, we are preloading the autoconf cache with this and many other results. See infrastructure/db/config.site. There is no actual test for this in the configure script. There _is_ a test whether -lm is required for pow(3), "checking if libmath is mandatory". If you run nm(1) on the compiled util.o on amd64, there is no unresolved reference to sqrt(). What's happening here is that the compiler inlines its own optimized sqrt(), instead of calling the libm function. The same happens for pow() in the configure test. Or worse, I think the compiler notices that this lone pow() call has no effect and just drops it, neutering the test. If you compile with -ffreestanding, which is the ultimate hammer to prevent such shenanigans, util.o has a reference to sqrt() and the configure check for -lm actually works. Anyway, that's not a solution for the port. Your solution is fine, but the comment needs to be tweaked. Maybe like this? # Requires libm: uses sqrt(3), inlined by the compiler on some archs -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: [macppc, all archs] net/echoping wants libm
On Wed, 10 Feb 2021 00:55:49 +0100
Charlene Wendling wrote:
> > util.o: In function `tvstddev':
> > util.c:(.text+0x6f4): undefined reference to `sqrt'
>
> I thought it was a ld.bfd issue but...
>
> Very surprisingly, i tried to reproduce on amd64 with USE_LLD=No to no
> avail, and the sparc64 bulk reports no failures. I can't compare with
> mips64 because no bulk is run currently.
ok gkoehler@
The compiler inlines the amd64 cpu instruction for sqrt, but one can
reproduce the error on amd64 by,
$ make COPTS=-fno-builtin-sqrt
powerpc64 clang inlines the instruction "fsqrt", but macppc clang calls
sqrt() and needs libm. This is because llvm believes that the G5 has
"fsqrt" but G4 and G3 don't have "fsqrt"; and the default target cpu in
powerpc64 clang seems to be the G5.--George
> Index: Makefile
> ===
> RCS file: /cvs/ports/net/echoping/Makefile,v
> retrieving revision 1.15
> diff -u -p -u -p -r1.15 Makefile
> --- Makefile 1 Feb 2021 19:47:08 - 1.15
> +++ Makefile 9 Feb 2021 23:50:36 -
> @@ -5,7 +5,7 @@ COMMENT= test performance of remote TCP/
> VER= 6_0_2
> DISTNAME=echoping-RELEASE_${VER}
> PKGNAME= echoping-${VER:S/_/./g}
> -REVISION=0
> +REVISION=1
> CATEGORIES= net
>
> MASTER_SITES=
> https://framagit.org/bortzmeyer/echoping/-/archive/RELEASE_${VER}/
> @@ -36,6 +36,10 @@ CONFIGURE_ARGS+= --enable-plugin="dns ra
> --enable-smtp \
> --enable-tos \
> --without-libidn
> +
> +# Requires libm (uses sqrt(3)), detected by autoconf but not used anywhere
> else
> +# in the build configuration
> +CONFIGURE_ENV+= LDFLAGS="${LDFLAGS} -lm"
>
> WRKDIST= ${WRKDIR}/${DISTNAME}/SRC
>
> Index: pkg/DESCR
> ===
> RCS file: /cvs/ports/net/echoping/pkg/DESCR,v
> retrieving revision 1.3
> diff -u -p -u -p -r1.3 DESCR
> --- pkg/DESCR 1 Feb 2021 18:10:44 - 1.3
> +++ pkg/DESCR 9 Feb 2021 23:50:36 -
> @@ -1,3 +1,3 @@
> -"echoping" is a small program to test (approximately) performance of a
> +"echoping" is a small program to test (approximately) performance of a
> remote host by sending it packets using various protocols (TCP/UDP echo,
> HTTP/HTTPS and some others).
>
--
George Koehler
[macppc, all archs] net/echoping wants libm
Hi,
I've spotted that echoping's build is broken in the current macppc bulk:
> util.o: In function `tvstddev':
> util.c:(.text+0x6f4): undefined reference to `sqrt'
I thought it was a ld.bfd issue but...
Very surprisingly, i tried to reproduce on amd64 with USE_LLD=No to no
avail, and the sparc64 bulk reports no failures. I can't compare with
mips64 because no bulk is run currently.
The autoconf stuff really detects the need for`-lm' as seen in
config.log: 'ac_cv_lib_m_sqrt=yes', but is not used anywhere at all.
In fact, FreeBSD met the issue before us [0]; we need the `-lm' LDFLAG.
While here, i removed a trailing whitespace in DESCR that portcheck
found.
Then it builds fine on macppc [1], and still does on amd64. I tested
examples provided by the manpage without issues (there is no regression
tests).
Comments/feedback are welcome,
Charlène.
[0] https://svnweb.freebsd.org/ports?view=revision&revision=368948
[1] https://bin.charlenew.xyz/echoping.log
Index: Makefile
===
RCS file: /cvs/ports/net/echoping/Makefile,v
retrieving revision 1.15
diff -u -p -u -p -r1.15 Makefile
--- Makefile1 Feb 2021 19:47:08 - 1.15
+++ Makefile9 Feb 2021 23:50:36 -
@@ -5,7 +5,7 @@ COMMENT=test performance of remote TCP/
VER= 6_0_2
DISTNAME= echoping-RELEASE_${VER}
PKGNAME= echoping-${VER:S/_/./g}
-REVISION= 0
+REVISION= 1
CATEGORIES=net
MASTER_SITES=
https://framagit.org/bortzmeyer/echoping/-/archive/RELEASE_${VER}/
@@ -36,6 +36,10 @@ CONFIGURE_ARGS+= --enable-plugin="dns ra
--enable-smtp \
--enable-tos \
--without-libidn
+
+# Requires libm (uses sqrt(3)), detected by autoconf but not used anywhere else
+# in the build configuration
+CONFIGURE_ENV+=LDFLAGS="${LDFLAGS} -lm"
WRKDIST= ${WRKDIR}/${DISTNAME}/SRC
Index: pkg/DESCR
===
RCS file: /cvs/ports/net/echoping/pkg/DESCR,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 DESCR
--- pkg/DESCR 1 Feb 2021 18:10:44 - 1.3
+++ pkg/DESCR 9 Feb 2021 23:50:36 -
@@ -1,3 +1,3 @@
-"echoping" is a small program to test (approximately) performance of a
+"echoping" is a small program to test (approximately) performance of a
remote host by sending it packets using various protocols (TCP/UDP echo,
HTTP/HTTPS and some others).
