Compilation update
mark carter <[email protected]> Fri, 24 Mar 2017 11:21:37 +0000
| Newsgroups | gmane.comp.gnu.oleo.bugs |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------A766542A3EDA7E3089B4F4E5
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Marcin,
As you point out, neoleo is hosted at
https://github.com/blippy/neoleo
rather than on gnu.
I have taken a look at your CVS repo, done some hacking, and I have been
able to compile oleo! It runs! I do not have things in a suitable form
for a patch, but here is an overview of the results of my investigations
so far:
*src/Markefile.am:8 Need to get rid of `../lib/ansi2knr'*
Googling around, this seems to way to convert ANSI C definitions to K&R
(Kernighan and Ritchie "traditional C"). I'm happy to drop that, as
nobody should be using such an antiquated compiler
*doc/*texi compilation fails**
*The fixes for these are pretty trivial and non-controversial.
*libxp*
autoreconf has a problem with LT_HAVE_LIBXP. I have commented it out for
now, and was able to obtain a build. However, the root cause appears to
be "underquoting" in m4/xp.m4. My knowledge `m4' is practically
non-existent, but I will take a look to see if I can fix whatever seems
to be the problem.
So, in summary, it should be too difficult to get oleo working again.
I'm not sure if you are aware, but there is apparently a patch for oleo
here:
https://launchpadlibrarian.net/19062178/oleo_1.99.16-11.diff.gz
It seems to patch the tar distribution: `configuration' in particular.
So although it's not exactly what we want, it's worth noting its existence.
On Arch Linux, there seems to be a recent attempt at building oleo:
https://aur.archlinux.org/packages/oleo/
I had only just noticed it, so I don't know what the status of it is. I
know that there were build problems in the past. I might liaise with the
package maintainer to see what's going on.
--------------A766542A3EDA7E3089B4F4E5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Marcin,</p>
As you point out, neoleo is hosted at<br>
<a rel="nofollow" href="https://github.com/blippy/neoleo">https://github.com/blippy/neoleo</a><br>
rather than on gnu.<br>
<br>
I have taken a look at your CVS repo, done some hacking, and I have
been able to compile oleo! It runs! I do not have things in a
suitable form for a patch, but here is an overview of the results of
my investigations so far:<br>
<br>
<b>src/Markefile.am:8 Need to get rid of `../lib/ansi2knr'</b> <br>
Googling around, this seems to way to convert ANSI C definitions to
K&R (Kernighan and Ritchie "traditional C"). I'm happy to drop
that, as nobody should be using such an antiquated compiler<br>
<br>
<b>doc/*texi compilation fails</b><b><br>
</b>The fixes for these are pretty trivial and non-controversial.<br>
<br>
<b>libxp</b><br>
autoreconf has a problem with LT_HAVE_LIBXP. I have commented it out
for now, and was able to obtain a build. However, the root cause
appears to be "underquoting" in m4/xp.m4. My knowledge `m4' is
practically non-existent, but I will take a look to see if I can fix
whatever seems to be the problem.<br>
<br>
So, in summary, it should be too difficult to get oleo working
again. I'm not sure if you are aware, but there is apparently a
patch for oleo here:<br>
<a class="moz-txt-link-freetext" href="https://launchpadlibrarian.net/19062178/oleo_1.99.16-11.diff.gz">https://launchpadlibrarian.net/19062178/oleo_1.99.16-11.diff.gz</a><br>
It seems to patch the tar distribution: `configuration' in
particular. So although it's not exactly what we want, it's worth
noting its existence.<br>
<br>
On Arch Linux, there seems to be a recent attempt at building oleo:<br>
<a class="moz-txt-link-freetext" href="https://aur.archlinux.org/packages/oleo/">https://aur.archlinux.org/packages/oleo/</a><br>
I had only just noticed it, so I don't know what the status of it
is. I know that there were build problems in the past. I might
liaise with the package maintainer to see what's going on.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>
--------------A766542A3EDA7E3089B4F4E5--