Date: Tue, 12 Feb 2002 13:06:19 -0500
From: David Allen <mda@idatar.com>
To: gopher@complete.org
Subject: [gopher] UMN Gopher on Mac OSX
Message-ID: <20020212130619.A9369@mothra.dyndns.org>
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Content-Transfer-Encoding: 8bit
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
Precedence: bulk
Reply-to: gopher@complete.org


I've been reading the posts about gopher not compiling on Mac OS X,
and since I have a machine around, I figured I'd give it a go.

So far, I've pretty much got everything compiled, including the
gopherd and object directories, and the compile is just bombing on
linking the gopher client, which fails to link with the errors that it
can't find the symbols _re_comp and _re_exec - looking for how to fix
that, it's probably going to be just another -l flag, but I'm not sure
which one.  :)

OK, so here's the main problem, which anybody familiar with C isn't
going to believe.  :)  The "regex.h too deeply nested" error that
someone was getting earlier was due to the fact that, (and *please*
don't ask me why this is) the compiler doesn't seem to respect case
differences in filenames.  When you include object/Regex.h using this:

#include "Regex.h"    (Supported by a -I../object parameter)

the compiler is unable to distinguish between that, and 

#include <regex.h>

The reason for the "deeply nested" error is because you're including
<regex.h> inside of Regex.h, and it looks like the file is referring
to itself.  (Well, at least to horribly braindead compilers it looks
that way.  :)  I didn't believe that this was actually the problem,
but here's how I fixed it:  rename object/Regex.h to
object/Gopher-Regex.h and it won't give you that error (after
substituting 
#include "Gopher-Regex.h"
for
#include "Regex.h")

Do the same with object/Dirent.h, object/Malloc.h, replace all of the
#include directives that reference the old filenames, and you get to
where I've gotten.  (These files have the same problem since Dirent.h
is really just a fancy wrapper for /usr/include/dirent.h)  Also, you
have to remove references from many header files in the object
directory to the <malloc.h> file, since it doesn't exist on this
platform (malloc() is in unistd.h and maybe stdlib.h I forget which)

Do all of these things, and you will get to the linker error that I'm
at.

John - would you be open to maybe allowing this file renaming thing to
go into the CVS tree?  I know that most people don't bother to bend
over backwards to support horribly broken compilers, but maybe we
could change the names?  Something like:

s/(Regex|Malloc|String|Dirent|Sockets|Stdlib|Locale).h/$1-Wrapper.h/;

That would make clear the function of the header file, and solve this
problem at the same time.  Also a few #ifdef's around the #include
<malloc.h>'s would help, either that or make configure brighter.

As for the compiler, what really bugs me is the fact that it's based
on gcc, and I've *never* seen gcc do anything like this.

[mda@main object]$ cc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/2.95.2/specs
Apple Computer, Inc. version gcc-932.1, based on gcc version 2.95.2
19991024 (release)
[mda@main object]$ uname -a
Darwin main 5.2 Darwin Kernel Version 5.2: Fri Dec  7 21:39:35 PST
2001; root:xnu/xnu-201.14.obj~1/RELEASE_PPC  Power Macintosh unknown

Of course not that Mac OS X doesn't have bugs...(I'm running OS X
server 10.1.2) check this out - (I rebooted the machine yesterday)

[mda@main object]$ uptime
 1:08PM  up 11730 days, 18:09, 1 user, load averages: 0.08, 0.00, 0.00

-- 
David Allen
http://opop.nols.com/
----------------------------------------
The Force.  It surrounds us;  It enfolds us;  It gets us dates on Saturday 
Nights. 
	- Obi Wan Kenobi, Famous Jedi Knight and Party Animal.