Re: pkg/52173 (C compilations can't find header files, sometimes CWRAPPERS_CONFIG_DIR is not found)

[Lucio De Re <lucio.dere%gmail.com@localhost>]

The following reply was made to PR pkg/52173; it has been noted by GNATS.

From: Lucio De Re <lucio.dere%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/52173 (C compilations can't find header files, sometimes
 CWRAPPERS_CONFIG_DIR is not found)
Date: Mon, 17 Apr 2017 19:44:35 +0200

 Thanks, Benny. I'll investigate the possibility of omitting the
 mk.conf file, but keep in mind that it works very effectively (but I'd
 like to improve that aspect) for a suite of utilities that one may
 want built as a group. The file I use is 1956 lines long, adopted
 verbatim from the pkgsrc directory mk/defaults/mk.conf and, as I
 mentioned, faulty in the way it queries ${OPSYS} when it is not set.
 It ought to be the responsibility of the pkgsrc team to ensure that
 the example does not hide some serious flaw in it and I'll be very
 happy to assist addressing this, if I may.
 
 Also, it is sometimes difficult to explain oneself properly, let me
 try to clarify the way the problem presents itself: During compilation
 of lang/php56, the '#include "php.h"' directive fails (possibly for a
 single module, but one can't tell), claiming it cannot find "php.h".
 The same, oddly, occurs in lang/php71. Now, in both cases, the
 displayed command line shows quite clearly that the -I... option
 needed to ensure that "php.h" is found is present. I can't recall the
 specific directory, but (a) I tracked it down and (b) I executed the
 command as displayed and it completed successfully. That is where I
 then proceeded to "make" in the object directory and, in that specific
 instance, the make and also "make install" worked fine.
 
 In other cases, of which devel/glib2 was the most insistent, the
 problem presented itself as a cwrappers failure. The only thing these
 have in common is the use of memory to hold in one case the command
 line arguments and in the other the environment variable. That, of
 course, is only a guess on my part and now that I think about it, the
 other common factor is that these are elements in the use of libtool
 or cwrappers (even more guess work on my part, now).
 
 So, what I am looking for is a weak spot around the propagation of
 these values from a parent process to its child, one where single
 values are dropped, even though it is also possible that these values
 are not dropped, but truncated. Somebody who is familiar with libtool
 and/or cwrapper is more likely to relate my indication to the real
 circumstances.
 
 I can certainly replicate them and will gladly collect some logging
 information. There was another odd error that I seem to recall as
 relevant, and that was a configure failure: it seems that
 USE_LANGUAGES did not include "c" at the time of execution of the
 configure script (as reported in the config.log file). Adding "c" as a
 value in the Makefile for the package made that go away. It again
 serves to suggest that there is some data loss of corruption
 involving, I would propose, environment variables, which in turn may
 be used to assigne values - possibly unsuccessfully -  to command line
 arguments. The size of the mk.conf file may in this case be relevant.
 Do you happen to know whether stripping it of comment lines would have
 some diagnostic value?
 
 Lucio.
 
 PS: You can find me on skype as "luciodere", if some interaction could
 be helpful.