I'm not getting a clean build for gkrellm-2.3.6-rc I found this in the logs: fgets(buf, sizeof(buf), f); ^ sysdeps/linux.c: In function ‘sysfs_get_chip_name’: sysdeps/linux.c:3525:2: warning: ignoring return value of ‘fscanf’, declared with attribute warn_unused_result [-Wunused-result] fscanf(f, "%255[^\n]", buf); ^ x86_64-pc-linux-gnu-gcc main.o alerts.o battery.o base64.o clock.o cpu.o disk.o fs.o hostname.o inet.o mail.o mem.o net.o proc.o sensors.o uptime.o chart.o panel.o config.o gui.o krell.o plugins.o pixops.o client.o utils.o sysdeps-unix.o deprecated.o log.o winops-x11.o -o gkrellm \ -Wl,-O1 -Wl,--as-needed `pkg-config --libs gtk+-2.0 gmodule-2.0 gthread-2.0` -lX11 -lSM -lICE "-lsensors" -lm -Wl,-E mail.o: In function `do_cram_md5.constprop.18': mail.c:(.text+0x5f31): undefined reference to `MD5Init' mail.c:(.text+0x5f4e): undefined reference to `MD5Update' mail.c:(.text+0x5f61): undefined reference to `MD5Final' mail.c:(.text+0x600b): undefined reference to `MD5Init' mail.c:(.text+0x6026): undefined reference to `MD5Update' mail.c:(.text+0x6038): undefined reference to `MD5Update' mail.c:(.text+0x604b): undefined reference to `MD5Final' mail.c:(.text+0x6057): undefined reference to `MD5Init' mail.c:(.text+0x606b): undefined reference to `MD5Update' mail.c:(.text+0x6083): undefined reference to `MD5Update' mail.c:(.text+0x6096): undefined reference to `MD5Final' mail.o: In function `check_pop3': mail.c:(.text+0x66a1): undefined reference to `MD5Init' mail.c:(.text+0x66e8): undefined reference to `MD5Update' mail.c:(.text+0x66fb): undefined reference to `MD5Final' collect2: error: ld returned 1 exit status Makefile:96: recipe for target 'gkrellm' failed make[1]: *** [gkrellm] Error 1 make[1]: Leaving directory '/tmp/portage/portage/app-admin/gkrellm-2.3.6_rc1/work/gkrellm-2.3.6-rc1/src' Makefile:127: recipe for target 'all' failed make: *** [all] Error 2 * ERROR: app-admin/gkrellm-2.3.6_rc1::gentoo failed (compile phase): * emake failed For me that looks like gkrellm needs MD5 support.
Please post the full build log.
Created attachment 411636 [details] build log of gkrellm-2.3.6_rc1
probably builds if you use USE=-gnutls as those look like openssl symbols
Yes it builds with USE="-gnutls". Now, I'd like to use gnutls. Is this an upstream bug?
Definitely partially an upstream bug. libopenssl.so and libgnutls-openssl.so do have MD5_Init but not MD5Init. How could this ever have worked? Maybe we can just rename MD5Init, MD5_Update and MD5_Final. What is still strange is that the log says "--without-ssl=yes" although USE=gnutls (and accordingly the linker line does not contain the gnutls libs.
Looking closer, I don't see any problem (and cannot reproduce). mail.c defines MD5Init to MD5_Init when gnutls is found. Passing --without-ssl without --without-gnutls to make does indeed make it use gnutls. @Attila: Could you also post /mnt/ramdisk/portage/app-admin/gkrellm-2.3.6_rc1/work/src/configure.log ?
Created attachment 411696 [details] /tmp/portage/portage/app-admin/gkrellm-2.3.6_rc1/work/gkrellm-2.3.6-rc1/src/configure.log Ah, that looks interesting... CC : x86_64-pc-linux-gnu-gcc CFLAGS: -march=native -O2 -pipe PKG_CONFIG: pkg-config Checking for gnutls... test.c:1:28: fatal error: gnutls/openssl.h: No such file or directory #include <gnutls/openssl.h> ^ compilation terminated. x86_64-pc-linux-gnu-gcc: error: test.o: No such file or directory GnuTLS not found... Checking for libsensors... Defining HAVE_LIBSENSORS
So gkrellm[gnutls] should depend on gnutls[openssl]. Test this by trying to emerge gkrellm after rebuilding gnutls with USE=openssl.
Yes, that worked. Isn't one purpose of using gnutls that I choose it over/insteat of openssl?
Fails here with the same error with these flags: app-admin/gkrellm-2.3.6_rc1:2::gentoo [2.3.5-r3:2::gentoo] USE="X hddtemp lm_sensors nls -gnutls -ntlm -ssl"
@Attila: USE=openssl for gnutls just makes gnutls ship an additional library for compatibility with openssl. It is not using openssl itself.
Created attachment 411738 [details, diff] Patch for Makefile @Prakash: Please see whether this patch fixes the build failures for you.
@Felix Sorry for reporting back late. But yes, your patch helped in my case.
Is anyone willing to proxy maintain this? https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
*** Bug 582542 has been marked as a duplicate of this bug. ***
Seems to be fixed in gkrellm-2.3.10
