slgtk fails to build with gtk 2.18

[Jörg Sommer]

Hi Michael,

Michael Noble hat am Sat 20. Feb, 10:12 (-0500) geschrieben:
> Thank you for contacting me.  I apologize for not responding
> sooner, but have been in bed for several days with a fever
> and strep throat.

No problem.

> I've posted a tarball of SLgtk 0.7.6 to the FTP area at
> 
>    ftp://space.mit.edu/pub/cxc/modules/slgtk/slgtk-0.7.6.tar.gz
> 
> web site, but have been holding off announcing it until more
> testing could be done by collaborators.

I found the following problems with this release and have questions:

• % ./configure --help >/dev/null
  tail: cannot open `config.out' for reading: No such file or directory

• You should update the config.guess and config.sub files. They are out
  of date and do not support architectures like SH. A similar bug is in
  SLIRP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554352

• Running configure with CFLAGS having more than one option doesn't
  creates a Makefile in gif, but configure returns successfully.

  % CFLAGS=-Wall\ -O2 ./configure

  Check config.out for results, or use ./configure --help for more info

  Found S-Lang shell slsh at /usr, using as default --prefix

  Configuring S-Lang Gtk module with:

      --with-slang=/usr --prefix=/usr

  configure.real: error: unrecognized option: -O2
  Try `./configure.real --help' for more information.

  Configuration complete.  You may need to edit the generated Makefile.
  You are compiling SLgtk with the following configuration:

  …
  % echo $?
  0
  % ls gif/Makefile*
  gif/Makefile.in

  It looks like a passing of CFLAGS down to another configure script is
  not cleanly quoted, i.e. not CFLAGS="$CFLAGS".

  And it seems the return value of this inner call is thrown away.

• make distclean in the top level directory doesn't cleanup the
  subdirectory gif.

• As you are the author of SLIRP, too, I've a question: The first
  sentence of the manual page of slirpsh read as follows “This program
  should not be explicitly invoked by users.” This indicates slirpsh
  should not be put in /usr/bin. But slirp should be there to make it
  usable. The test for slirp in admin/aclocal.m4 at --with-slirp assumes
  bothes commands live in the same directory, which forces slirpsh must
  be installed in /usr/bin. Is this good?

  The test also assumes the binary is named slirp. But in Debian this
  name is already used by another package. Hence, I never can't use this
  external SLIRP. Can you modify the test to use the name passed with the
  configure argument?

  And, but this has nothing to do with slgtk, what's special to slirpsh?
  Why it's not slsh with special aguments? From the point of view of
  reusing code, it would be better to use the original slsh.

• Do you use a VCS like git or SVN? Is it public?

Bye, Jörg.
-- 
UNIX is user friendly, it's just picky about who its friends are
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature http://en.wikipedia.org/wiki/OpenPGP
URL: <http://lists.alioth.debian.org/pipermail/pkg-jed-sl-modules/attachments/20100222/a0747ce2/attachment.pgp>