Notag

When the upstream netrek-server code base imported my cmake build patch it renewed my interest in working on this project.

Couple problems I need to work on.

Biggest issue, I forgot to create a “make install” target.

Starting my collection of cmake links. I’ll post them below:

http://www.cmake.org/
http://www.linuxjournal.com/article/6700
http://www.lcfg.org/doc/buildtools/cmake_recipes.html

I had an epic failure and did not darcs add the cmake build files. “Worse” James’ osx merge branch is based of trunk and had all the deprecations of PING, RCD, RSA, so I had to spend some time merging branches.

I just issued a ‘darcs send’ to Quozl for the osx port (actually, I think I sent it to him 2 times, darcs newbie, sorry!)

The port wasn’t hard, mostly fixed up the macros and conditional compile directives. In the end the code changes aren’t very intrusive. I do not expect the code changes to be rejected after Quozl reviews them.

On the other hand, I totally gutted the build system and started from ground zero with cmake. This change might be controversial and I don’t expect Quozl to patch upstream right away, even with a code review.

In fact, the patch breaks the old autotool build! The the old autotools will not compile Vanilla anymore unless someone goes back to the configure.in and strips out all of the include-files-as-macros-hackery that it does.

Going to repeat the above.

NOTE:: The osx/cmake patch BREAKS building with autotools!

Why?

First the selfish reasons.

The autotools are a pita under osx. They pollute the system, seem to need constant tweaking, and generally not Mac-friendly.

Next, what version of autotools? autoconf-2.63 or autoconf-2.13? automake1.4, automake1.7, automake1.8, or automake1.9? All? Some? Just ick! And we all hate m4, right?
Now the techincal (non-selfish) reasons.

With cmake, you just need one tool; cmake. The 3 platforms we really care about are official supported (as well as others).

There’s plenty of “cmake FTW!” in Google. Good read is why KDE moved to cmake.

What I’m most excited about are cmake generators. In short, the ability to generate native build “instructions”. Like Makefiles for Linux, cygwin, even MinGW. NMake for Vistual C++. Xcode project files of osx.

For specific info look here.

And goodies, like CPack, for building software for your specific platform.

For specific info look here.

I’ll work with Quozl and the community to iron out all the rough spots. I am willing to do the work it takes to get cmake adopted as the build tool for the netrek-server.

If that doesn’t work, at least have cmake along side the autotools as a choice of build tool (cmake can co-exist with the autotools since it does out-of-source building (more in another post)).

I’ll continue to maintain the osx-branch of netrek-server until either of the 2 above situations present themselves.

For specific info on the osx-netrek-branch look here.

Oh, how things have changed. First netrek clients do not need to be blessed to work on the majority (all?) servers.

Now, it looks like res-rsa has had it’s license change so it can be exported outside the US!

I’m only 9 years late!

Port of the code was easy. Just couple header inclusions. I love cmake!

Working with res-rsa’s maintainer to get my changes merged into upstream.

I’ve gotten netrek-server 2.15 ported to osx. It compiles clean, I even cleaned up the warnings.

I’m building everything in ntserv, newstartd, robots, robotd, tools, sequencer, keycomp, xsg, and pledit.

I was informed gum is no longer maintained? (if so, remove it from darcs?)

I prefer to work in bzr and would like to continue working there until we know that the osx code is stable and ready for merge back into upsteam/darcs.

The branch is hosted on launchpad: bzr branch lp:~tanner/netrek-server/osx-branch
Web view: https://code.launchpad.net/~tanner/netrek-server/osx-branch

I did alot of clean-up as I went.

#ifdef and macros for platforms and operating systems from the ancient past I refactored and just put in the equivalent (generally speaking) POSIX API calls. Example sun3? sun4? sequent? bzero vs memset? string.h vs strings.h?

What I would like to do is open a launchpad bug for each major “drop” of an old platform and allow the developers to discuss it.

I also removed most (all?) of the deprecated APIs, as hinted above, memcmp vs bcmp, memcpy vs bcopy, memset vs bzero. Like above, I’ll open a LP bugs and let the developers discuss.

Other clean ups:

