Re: [B2-devel] BasiliskII compilation issues

[Giulio P. <giu...@gm...>]

On 12/06/2012 02:01, Robert Munafo wrote:
> Hello Giulio,
> 
> On 6/11/12, Giulio Paci <giu...@gm...> wrote:
>> On 10/06/2012 06:59, Robert Munafo wrote:
>>> You might have noticed that mysignal is part of a small C program used
>>> as a test during the autoconf process.  [...]
>>
>> Actually I did not notice it. How is it related mysignal being part of a
>> test in configure and the error I am seeing?
> 
> They both use the same name. This means that they might have both been
> put in by the same programmer. If there is a history of old versions
> of BasiliskII source code, then we could find out when the mysignal
> got added to autoconf, and perhaps that will give a clue as to who
> added it and maybe the other mysignal was added at the same time.

In autoconf files they were there since the first CVS commit, but I do
not know how this can help.

>>> What happens if you disable the "#define HAVE_DEV_PTMX 1" as Andreas
>>> Wiese suggested?
>>
>> I am in the same situation as Andreas: if I
>> 1) undefine HAVE_DEV_PTMX and
>> 2) include signal.h
>> I can complete the compilation. (Although I am not able to test the
>> resulting binary at the moment, because on the virtual machine I set up
>> for testing, the X server is not able to start).
>>
>> My goal is to have the compilation working without manual intervention
>> on as many Debian supported architectures as possible, so: I can accept
>> the point 2 above (as it is working in the general case), but I cannot
>> accept the point 1 (because I do not understand what I am tweaking and
>> why. Moreover the change is probably affecting other architectures).
> 
> I suggest that you add the change in the same way that one normally
> makes such changes in Debian.
> 
> This is probably done with the config files. Note that "HAVE_DEV_PTMX"
> appears in:
> 
>   Unix/config.h.in
>   Unix/configure
>   Unix/configure.ac

Yes, the two usual fixes are either 1) temporary patch the building
system or 2) wait for an upstream patched release.

> I do not know how these files work, but I do remember that one or more
> of them is created based on one of the others, and I'm pretty sure
> this happens in the "autogen.sh" or "configure" step of the build
> process.

config.h.in is normally generated by autoheader, configure.ac is usually
the manually edited main source and configure is automatically generated
by autoconf and is responsible to convert .in files into the final file
(e.g., to create config.h from config.h.in).

> Whichever one is the "original" configure file, needs to be edited so
> that it tests for Debian and disables the define of HAVE_DEV_PTMX if
> the Debian test is true.

The problem is that 1) I do not understand what to check for and 2) I do
not understand the implication of undefining HAVE_DEV_PTMX.

It is not a matter to detect Debian, as the building procedure is
already working on many Debian architectures. It is a matter of
detecting freebsd kernel in a Debian OS, but why? What features is
missing? As the same problem appeared long time ago in NetBSD and other
*BSD, is it related to FreeBSD?

> Once you determine the best way to change the right config file, then
> report the details back to this list. There are people on this list
> who can update the source code server to reflect the bug fix, once
> they are told what needs to be changed.

Once I will determine it I will do it for sure, but I do not think I
have the knowledge to determine it on my own.

Bests,
	Giulio.