GNOME Bugzilla – Bug 171957
Build --with-perl fails if the system has perl, but not libperl
Last modified: 2005-04-03 03:45:53 UTC
When the system doesn't have libperl headers (eg. if "libperl-dev" package is missing), configure doesn't understand the situation: the tree is configured as if libperl were available; then, "make all" fails. The configure should check for working instalation of libperl library and headers. This problem has to be solved before --with-perl is made the default. Please note that uncomenting the AC_CHECK_LIB(perl,...) macro doesn't help here. This macro call should be deleted. As Morten has explained me, the right check has to use the PERL_* variables. For example, PERL_CC may not be the default compiler. Or perhaps PERL_LDFLAGS may contain options which are necessary to ling the test program. This means that we cannot use AC_LINK_IFELSE directly, we have to use a modified version of its definition. (This issue first appeared in Comment #3 to bug #158029.)
I am not sure how we can keep up with distributions that wish to split, say, perl into a number of subpackages. Do we need to test for each and every header file that we use because it might have been put in its own package? I am tempted to call this a Debian bug and ask that it be filed against them. In any case, "make -k" or installing all of perl works fine, so I am lowering priority.
In comment #1, Morten asks: "Do we need to test for each and every header file that we use because it might have been put in its own package?" Of course not. But many packagers divide each library package in two parts: the library proper and a "devel" package, containing headers and such. I think we should understand this, and when we want to use a library, we should check for one of its headers, not only for the compiled library. When I apply this principle to the perl problem, I think we should check for "perl.h", using PERL_CCOPTS, of course. The AC_CHECK_LIB call can be deleted, without any replacement. Morten, what would you say? Let me outline some details: After the PERL_* vars have been assigned, we'd temporarily change CC=$PERL_CC, CFLAGS=$PERL_CCOPTS and run AC_CHECK_HEADER(perl.h,...).
We wouldn't be in this mess if Debian had just put developement stuff in the -devel package. We are in this mess because they decided to move parts to the main package. Specifically the ExtUtils::Embed module. There is some CPP related variable you would have to set too, and that would have to be created by filtering PERL_CCOPTS, I fear. We don't want to go that way. I am guessing you want to make a AC_TRY_LINK rule -- something that includes the headers we want and takes the address of (some of) the functions we want.
Fixed in cvs.