Compile errors with MOSS on MacOSX10.6 Server

[Valdez]

Hello everyone, Valdez here.

Recently I have undertaken the (tremendous) task of setting up an URU shard using MOSS -- on a Mac OS X 10.6 Server. So far, installations and such have gone rather well for the componennts that are not MOSS. The 'configure' script run of MOSS before 'make/make install' ran smoothly with no problems. I am using the latest version of MOSS on the repository as of this writing. However, upon running 'make' on the MOSS files, I immidiately ran into compile failures:

Code: Select all

make  all-am
/bin/sh ./libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.   -I/Library/PostgreSQL/8.4/include      -g -O2 -MT ConfigParser.lo -MD -MP -MF .deps/ConfigParser.Tpo -c -o ConfigParser.lo ConfigParser.cc
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I/Library/PostgreSQL/8.4/include -g -O2 -MT ConfigParser.lo -MD -MP -MF .deps/ConfigParser.Tpo -c ConfigParser.cc  -fno-common -DPIC -o .libs/ConfigParser.o
In file included from ConfigParser.cc:38:
ConfigParser.h:75: error: ‘u_int’ has not been declared
ConfigParser.h:104: error: ‘u_int’ has not been declared
ConfigParser.cc: In member function ‘int ConfigParser::read_config(const char*, bool)’:
ConfigParser.cc:124: error: ‘u_int’ was not declared in this scope
ConfigParser.cc:124: error: expected `;' before ‘bufsize’
ConfigParser.cc:129: error: ‘bufsize’ was not declared in this scope
ConfigParser.cc:131: error: ‘bufat’ was not declared in this scope
ConfigParser.cc:148: error: ‘lineno’ was not declared in this scope
ConfigParser.cc:151: error: ‘lineno’ was not declared in this scope
ConfigParser.cc:156: error: ‘lineno’ was not declared in this scope
ConfigParser.cc: At global scope:
ConfigParser.cc:280: error: variable or field ‘file_error’ declared void
ConfigParser.cc:280: error: ‘u_int’ was not declared in this scope
ConfigParser.cc:280: error: expected primary-expression before ‘int’
make[1]: *** [ConfigParser.lo] Error 1
make: *** [all] Error 2

What could be wrong here? I'm not missing any libraries or anything of the sort. Is it a problem with the OS? I would like this problem resolved as quickly as possible. I have been working hard on getting through every little thing that pops up during this adventure and I would love to see the effort materialize into a worthwhile product.

Thanks in advance,
Valdez

[cjkelly1]

Looks like u_int is not defined in Mac OSX. Not sure though, as I do not have a Mac to verify this. You can define it yourself, I think, with something like this:

Code: Select all

#ifndef u_int
#define u_int unsigned int
#endif

I do not know if there is a standard include on Mac OSX that one can add this to. Perhaps someone who is more familiar with OSX will comment.

[Valdez]

You are correct in your answer. The problem there has been solved and the files built successfully, so thank you! There was a problem with building dispatcher.cc as well, but the error vanished after running 'make -k -t'. I probably shouldn't have done that but I was looking for a way to bypass the make for that file and see if any other files after it had issues before I started trying to fix anything more. 'make install' ran fine though and reported no errors.

I've come across another issue, however. I'm trying to 'make' the moss_uuidgen.c file, but it keeps telling me it cannot find pg_config. I've tried to specify the absolute path of that file by changing its Makefile and just adding on the path (i.e. PGXS := $(shell /library/postgresql/8.4/bin/pg_config -pgxs) ). This has not worked though. Without the absolute path the make fails immediately. With the path 'make' attempts to build the file but ultimately fails while still reporting that it cannot find pg_config. I need help with this issue as well

Thanks,
Valdez

[a'moaca']

Hi,

cjkelly1's answer is sufficient, as you found (though I don't know about the disappearing dispatcher.cc problem). Apparently u_int is not defined by anything currently included by MOSS. I thought u_int was C99 and therefore in stdint.h but now I know I was wrong!

Anyway, I looked, and the configure script is checking for it. That you got no errors there implies the configure script is including whatever file defines u_int. I may just copy its rather large include stanza into machine_arch.h. Since you're past the problem, I will take the time to test out the new version on a couple OSes but I hope you'll be willing to test it for us on OSX after I get it checked in.

As for the moss_uuidgen problem: unfortunately you're actually working with the PostgreSQL build system, about which I know almost nothing. On one of my older OSes the package system did not install pg_config at all so I had similar struggles. But in your case it clearly is installed. It sounds like it's getting past the pg_config you changed, but perhaps the build process kicks off something else that tries to run pg_config. I would first try simply adding the location of pg_config to your shell's $PATH before running the make command. If that works, it ought to work with the original (unmodified) Makefile.

If it does work, please let us know, and whether the Makefile needs to be changed as well. I will then add the extra OSX instructions to the README file there.

If that does not work, I'm not as sure. On my system with pg_config not installed, I ended up putting the *output* of pg_config -pgxs in the variable. That is, if you run "/library/postgresql/8.4/bin/pg_config -pgxs" and it spits out, say, "/library/postgresql/8.4/makefiles/pgxs.mk", then put PGXS := /library/postgresql/8.4/makefiles/pgxs.mk . Obviously if something else is running pg_config this won't be sufficient. There was nothing else running pg_config in 8.3.1 but that was a while ago.

Also, there are instructions on the PostgreSQL web site for compiling modules like this yourself (not using their build system). There is a pointer in the README file, but you may want to find the equivalent for 8.4.

If none of those things work, please post the actual output and maybe we'll be able to figure out where the extra pg_config is. Maybe output of make -d if there isn't anything useful in normal output.

- a'moaca'

[Valdez]

Alright, update time!

I have gotten the module built through using the instructions on the PostgreSQL site about manually building them (which was two terminal lines, so very easy). Also got the SQL database working and created with 0 problems. PostgreSQL also has a GUI version that comes with itself for Mac OSX that allows me to set a password for moss to enable me to log in to moss without problems. It also comes with shortcuts (like desktop shortcuts) that send signals such as "Start Server," "Stop Server," "Restart Server," and "Reload Configuration!" (They work, too!) I still used console commands to create the moss DB, but this makes certain other things a breeze compared to using all console!

I got rid of the .o file for Dispatcher.cc and ran 'make' again and it tried to build it, but it threw the same exact errors as when I originally tried building this file:

Code: Select all

make  all-am
g++ -DHAVE_CONFIG_H -I.   -I/Library/PostgreSQL/8.4/include      -g -O2 -MT dispatcher.o -MD -MP -MF .deps/dispatcher.Tpo -c -o dispatcher.o dispatcher.cc
dispatcher.cc: In member function ‘bool DispatcherProcessor::test_maybe_create_dir(const char*, bool)’:
dispatcher.cc:358: error: call of overloaded ‘recursive_mkdir(const char*&, int)’ is ambiguous
util.h:137: note: candidates are: int recursive_mkdir(const char*, u_int)
dispatcher.cc:147: note:                 int recursive_mkdir(const char*, mode_t)
dispatcher.cc: In member function ‘virtual Server::reason_t Dispatcher::message_read(Server::Connection*, NetworkMessage*)’:
dispatcher.cc:1743: error: call of overloaded ‘recursive_mkdir(char [(((long unsigned int)(((int)len) - 1)) + 1u)], int)’ is ambiguous
util.h:137: note: candidates are: int recursive_mkdir(const char*, u_int)
dispatcher.cc:147: note:                 int recursive_mkdir(const char*, mode_t)
make[1]: *** [dispatcher.o] Error 1
make: *** [all] Error 2

Any fixes for this? I also already have the prefix/file, prefix/game, and prefix/auth files created and placed where they need to be. I went right ahead with making the keys with make_cyan_dh with the parameters in the tutorial, but I got no output from the terminal and no output files. I even tried running with -h and got no output. I suspect this is from the faulty build though.

I would be more than happy to test any repository changes in MOSS on Mac OSX for you! Just give me the word and I'll get right to it!

Thanks for the ongoing support,
Valdez

[a'moaca']

I pushed a change that should fix the dispatcher.cc error. Please give it a try.

However, make_cyan_dh should not be affected. I am really not sure what to make of that. I don't know what it means for it not to print anything with -h. That is really quite straightforward stuff. Is it crashing? Do things even dump core in OSX? Does it print anything if you give it a bogus option, like -q?

- a'moaca'

[Valdez]

Well, I updated my files and did a complete rebuild of everything and it all compiled fine as far as I could see. When it started linking, however, I ran into some issues:

Code: Select all

libtool: link: g++ -g -O2 -o .libs/moss dispatcher.o GatekeeperServer.o GatekeeperMessage.o -Wl,-bind_at_load  -L/Library/PostgreSQL/8.4/lib ./.libs/libmoss.0.0.0.dylib ./.libs/libmoss_serv.0.0.0.dylib -lz -lssl -lpthread -liconv
Undefined symbols:
  "_DH_up_ref", referenced from:
      Dispatcher::add_client_conn(int, unsigned char)in dispatcher.o
      Dispatcher::add_client_conn(int, unsigned char)in dispatcher.o
  "_RC4", referenced from:
      GatekeeperServer::GatekeeperConnection::make_if_enough(unsigned char const*, unsigned long, int*, bool)in GatekeeperServer.o
  "_DH_free", referenced from:
      Dispatcher::update_keydata(char const*, int)in dispatcher.o
      Dispatcher::~Dispatcher()in dispatcher.o
      Dispatcher::~Dispatcher()in dispatcher.o
      Dispatcher::~Dispatcher()in dispatcher.o
      Dispatcher::~Dispatcher()in dispatcher.o
      Dispatcher::~Dispatcher()in dispatcher.o
      Dispatcher::~Dispatcher()in dispatcher.o
      GatekeeperServer::~GatekeeperServer()in GatekeeperServer.o
      GatekeeperServer::~GatekeeperServer()in GatekeeperServer.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [moss] Error 1
make: *** [all] Error 2

Not too sure what caused this but here you go. I tried rebuilding a couple times and I kept running into this error. And no, I got no crashes or dumps from make_cyan_dh as far as I could tell. It just closes down no matter what arguments are entered (including bogus). But I do not know if it was properly built the first time around so let's not worry about that program until I get a full errorless make/make install. Then we'll see if make_cyan_dh still has problems.

Thanks,
Valdez

[a'moaca']

It's pretty clear something isn't right with OpenSSL. I'm a little confused how that could be, since you said it had all compiled once before.

Where is your openssl library installed? Is it in a location that's not in the default library search path? Is it some funky OSX special version without all the same symbols? Or is it somehow not named libssl? I would think configure found the library or we would not be trying to link those symbols. In config.log search for "OpenSSL" and see what arguments it used when checking for openssl. Are there paths there that aren't present in the command line used when the error occurred?

I suppose problems with openssl could result in make_cyan_dh bombing out, if the dynamic linker is failing to link in openssl at runtime. (make_cyan_dh does link against openssl.) Really there ought to be an error in such a case, of course.

- a'moaca'

[Valdez]

Hello again,

I right away decided to re-install OpenSSL on account of I wasn't sure if it truly compiled correctly the first time. Knowing that it did compile correctly this time however, I still got the same exact errors as the last time. I redid the configure and did a complete re-'make' of MOSS but it still did not work. Configure always tells me it has found OpenSSL but it never links. There is a folder called 'ssl' in '/usr/local' that contains some bins and libs (the lib folder contains a file called libssl.a). There are also .dylib files for Openssl installed in /usr/lib (one is called libssl.dylib). I'm pretty sure these are standard locations where they are all installed. I even tried passing "--with-openssl=/usr/local/ssl" into configure to see if that made a difference but it did not.

When I searched OpenSSL in configure.log, I did not find any filepath arguments passed that looked relevant to OpenSSL (unless I specified where OpenSSL was located using --with-openssl, of which still did not work). Actually, from what I can tell in the log file, it looks no further than the PostgreSQL folder for the libraries. Not sure if I'm reading that right but that's what I see. This is an excerpt from the config.log file of which I have put up for download (in whole) here:

Code: Select all

configure:18593: checking for OpenSSL installation
configure:18614: gcc -c -g -O2  -I/Library/PostgreSQL/8.4/include  conftest.c >&5
configure:18620: $? = 0
configure:18646: gcc -o conftest -g -O2  -I/Library/PostgreSQL/8.4/include   -L/Library/PostgreSQL/8.4/lib  conftest.c -lpthread  -lssl >&5
configure:18652: $? = 0
configure:18658: result: yes
configure:18763: checking for zlib installation
configure:18784: gcc -c -g -O2  -I/Library/PostgreSQL/8.4/include   conftest.c >&5
configure:18790: $? = 0
configure:18816: gcc -o conftest -g -O2  -I/Library/PostgreSQL/8.4/include    -L/Library/PostgreSQL/8.4/lib   conftest.c -lpthread  -lz >&5
configure:18822: $? = 0
configure:18828: result: yes
configure:18904: checking for iconv installation
configure:18924: gcc -c -g -O2  -I/Library/PostgreSQL/8.4/include    conftest.c >&5
configure:18930: $? = 0
configure:18956: gcc -o conftest -g -O2  -I/Library/PostgreSQL/8.4/include     -L/Library/PostgreSQL/8.4/lib    conftest.c -lpthread  >&5
Undefined symbols:
  "_iconv_open", referenced from:
      _main in ccwyBl7T.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
configure:18962: $? = 1
configure: failed program was:
| /* confdefs.h.  */

Are the files needed not installed? Is libssl the only library required for linking into MOSS? I'm not sure if it is a special OSX version. I do not see how it would be as I did not download a "Made for Mac OS X" version. I just downloaded the latest source from their site and built it. I also tried putting libssl.dylib and libssl.a into ./.libs in MOSS to see if they would magically work (you never know , though I'm not actually sure if a .a file is a library), but it still failed to link.

Valdez

[Christian Walther]

OpenSSL comes with Mac OS X, in /usr, and that’s the one that’s being found by configure according to your log.

It looks like the problem is that the missing symbols are not in libssl, but in libcrypto.

Try this (untested):

Code: Select all

diff -r e87acb3b567b aclocal/openssl.m4
--- a/aclocal/openssl.m4	Wed Jul 20 20:53:52 2011 -0700
+++ b/aclocal/openssl.m4	Fri Jul 22 10:28:09 2011 +0200
@@ -49,7 +49,7 @@
 		CPPFLAGS="$CPPFLAGS -I$moss_openssl_path/include"
 		LDFLAGS="$LDFLAGS -L$moss_openssl_path/lib"
 	fi
-	LIBS="$LIBS -lssl"
+	LIBS="$LIBS -lssl -lcrypto"
 	AC_COMPILE_IFELSE([AC_LANG_SOURCE([[#include <openssl/ssl.h>]])],
 	  [AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include <openssl/ssl.h>]],
 		[[SSL_new(NULL)]])],
diff -r e87acb3b567b configure.ac
--- a/configure.ac	Wed Jul 20 20:53:52 2011 -0700
+++ b/configure.ac	Fri Jul 22 10:28:09 2011 +0200
@@ -165,7 +165,7 @@
 	CPPFLAGS="$CPPFLAGS $moss_openssl_CPPFLAGS"
 	LDFLAGS="$LDFLAGS $moss_openssl_LDFLAGS"
 	AC_DEFINE(HAVE_OPENSSL,1,[Define to 1 to use OpenSSL functionality])
-	AC_SUBST(ssl_libs,"-lssl")
+	AC_SUBST(ssl_libs,"-lssl -lcrypto")
 fi
 
 MOSS_ZLIB