Build error: storage_umem.c: error: link.h: No such file or directory

[barracuda156]

Expected Behavior

Build should succeed.

Current Behavior

Looks like it includes a non-existing header here:

storage/storage_umem.c:46:18: error: link.h: No such file or directory
storage/storage_umem.c: In function ‘smu_init’:
storage/storage_umem.c:332: warning: implicit declaration of function ‘dlmopen’
storage/storage_umem.c:332: error: ‘LM_ID_NEWLM’ undeclared (first use in this function)
storage/storage_umem.c:332: error: (Each undeclared identifier is reported only once
storage/storage_umem.c:332: error: for each function it appears in.)
storage/storage_umem.c:332: warning: assignment makes pointer from integer without a cast
make[4]: *** [storage/varnishd-storage_umem.o] Error 1

Possible Solution

No response

Steps to Reproduce (for bugs)

No response

Context

I am trying to update varnish port in MacPorts, for which I need it to build for a range of supported systems.

Varnish Cache version

7.6.0

Operating system

macOS 10.6

Source of binary packages used (if any)

No response

[barracuda156]

It looks like link.h is a Linux header, but the guarding macro does not check for the OS, but only for umem.h presence. The problem is that the check does not limit itself to system includes, and umem.h may be present from some third-party software, for example:

36-242% port provides /opt/local/include/umem.h 
/opt/local/include/umem.h is provided by: umem

Deactivating umem will probably solve this issue locally, but this arrangement is rather fragile.

[dridi]

Does it build if you remove the include?

I don't think link.h is a Linux-only header, because we currently don't build with umem support on Linux. To my knowledge, only SunOS and FreeBSD.

[barracuda156]

@dridi Yeah, if umem.h is not found, build works normally. I think it is worth at least excluding systems which are not meant to use this file. Adding something like #ifndef __APPLE__ is easy and may save someone from headache.

[nigoroll]

@barracuda156 I am not familiar with MacPorts, could you please give a some pointers on the libumem sources used with it?

[barracuda156]

@nigoroll This is the port which installed umem.h: https://ports.macports.org/port/umem

[dridi]

FWIW I was not suggesting to remove umem.h from your system. I was wondering whether the build is still broken after doing something like this:

--- i/bin/varnishd/storage/storage_umem.c
+++ w/bin/varnishd/storage/storage_umem.c
@@ -43,7 +43,9 @@
 #include <stdlib.h>
 #include <umem.h>
 #include <dlfcn.h>
+#ifndef __APPLE__
 #include <link.h>
+#endif
 #include <string.h>
 
 #include "storage/storage.h"

In other words, not involving link.h on your system where it does not exist. If it fails to compile, we can dig deeper.

[nigoroll]

@dridi the OP also reported dlmopen() missing. I will look

[nigoroll]

FTR from bugwash: we do not build umem for bsd, phk sais:

(15:16:20) phk: critter phk> size storage/varnishd-storage_umem.o 
(15:16:20) phk:   text   data   bss   dec   hex   filename
(15:16:20) phk:      0      0     0     0   0x0   storage/varnishd-storage_umem.o