Menu
▾
▴
Re: [B2-devel] BasiliskII compilation issues
|
From: Giulio P. <giu...@gm...> - 2012-06-16 18:47:26
|
Il 15/06/2012 23:57, Alexei Svitkine ha scritto: > 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. It is still not working: sshpty.c:187:20 error: `I_PUSH' undeclared (first use in this function) I also have two warnings about "sig" and "strlcpy" implicit declaration. The first one is due to a wrong definition of mysignal. I do not know why I see the strlcpy warning (In config.h HAVE_STRLCPY has been defined to 1). Giulio. > On Fri, Jun 15, 2012 at 5:46 PM, Alexei Svitkine > <ale...@gm... <mailto: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... > <mailto:giu...@gm...>> wrote: > > On 12/06/2012 02:01, Robert Munafo wrote: > > Hello Giulio, > > > > On 6/11/12, Giulio Paci <giu...@gm... > <mailto: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 <http://config.h.in> > > Unix/configure > > Unix/configure.ac <http://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 <http://config.h.in> is normally generated by > autoheader, configure.ac <http://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 <http://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... > <mailto:bas...@li...> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > > > > > ------------------------------------------------------------------------------ > 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 |
