SVN Fails to Run in OS X

Shissui · Post by **Shissui** » Sun Feb 11, 2007 1:41 pm

Hi,

*** continued from thread #77461 -- the topic has drifted & now bears absolutely no resemblance to the original issue. ***

I installed the DevTools & other dependencies.
I installed subversion 1.4.3
I attempted an initial checkout.

It ran for 2.5 hours & then hanged, so the checkout never finished.

The problem -- Mac OS X disks are not case sensitive when shipped. They will only distinguish case in the file system if & only if you reformat the hard drive. The download hung when it found a tag directory that "already existed" (differing only by case from a previous tag directory) & it thus could not create that directory.

The only way to fix this at my end is to reformat the hard disk and a clean install. That would be a week of work and I REALLY do not want to do that until 10.5 is released. SO, unless somebody is willing to rename the offending directory(s), I think that I am done.

*** EDIT: The problem directories are:
.../tags/before_khepri_Cg
.../tags/before_khepri_cg
(where I have substituted underscore for space) ***

Post by **klauss** » Mon Feb 12, 2007 6:07 am

I replied in your original thread.
You don't have to checkout tags/ or branches/, only trunk/data4.x and trunk/vegastrike - it said so on the wiki, last time I checked.

Shissui · Post by **Shissui** » Mon Feb 12, 2007 6:19 pm

That should solve the problem nicely.

Were I to offer any development support, it would not be before I migrate to OS X 10.5 anyway; and all of my disks will be changed to case sensitive format anyway as I do that migration.

[Bug notes don't count -- long ago I developed a habit to keep a notebook on hand for bug triage. Although I am retired now, this volume isn't full yet. My replies to various bug complaints come from this book.]

However, it may be a few days before I have any time to get back to the SVN.

Shissui · Post by **Shissui** » Tue Feb 20, 2007 11:26 pm

klauss wrote:I replied in your original thread.
You don't have to checkout tags/ or branches/, only trunk/data4.x and trunk/vegastrike - it said so on the wiki, last time I checked.

Yes, it did. However, had I skipped the section marked for Linux only (no linux machines here) and the section marked for Windows only (no windows machines here) & that left me feeling pretty much on my own after I was told that I needed to install svn.

However, I have made some progress; switching to the linux instructions, executed from the bsd command line in OS X.
- I did the checkout (trunk only) from the command line. [10881]
- bootstrap-sh ran without error
- configure crashed when it failed to look in /usr/bin for python 2.3.5
- copious additional warnings appear in the config.log file.

config.log [no longer] appended.

[edit: config.log appears to be too large to upload (122184 bytes). What alternatives exist for delivery ?]

Post by **dandandaman** » Wed Feb 21, 2007 9:52 am

Fink is probably the way to go for most of the dependencies. You'll need python, libjpeg, libpng, libogg, libvorbis, SDL, SDL_mixer (get SDL and SDL_mixer from the main SDL site and compile yourself ... the newer versions have a lot of OSX fixes).

For python you could also maybe use the patch from here:
http://thewillofomega.googlepages.com/vegastrikedev

That should hopefully get you a bit further. Any more problems just ask

Dan

Shissui · Post by **Shissui** » Wed Feb 21, 2007 3:57 pm

Early in the build, configure tested for python and correctly detected version 2.3.5.

Late in the build it tested again, but only in specific directories rather than reading PATH. On this occasion, it failed to test "/usr/bin/python", where it is located, as part of the kernel install for OS X.

Presumably, this could be hacked with a symlink. Any preference to where the best place would be to place it ?

****
I do not have fink. Thus, I am unlikely to have any of the fink libraries. I do not have SDL. That likely accounts for a very large portion of the log volume.

Collecting the dependencies should keep me busy a while.

Shissui · Post by **Shissui** » Thu Feb 22, 2007 2:55 am

Some progress, I think.

I installed Fink & all of the dependencies that you named. I ran bootstrap without error. configure appears to have run to the end of its script, as before, but does not generate a usable makefile. config.log is only 1000 bytes smaller than before, so it appears that configure is not happy with any of my installations.

