Re: [B2-devel] BasiliskII compilation issues

[Alexei S. <ale...@gm...>]

I've now landed a change that does that and also includes <signal.h>. Let
me know if it works for you now or if there are still issues.

-Alexei

On Fri, Jun 15, 2012 at 5:46 PM, Alexei Svitkine
<ale...@gm...>wrote:

> Does it work if you replace "mysig_t" with "sig_t" and "mysignal" with
> "signal"?
>
>
> On Fri, Jun 15, 2012 at 12:54 PM, Giulio Paci <giu...@gm...>wrote:
>
>> 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.
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>
>