Subject: Re: GIMP on MacOS X 10.1.5 fails...
To: Julio M. Merino Vidal <jmmv@menta.net>
From: John D. Baker <jdbaker@mylinuxisp.com>
List: tech-pkg
Date: 03/21/2004 20:05:57
On Mon, 15 Mar 2004, Julio M. Merino Vidal wrote:

> "John D. Baker" <jdbaker@mylinuxisp.com> wrote:
>
>> After much effort and working around problems (most of which were
>> documented here in tech-pkg), I finally built and installed a complete
>> graphics/gimp.
>>
>> Any hints?  (Upgrading the hardware is not an option a this time.
>> Perhaps others are also needing to run an older rev of the OS but
>> still want to build software from pkgsrc?)
>
> Not a fix, but you may try with gimp2.  Install x11/gtk2, run the gtk-demo
> program to ensure it works, then download a copy of pkgsrc-wip (see
> instructions in http://pkgsrc-wip.sf.net/) and install gimp-current from it.

I've been pursuing this suggestion--it's taken all week to crunch through
the dependencies--but still no joy.

I first tried gtk2-devel from pksrc-wip, but some dependency (pango
1.4.0, I think) failed to link, complaining about some undefined symbol,
so I backed off and built x11/gtk2 in the main pkgsrc tree.

All the dependencies leading to a complete x11/gtk2 built and installed
without a hitch.  The gtk-demo program worked splendidly, so I then
turned my attention to wip/gimp-current, and have been clawing my way
through the dependencies.  Along the way, I found the following problems
with packages in the main pkgsrc tree:

net/libIDL complains that '/usr/pkg/bin/bison -y' is not usable as yacc.
Workaround:  define "HAVE_YACC=yes" on the build command line, e.g.,
"bmake HAVE_YACC=yes install".

net/ORBit2 fails to build complaining about an undeclared variable in one
of the "linc-xxxx.c" files.  Seems this is a known issue when building
ORBit2 on MacOS X, but it is not yet accounted for in the pkgsrc patches
for this package.
Workaround:  edit /net/ORBit2/work/$distname/linc2/src/Makefile and add
"-DMAC_OS_X_IS_SO_BROKEN" to LINC_LOCAL_CFLAGS.  (I didn't know how to
make this happen automatically during the configuration phase.)  This
turns on code in the affected files to resolve the problem.

sysutils/fam fails to compile because

    sysutils/fam/work/$distname/fam/IMon.c++
    sysutils/fam/work/$distname/fam/Interest.c++

each attempt to include <sys/sysmacros.h>, which doesn't exist on MacOS
X.  Looking at the files, the problem #include directive is preceded by
a conditional which prevents the inclusion if it detects that the system
is one of the *BSDs.
Workaround:  Figuring this should apply to MacOS X as well and not
knowing what symbol to test for, I simply commented out the the whole
block (it's an isolated conditional in each file).

But sysutil/fam is being more of a pain.  Restarting the build got past
the problems mentioned above, only to come to a dead stop with the
following:

[...]
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../include -DCONFIG_ETC_CONFIG_PATH=\"/usr/pkg/etc/fam.conf\"  -no-cpp-precomp  -O2 -c -o Listener.o `test -f 'Listener.c++' || echo './'`Listener.c++
In file included from RequestMap.h:26,
                 from MxClient.h:27,
                 from TCP_Client.h:27,
                 from LocalClient.h:26,
                 from Listener.c++:46:
../include/BTree.h:241: warning: `typename BTree<Key, Value>::Closure' is
   implicitly a typename
../include/BTree.h:241: warning: implicit typename is deprecated, please see
   the documentation for details
../include/BTree.h:353: warning: `typename BTree<Key, Value>::Closure' is
   implicitly a typename
../include/BTree.h:353: warning: implicit typename is deprecated, please see
   the documentation for details
../include/BTree.h:409: warning: `typename BTree<Key, Value>::Closure' is
   implicitly a typename
../include/BTree.h:409: warning: implicit typename is deprecated, please see
   the documentation for details
../include/BTree.h:504: warning: `typename BTree<Key, Value>::Status' is
   implicitly a typename
../include/BTree.h:504: warning: implicit typename is deprecated, please see
   the documentation for details
../include/BTree.h:562: warning: `typename BTree<Key, Value>::Closure' is
   implicitly a typename
../include/BTree.h:562: warning: implicit typename is deprecated, please see
   the documentation for details
../include/BTree.h:592: warning: `typename BTree<Key, Value>::Status' is
   implicitly a typename
../include/BTree.h:592: warning: implicit typename is deprecated, please see
   the documentation for details
Listener.c++: In static member function `static void
   Listener::create_local_client(TCP_Client&, unsigned int)':
Listener.c++:215: warning: invalid conversion from `const char*' to `unsigned
   char'
Listener.c++: In static member function `static void
   Listener::accept_localclient(int, void*)':
Listener.c++:289: warning: invalid conversion from `const char*' to `unsigned
   char'
Listener.c++: In member function `void Listener::dirty_ugly_hack()':
Listener.c++:355: warning: invalid conversion from `const char*' to `unsigned
   char'
/var/tmp//cclFYkYU.s:unknown:Fixup of 8740 too large for field width of 1
gnumake[2]: *** [Listener.o] Error 1
gnumake[1]: *** [all-recursive] Error 1
gnumake: *** [all] Error 2
*** Error code 2

Stop.
bmake: stopped in /usr/pkgsrc/sysutils/fam
[...]

There appears to be a problem with the intermediate assembly step.  I
don't know if it's a compiler/assembler problem, or wonky source code
causing the problem.

So far, I'm zero-for-two at getting a working GIMP on MacOS X 10.1.5.
Again, the system is:

    PowerMac 7500 w/MPC604e, 180MHz, 1GB RAM, MacOS X 10.1.5 (via
    XPostFacto).  pkgsrc, pkgsrc-wip last updated a few hours before
    this message was sent.

I'm gearing up to compare results on a machine running 10.2.8, although
I know I can build a working GIMP 1.2.5 on such systems...

Thanks.

-- 
John D. Baker, KN5UKS                    NetBSD     Darwin/MacOS X
jdbaker(at)mylinuxisp(dot)com                 OpenBSD            FreeBSD
BSD -- It just sits there and _works_!