It still fails to find the Python that it ran a version test on.

Code: Select all

<<snip>>
checking for python... python Python 2.3.5
/usr/lib/libpython2.3.so no
/usr/local/lib/libpython2.3.so no
/usr/lib64/libpython2.3.so no
/usr/local/lib64/libpython2.3.so no
/usr/lib64/python2.3/config/libpython2.3.so no
/usr/local/lib64/python2.3/config/libpython2.3.so no
/sw/lib/python2.3/config/libpython2.3.so no
/usr/lib/python2.3/libpython2.3.so no
/usr/lib/python2.3/config/libpython2.3.so no
/usr/local/lib/python2.3/libpython2.3.so no
/usr/local/lib/python2.3/config/libpython2.3.so no
/lib/python2.2/config/libpython2.3.so no

Missing {python-prefix}/lib/libpython2.3.so

<< snip>>
!25> which python
/usr/bin/python

Well, actually, not "code", but "stdout".

****
The server still times out if I try to append the config.log; so not included.

Post by **ace123** » Fri Feb 23, 2007 8:17 am

Configure is not looking for the binary which will always be in /usr/bin/python.
It's looking for the shared object file that it can directly link to.

Specifically, the file it is looking for is called "libpython2.3.so" The problem is that python does not have a standard place for this shared object file on all operating systems.

What version of OS X.x is this on by the way? Can you find the necessary python library at all? (you might want to try a manual locate/find to find it, or maybe Spotlight will find it).

By the way, you might want to attach the config.log, not append it. The attach buttons should let you include it.

However, this seems to be a problem that config.log won't help solve... it has to do with the way your operating system libraries are organized.

Post by **dandandaman** » Sat Feb 24, 2007 6:51 am

Try:

Code: Select all

--with-python-libs=/sw/lib

or where ever fink put it (/sw is default)

Post by **ace123** » Sat Feb 24, 2007 8:28 am

Should we add that path to the configure script as well?

It currently only checks /sw/lib/python2.4/config, but not /sw/lib by itself.

I wish python had a standard location for its libraries, or else a program such as python-config like every other library includes that gives out that information.

Shissui · Post by **Shissui** » Sat Feb 24, 2007 3:19 pm

This brings me (I presume) a step forward.

I followed Dan's link regarding Mac python. This led me to a site that had a script to allow use of the Apple's python, but I was not able to get any use out of that -- I have no idea what might even run an "m4" script. Reading the script did not get me much further.

So, I installed a second copy of python --> wherever fink puts it. This had mixed results. After detecting the Apple installed 2.3.5, it wanted to use that instead of the fink installed 2.4.2. SO, it found only those shared libraries that are further shared 2.3.5 & 2.4.2

I removed 2.4.2 & installed a second copy of 2.3.5 so that the libraries would match & this problem has resolved -- the config.log file is now another 300 bytes smaller.

The only error remaining in stdout is "expat library not found".

***
Dan> or where ever fink put it (/sw is default)

The problem, in this case, is that APPLE places python & its libraries in /usr/bin -- another place where nobody else puts it. My crude hack worked by putting a duplicate install in /sw, yet another place where nobody else puts it but it *is* a place that the VS configure script knows to look in. VS configure is happy with this -- /usr/bin/python is in PATH & all the libraries that it wants are in /sw.

I am not nearly as happy with this as VS. I really dislike needing to install two copies of python, but it will do for now. Disk space is cheap, but keeping them synchronised might not be.

****
ace> Configure is not looking for the binary which will always be in /usr/bin/python.
ace> It's looking for the shared object file that it can directly link to.

Thank you -- I can see that plainly now in stdout, but I missed it before.

ace> What version of OS X.x is this on by the way?

I am running OS X 10.4.8 with all updates. But that does not tell you that it is running on a 64bit quad Intel processor.

ace> By the way, you might want to attach the config.log, not append it.

That is what I was doing. I suppose I could try cut/paste & then delete or edit it to the bones after vous have gone through it. But, give the size of the file, I am reluctant to do that before we have resolved everything that can be learned from stdout.