* SYSV signals vs BSD signals
* Header file inclusions unistd.h? strings.h? stdlib.h? fctl.h?
* strcpy, strncpy, string stuff in general
* random, srandom vs rrandom,ssrandom
* usleep vs micosleep

Everyone think using LP bugs to discuss the changes is a good methodology for tracking all of this?

I purposely left out how to build the branch, the tools I used, and what not, as I did not start on a pristine osx install. I’m am currently working on documenting everything and will put something on the wiki when I think I have something that won’t cause more problems then it solves.

Right now, I’m just looking to start the discussion, let developers use tools they know (vim, emacs, etc) and give me a code review.

(more…)

Ran into another issue with my netrek-server move to cmake.

Attempting to link with an internal library gives me a whole bunch of
“non_lazy_ptr” linking errors:

Linking C executable trimscores
Undefined symbols:
“_Cambot_out”, referenced from:
_Cambot_out$non_lazy_ptr in libnetrek.a(getpath.o)
“_NoCount_File”, referenced from:
_NoCount_File$non_lazy_ptr in libnetrek.a(getpath.o)
“_Global”, referenced from:
_Global$non_lazy_ptr in libnetrek.a(getpath.o)

Spent alot of time poking around google until I found this url:

http://software.intel.com/en-us/articles/intelr-fortran-compiler-for-mac-os-non_lazy_ptr-unresolved-references-from-linking/

Summary

of the above url says that when you “ranlib” you really should “ranlib
-c” and makes reference to the libtool manpage (more on this later).

If I ‘ranlib -c ntserv/libnetrek.a’ and make

$ make

Linking C executable trimscores
[ 98%] Built target trimscores

Things work.

First question, how to I add “-c” to ranlib evocation?

I build libnetrek via the ADD_LIBRARY as noted below:

ADD_LIBRARY (netrek STATIC
advertise.c
alarm.c

warning.c
)

Which generates this command line:

/usr/bin/ar cr libnetrek.a CMakeFiles/netrek.dir/advertise.o
CMakeFiles/netrek.
dir/alarm.o CMakeFiles/netrek.dir/warning.o
/usr/bin/ranlib libnetrek.a

My gut tells me to change CMAKE_RANLIB but maybe a change the ADD_LIBRARY?

My research on ranlib lead me to libtool and the libtool manpage. On
osx-10.5.7 (all I have access to) the libtool manpage states:

” Libtool with -static is intended to replace ar(5) and ranlib.
For backward compatibility, ranlib is still available, and it supports
universal files. ”

To ultimately, the ADD_LIBRARY should be changed to libtool. Just
passing that information along.

Thanks.

(more…)

Run into the strangest linking error for tools/trimscores on osx/darwin.

Compile of trimscores.c to .o no problems.

Go to link.

/usr/bin/gcc -g -Wl,-search_paths_first -headerpad_max_install_names -
fPIC trimscores.o -o trimscores ../ntserv/libnetrek.a
Undefined symbols:
“_Cambot_out”, referenced from:
_Cambot_out$non_lazy_ptr in libnetrek.a(getpath.o)
“_NoCount_File”, referenced from:
_NoCount_File$non_lazy_ptr in libnetrek.a(getpath.o)
“_Global”, referenced from:
_Global$non_lazy_ptr in libnetrek.a(getpath.o)
“_PlayerFile”, referenced from:
_PlayerFile$non_lazy_ptr in trimscores.o
_PlayerFile$non_lazy_ptr in libnetrek.a(getpath.o)
“_GodLog”, referenced from:
_GodLog$non_lazy_ptr in libnetrek.a(getpath.o)

I’ve removed al CFLAGS and LDFLAGS still get the same linking error.

Ok, lets look at libnetrek, getpath.o in there?

$ ar t libnetrek.a | grep getpath
getpath.o

getpath cannot resolve (as an example) GodLog, poking around I found
GodLog is defined in data.c

#ifdef CHECKMESG
char MesgLog[FNAMESIZE];
char GodLog[FNAMESIZE]; <———-
#endif

Is data.o in libnetrek?

$ ar t libnetrek.a | grep data
data.o

Is GodLog inside data.o?

$ ar x libnetrek.a data.o
$ nm data.o | grep GodLog
00000100 C _GodLog

Any ideas?