SGI: Development

beta : neko_dia-0.97

urchin 1% dia wrote:

15148:dia: rld: Fatal Error: Cannot Successfully map soname 'libgnomeui-2.so.1' under any of the filenames /usr/nekoware/lib/libgnomeui-2.so.1:/pango-1.9.1/pango/.libs/libgnomeui-2.so.1:
/usr/lib32/libgnomeui-2.so.1:/usr/nekoware//lib/libgnomeui-2.so.1:
/opt/build/pango-1.12.4/pango/.libs/libgnomeui-2.so.1:/usr/nekoware/lib/dia/libgnomeui-2.so.1:
/usr/lib32/internal/libgnomeui-2.so.1:/lib32/libgnomeui-2.so.1:/opt/lib32/libgnomeui-2.so.1:
/usr/nekoware/lib/libgnomeui-2.so.1.1:/pango-1.9.1/pango/.libs/libgnomeui-2.so.1.1:
/usr/lib32/libgnomeui-2.so.1.1:/usr/nekoware//lib/libgnomeui-2.so.1.1:
/opt/build/pango-1.12.4/pango/.libs/libgnomeui-2.so.1.1:/usr/nekoware/lib/dia/libgnomeui-2.so.1.1:
/usr/lib32/internal/libgnomeui-2.so.1.1:/lib32/libgnomeui-2.so.1.1:/opt/lib32/libgnomeui-2.so.1.1:

Oops :D
neko_dia specifies no dependencies, however, they should look approximately like this:
Code:
neko_atk.sw.lib 5 maxint
neko_bzip2.sw.lib 5 maxint
neko_cairo.sw.lib 5 maxint
neko_esound.sw.lib 1 maxint
neko_expat.sw.lib 6 maxint
neko_fontconfig.sw.lib 4 maxint
neko_freetype2.sw.lib 13 maxint
neko_gconf.sw.lib 4 maxint
neko_gettext.sw.lib 9 maxint
neko_glib.sw.lib 10 maxint
neko_glitz.sw.lib 2 maxint
neko_gnomekeyring.sw.lib 2 maxint
neko_gnomevfs.sw.lib 2 maxint
neko_gtk.sw.lib 8 maxint
neko_libart.sw.lib 2 maxint
neko_libaudiofile.sw.lib 1 maxint
neko_libbonobo.sw.lib 4 maxint
neko_libgnomecanvas.sw.lib 3 maxint
neko_libgnomeui.sw.lib 2 maxint
neko_libgnome.sw.lib 2 maxint
neko_libiconv.sw.lib 4 maxint
neko_libjpeg.sw.lib 6 maxint
neko_libpixman.sw.lib 2 maxint
neko_libpng.sw.lib 10 maxint
neko_libxft.sw.lib 2 maxint
neko_libxml2.sw.lib 7 maxint
neko_libxrender.sw.lib 2 maxint
neko_openssl.sw.lib 22 maxint
neko_orbit2.sw.lib 3 maxint
neko_pango.sw.lib 13 maxint
neko_pixman.sw.lib 1 maxint
neko_popt.sw.lib 2 maxint
neko_zlib.sw.lib 6 maxint
It also has python bindings that should be in a separate subsystem and should depend on neko_dia.sw.eoe as well as neko_pygtk.

I'd update dia, but then I'd have to build pygtk for the python 2.7.3 that has found its way into /current by now. That needs a newer pygobject (a not current anymore version of which is bundled in neko_pygtk for unknown reasons), which again requires a new glib, which requires libffi (would be in /incoming by now, but the ftp server says "I'm sorry anonymous, I'm afraid I can't do that."), and the new glib requires constructor and destructor support. I have no Idea how that's supposed to work with c99. At least fec_360 seems to have constructor support, and I can use that with -Zf,_360, but it still just produces errors.
Code:
$ strings /usr/lib32/cmplrs/fec_360  |grep __attr |grep const
__attribute__ ((constructor)) specified for %s

Code:
$ c99 -Zf,_360 -c constructor.c  -o constructor.o
cc-1079 c99: ERROR File = constructor.c, Line = 2
A type specifier is expected.

static void __attribute__((constructor)) glib_init_ctor (void);
^

cc-1137 c99: ERROR File = constructor.c, Line = 2
Unnamed prototyped parameters not allowed when body is present.

static void __attribute__((constructor)) glib_init_ctor (void);
^

cc-1129 c99: ERROR File = constructor.c, Line = 2
A left brace ("{") is expected at this point.

static void __attribute__((constructor)) glib_init_ctor (void);
^

cc-1012 c99: WARNING File = constructor.c, Line = 7
Parsing restarts here after previous syntax error.

{
^

cc-1196 c99: WARNING File = constructor.c, Line = 8
The indicated function is declared implicitly.

glib_init ();
^

unable to proceed because of earlier errors
3 errors detected in the compilation of "constructor.c".
$ cat constructor.c
static void __attribute__((constructor)) glib_init_ctor (void);

static void
glib_init_ctor (void)
{
glib_init ();
}
If anyone wants to update the dia package, below are file type rules and icons for dia and .dia files.
I would suggest, in view of the huge amount of problems with this tardist, that it be put into the round file ? That could save some unsuspecting passerby from wasting his time installing this. It would be just as easy for someone in the future to start from scratch.
canavan wrote:
(would be in /incoming by now, but the ftp server says "I'm sorry anonymous, I'm afraid I can't do that.")


Let me know when it does that so I can restart FTP. If you just sit on it and hope it magically corrects itself it may stay that way a long while (until I eventually stumble on it myself, who knows when).

_________________
Twitter: @neko_no_ko
IRIX Release 4.0.5 IP12 Version 06151813 System V
Copyright 1987-1992 Silicon Graphics, Inc.
All Rights Reserved.
anon ftp is working now, neko_libffi-3.0.11.tardist is in /incoming. Will contact you the next time I stumble upon this or similar problems.