Or, I could email it to one of you.

ace> However, this seems to be a problem that config.log won't help solve

Agreed, but we are (finally) running out of missing dependencies & soon it might become useful.

***
I am also learning that in the [large number censored for vanity] years that I was not looking, *nix has really changed. I feel about as competent as in my first month facing a Sun [small number censored because it would date me faster than the number of years] workstation.

Post by **ace123** » Sat Feb 24, 2007 11:38 pm

You shouldn't have to copy libraries. There are configure options to tell it where to find the libraries by the way.

configure --help wrote: --with-python-libs=DIR Location of python library
--with-sdl-prefix=PFX Prefix where SDL is installed (optional)
--with-sdl-exec-prefix=PFX Exec prefix where SDL is installed (optional)
...
--with-expat-libs=DIR Location of expat library
--with-expat-inc=DIR Specify expat header file location
...

If you can locate them manually, then it should be possible to tell configure about where they were.

Unfortunately, I don't know the Mac platform very well either. Do you have suggestions on how to make the configure script more robust?

Shissui · Post by **Shissui** » Sun Feb 25, 2007 2:58 am

just ran a find --> the results were more interesting than expected:

stdout wrote: !1=/usr[admin]> sudo find / | grep libpython
Password:
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libpython.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libpython2.3.dylib
/Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libpython2.dylib
/sw/lib/python2.3/config/libpython2.3.a
/sw/lib/python2.3/config/libpython2.3.dylib
/sw/share/doc/python23/Doc/lib/libpython.tex
/usr/lib/libpython.dylib
/usr/lib/libpython2.3.dylib
/usr/lib/libpython2.dylib
/Volumes/X5/usr/lib/libpython.dylib
/Volumes/X5/usr/lib/libpython2.4.dylib
/Volumes/X5/usr/lib/libpython2.dylib

So, I make several observations from this:
1) There are lots of "libpythin2.3.dylib" & VS found one of them (most likely /usr/lib/).
2) VS also wants "libpython2.3.so", but will accept "libpython2.3.a". My only copy of either library is in "/sw" = the fink installation. Apple does not appear to install this.
3) SDK10.4 appears to include yet another complete (superfluous) install of python.
4) Apple plans to leave python in /usr/bin & the linked libraries in /usr/lib for 10.5 [X5 has OS X 10.5 (developer release, build 9a343)]. As XCode3 has not been installed on that drive, it is in the base install.

Conclusions:
The existing script already knows to look in /usr/bin for Python and in /usr/lib for the python libraries. But, Apple does not pre-install all of the Python libraries that VS expects to find. SO, it is still necessary to fink "libpython2.3.a".

****
So, while I am on a roll . . .

stdout (with appreciable snipping & editing to simplify) wrote: !3=/usr[admin]> sudo find / | grep expat
Password:
/Developer/SDKs/MacOSX10.3.9.sdk/usr/X11R6/... (source code)
/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/... (source code)
/sw/fink/10.4/stable/main/finkinfo/libs/expat.info
/sw/fink/10.4/stable/main/finkinfo/libs/expat.patch
/sw/fink/10.4/unstable/main/finkinfo/libs/expat.info
/sw/fink/10.4/unstable/main/finkinfo/libs/expat.patch
/sw/fink/10.4/unstable/main/finkinfo/libs/perlmods/xml-sax-expat-pm.info
/sw/fink/10.4/unstable/main/finkinfo/libs/perlmods/xml-sax-expat-pm.patch
/sw/fink/10.4/unstable/main/finkinfo/libs/tclexpat.info
/sw/lib/libexpat.0.5.0.dylib
/sw/lib/libexpat.0.dylib
/sw/lib/python2.3/lib-dynload/pyexpat.so
/sw/lib/python2.3/xml/(various)/(.py, .pyc & .pyo files)
/sw/share/doc/expat-shlibs/(docs)
/sw/share/doc/python23/Doc/lib/libpyexpat.tex
/sw/share/doc/python23/html/lib/(more docs)
/.../VS/vegastrike/(SVN 10881)
/usr/include/php/ext/xml/expat/*.h
/usr/share/doc/libxml2-2.6.16/html/tutorial/includexpath.c
/usr/share/man/mann/expat.n
/usr/share/man/mann/expatapi.n
/usr/X11R6/include/expat.h
/usr/X11R6/lib/libexpat.0.4.dylib
/usr/X11R6/lib/libexpat.0.dylib
/usr/X11R6/lib/libexpat.a
/usr/X11R6/lib/libexpat.dylib

Observations:
--> Apple's version of the expat libraries are in /usr/X11R6/lib/ (base install) with the source in the SDK hierarchies.
--> looking at X5, the binaries are included in the base install; the source code from the SDK tree is not required for this dependency.
--> also from X5, in 10.5, it appears that these libraries will be duplicated in /usr/lib -- where VS looks for them.

Conclusion:
The config script does not appear to look in "/usr/X11R6/lib/" (well -- it isn't exactly the most obvious place to look), so the script fails to find these libraries.

***
Going forward:
1) [for me] I should be able to move another step forward by duplicating these libraries to "/usr/lib". << but not tonight >>

Q: 10.4 appears to have older versions of these libraries than 10.5. Can I update:
libexpat.0.4.dylib --> libexpat.1.5.0.dylib
libexpat.0.dylib --> libexpat.1.dylib
libexpat.a (not installed in 10.5)
libexpat.dylib --> libexpat.dylib (likely newer)

2) [for somebody else] Although the directory tree will be normalised in 10.5, the config script still needs to be changed for compatibility with 10.3 & 10.4.

Post by **ace123** » Sun Feb 25, 2007 11:42 pm

Have you tried using the configure options:

Based on your searches, this *should* work:
--with-python-libs=/sw/lib/python2.3/config --with-expat-libs=/usr/X11R6/lib

The python will look for the libpythonX.X.a (If the configure script is getting python 2.4 instead of 2.3, that would be your problem... I could add an option --with-python-version=X.X if it's finding the wrong version).

Shissui · Post by **Shissui** » Sun Mar 04, 2007 10:55 pm

Another step forward, if only 3 lines further down configure.
Configure now finds the expat libraries, but fails to find expat.h

stdout wrote:<snip>
checking for glut32 library... yes
checking for expat library... yes
checking expat.h usability... no
checking expat.h presence... no
checking for expat.h... no
configure: error: Cannot find expat.h
6.221u 13.178s 0:28.00 69.2% 0+0k 43+570io 0pf+0w
<snip>
!25=[admin]> sudo find / | grep expat.h
Password:
/Developer/SDKs/MacOSX10.3.9.sdk/usr/X11R6/include/expat.h
/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include/expat.h
.../vegastrike/vega-proj/include/expat.h
.../vegastrike/vega-vc7/include/expat.h
.../vegastrike/vega-vc8/include/expat.h
.../vegastrike/vegastrike/objconv/mesher/expat.h
/usr/include/php/ext/xml/expat/expat.h
/usr/X11R6/include/expat.h

SO with 8 to pick from, 4 of which are directly available in the VS code tree & another 2 in PATH, I find this error a bit inexplicable.

Post by **ace123** » Mon Mar 05, 2007 4:49 am

Should have seen that one coming... use the other argument that goes with expat:
--with-expat-inc=/usr/X11R6/include
to go with the -libs argument

I've never seen such a strange system configuration before... and I don't think it is easy to change the configure script to try certain places. Expat is a completely different library and does not depend on X11 at all, so why Apple put them there is beyond me.

The ones in the vegastrike code base that you found are all for windows, for which we also include the proper DLL's. Unix-based systems allow for better use of shared libraries, so including them in the source tree is not necessary.

Shissui · Post by **Shissui** » Sat Mar 10, 2007 12:47 am

1 line further. It now correctly locates expat.

Now it halts at the immediate subsequent test -- searching for the png library.
I have located two copies -- in "/sw/include/" and "/sw/lib/"
However, I have been unable to derive the correct syntax for another "--with" command to actually include it.

Perhaps this would go faster if you explained how I can take:
"configure: error: # library not found"
and a location for # --> yet another --with.

At 3 lines per week, this compile make take a while.

Post by **dandandaman** » Sat Mar 10, 2007 9:36 am

I have to say you've sure uncovered a great deal of tricky issues. I personally never came across half of these, as I tried to keep all teh dependencies down to stuff that would be available on older OSX versions (so I could potentially build releases if so required). Basically, the script I use to configure is this:

Code: Select all

./configure --enable-macosx-bundle --with-expat-libs=/sw/lib/ --with-expat-inc=/sw/include/ --with-png-libs=/sw/lib/ --with-png-inc=/sw/include/ --with-jpeg-libs=/sw/lib/ --with-jpeg-inc=/sw/include/ --with-vorbis-libs=/sw/lib/ --with-vorbis-inc=/sw/include/

So it looks like I use the fink version for everything in that list. Python is the only major exception, and for that I use that modified version of the .m4 (which to use you just copy of the version that exists in your m4scrips/ folder in the root vegastrike directory) ... but that can now change that our min OSX version is 10.3, as we can use that python version for release even.

Sorry it took so long to get back to you. If you do get it working with the 10.4 versions, let us know as it'll be useful in teh future

Otherwise, using the setup I just described is guaranteed to at least get configure working

Dan

Shissui · Post by **Shissui** » Sat Mar 10, 2007 3:10 pm

That helped. I redirected the expat dependencies to /usr/X11R6/include (Apple has a newer version than Fink). Otherwise, I ran your command as presented . . .

Warnings -- does not find OGRE & CEGUI & GTK:

stdout wrote: checking for OGRE... Package OGRE was not found in the pkg-config search path.
Perhaps you should add the directory containing `OGRE.pc'
to the PKG_CONFIG_PATH environment variable
No package 'OGRE' found
no
checking for CEGUI... Package CEGUI was not found in the pkg-config search path.
Perhaps you should add the directory containing `CEGUI.pc'
to the PKG_CONFIG_PATH environment variable
No package 'CEGUI' found
no
checking for CEGUI_OPENGL... Package CEGUI-OPENGL was not found in the pkg-config search path.
Perhaps you should add the directory containing `CEGUI-OPENGL.pc'
to the PKG_CONFIG_PATH environment variable
No package 'CEGUI-OPENGL' found
no
checking for CEGUI_OGRE... Package CEGUI-OGRE was not found in the pkg-config search path.
Perhaps you should add the directory containing `CEGUI-OGRE.pc'
to the PKG_CONFIG_PATH environment variable
No package 'CEGUI-OGRE' found
no
checking for gtk-config... no
checking for GTK - version >= 1.2.0... no
*** The gtk-config script installed by GTK could not be found
*** If GTK was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the GTK_CONFIG environment variable to the
*** full path to gtk-config.
configure: WARNING: GTK Was not found. VSSETUP will not be built.

Running "find" -->
OGRE -- only in .../m4scripts/...
CEGUI -- only some dll files in .../data5.x/...
gtk -- doc files in fink --> suggests I have the name wrong.
... and dll files in: .../data4.x/... & .../data5.x/...
... and (many) h files in: .../vega-proj/vssetup/...

Post by **dandandaman** » Sun Mar 11, 2007 2:40 am

Those errors are perfectly fine

You don't need ogre or cegui at this stage, and gtk is only needed if you want to build the setup app (maybe good later, but not required). So from that starting point, you can type 'make vegastrike' and should end up with a shiny new binary

Dan

Shissui · Post by **Shissui** » Sun Mar 11, 2007 4:30 am

stdout wrote:!3:[admin]> make check
source='src/aldrv/al_sound.cpp' object='src/aldrv/vegastrike-al_sound.o' libtool=no \
depfile='src/aldrv/.deps/vegastrike-al_sound.Po' tmpdepfile='src/aldrv/.deps/vegastrike-al_sound.TPo' \
depmode=gcc3 /bin/sh ./depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I. -I./boost/1_33 -Wno-long-double -I/sw/include/ -DWITH_MACOSX_BUNDLE=1 -DHAVE_SDL=1 -DSDL_WINDOWING=1 -I/Developer/SDKs/MacOSX10.3.9.sdk/System/Library/Frameworks/Carbon.framework/Libraries/CIncludes -I/usr/X11R6/include -I/sw/include/ -I/sw/include/ -DJPEG_SUPPORT -DHAVE_AL=1 -I/System/Library/Frameworks/OpenAL.framework/Headers -I/sw/include -I/sw/include/ -DHAVE_OGG -I/usr/include/python2.3 -DHAVE_PYTHON=1 -I./src -DBISON -g -O2 -I/Developer/SDKs/MacOSX10.2.8sdk/System/Library/Frameworks/Carbon.framework/Libraries/CIncludes -pipe -falign-loops=2 -falign-jumps=2 -falign-functions=2 -I/sw/include/SDL -D_THREAD_SAFE -D_REENTRANT -pipe -c -o src/aldrv/vegastrike-al_sound.o `test -f 'src/aldrv/al_sound.cpp' || echo './'`src/aldrv/al_sound.cpp
src/aldrv/al_sound.cpp:184:18: error: alut.h: No such file or directory
src/aldrv/al_sound.cpp: In function 'bool MacFixedLoadWAVFile(char*, ALenum*, ALvoid**, ALsizei*, ALsizei*)':
src/aldrv/al_sound.cpp:191: error: 'alutLoadWAVMemory' was not declared in this scope
make: *** [src/aldrv/vegastrike-al_sound.o] Error 1

If I follow this correctly, then I will have no sound & no VSSETUP -- but otherwise a workable executable ?

[Edit: Nope. Looks as if it merely fails to compile.]

peter · Post by **peter** » Sun Mar 11, 2007 5:22 am

Shissui wrote: src/aldrv/al_sound.cpp:184:18: error: alut.h: No such file or directory

Looks like you're missing openAL, or configure isn't finding it. If there's an option to disable openAL, or sound altogether, that might work. BTW, openAL is like openGL, but for audio instead of graphics. I think alut would be the openAL equivalent of GLUT, the GL Users Toolkit. (BTW, there's a GLUT library function to draw a teapot. I wonder which came first, the teapot demos, or the teapot library function

)

Post by **dandandaman** » Sun Mar 11, 2007 7:32 am

Oh, um, watch what openAL version you're using... I think I use the official mac framework from the openAL project. i remember getting that error, and a different version was the way to fix it...

Dan

Shissui · Post by **Shissui** » Sun Mar 11, 2007 3:15 pm

[Edit: Preventive of an error yet to bite hard -- danielrh records in the wiki that VS forces itself on the 10.3.9 SDK -- code that will not run on an intel processor. Had I continued, the eventual binary would have crashed as soon as I attempted to open the resulting ".app". [This likely accounts for a lot of bgaskey's recent errors opening VS on his Mac PPC in 10.4.8]

Daniel's solution was to edit configure.ac to use the 10.4u kit. I have made this change, but it does not effect the current problem.

Way back near the beginning, I remember asking why the 10.3.9 SDK was needed -- after all, it does not run on my machine. An Intel processor running 10.3.9 would still need the 10.4u SDK, as that is the oldest SDK that supports both hardware.]

***

dandandaman wrote:Oh, um, watch what openAL version you're using... I think I use the official mac framework from the openAL project. i remember getting that error, and a different version was the way to fix it...

No openAL at all.

[Edit2: Located & installing openAL 1.0.13. Will run the compile again.]

Shissui · Post by **Shissui** » Sun Mar 11, 2007 8:59 pm

I now have OpenAL. However, configure continues to assume that OpenAL will be in "/sw/..." & never actually attempts to verify that. (hence why configure completes).

OpenAL is a framework, rather than a shared library, located in "/Library/Frameworks/OpenAL.framework".

What do I add to the configure command so that it will correctly locate this?