that libpath stuff is a pretty horrible hack (one that won't work anyway since the binary won't be able to find its data if you stick it in /usr/bin). the proper way to package ioq3 is to put it next to the data and have a shell script in /usr/bin. you could set the default fs_basepath instead of libpath, but it's still preferable to have a shell script do that instead of hardcoding it into the binary (that shell script could just as easily set fs_homepath too).

It looks to me like I added all the right hooks in the right places.

Observe:
> pwd
/usr/home/kamikaze
> ./ioquake3-smp.x86_64 +set fs_basepath /usr/local/share/quake3 +set sv_pure 1 +set vm_cgame 0 +set vm_game 0 +set vm_ui 0 +set fs_libpath ioq3/ioquake3-1.36/build/release-freebsd-x86_64
ioq3 1.36 freebsd-x86_64 Aug 31 2009
...
Loading dll file ui.
Sys_LoadDll(/usr/home/kamikaze/baseq3/uix86_64.so)... 
Sys_LoadDll(/usr/home/kamikaze/baseq3/uix86_64.so) failed:
"Failed loading /usr/home/kamikaze/baseq3/uix86_64.so: Cannot open "/usr/home/kamikaze/baseq3/uix86_64.so""
Sys_LoadDll(/home/kamikaze/.ioquake3/baseq3/uix86_64.so)... 
Sys_LoadDll(/home/kamikaze/.ioquake3/baseq3/uix86_64.so) failed:
"Failed loading /home/kamikaze/.ioquake3/baseq3/uix86_64.so: Cannot open "/home/kamikaze/.ioquake3/baseq3/uix86_64.so""
Sys_LoadDll(/usr/local/share/quake3/baseq3/uix86_64.so)... 
Sys_LoadDll(/usr/local/share/quake3/baseq3/uix86_64.so) failed:
"Failed loading /usr/local/share/quake3/baseq3/uix86_64.so: Cannot open "/usr/local/share/quake3/baseq3/uix86_64.so""
Sys_LoadDll(ioq3/ioquake3-1.36/build/release-freebsd-x86_64/baseq3/uix86_64.so)... 
Sys_LoadDll(ioq3/ioquake3-1.36/build/release-freebsd-x86_64/baseq3/uix86_64.so): succeeded ...
Sys_LoadDll(ui) found vmMain function at 0x82bf0e95a
...

So the binary, the game files and the libraries are in different places and all are found.

Why is it cleaner to wrap a shell script around ioquake3 instead of building something in? Would you really expect me to place a binary in /usr/local/lib?

(In reply to comment #2)
> Why is it cleaner to wrap a shell script around ioquake3 instead of building
> something in? Would you really expect me to place a binary in /usr/local/lib?
of course not, but the mod code (in this case shared objects, but usually just qvms) should be considered part of the data, not part of the code. that's part of why (io)q3 refuses to load the shared objects from /usr/lib or any of the other standard places unless you go out of your way to do something like this (the other is that there are now a lot of games that will load uix86.so if you tell them to use shared objects, and that would lead conflicts between games, since it isn't something games can share).

This is sound reasoning, but I think it does not apply here.

a) Library loading is only attempted when the game is started with the vm_* cvars set to 0.

b) Modifications shouldn't come with a platform specific .so anyway (ioquake3 runs fine without them, but the performance is better i.e. ~15% more fps on my machine).

c) When no library is encountered, the game falls back to the qvm.

d) Ioquake3 uses lots of libraries from /usr/local/lib (e.g. SDL, OpenAL).

e) The .so files would be placed in /usr/local/lib/ioquake3/baseq3 and /usr/local/lib/ioquake3/missionpack, so other applications will not encounter them unless they try to load "ioquake3/baseq3/uix86.so". I consider any application not ioquake3 doing this broken.

f) Obeying hier(7) is really sufficient reason for me. I don't know how this is handled for other operating systems, I haven't ever used any other *nix flavour apart from Solaris and AIX (not a Linux person), but FreeBSD things have places where they belong.

there isn't a good reason to package the shared objects to begin with, since they will pretty much never be used in online play (sv_pure 1 requires qvms).

(In reply to comment #5)
> there isn't a good reason to package the shared objects to begin with, since
> they will pretty much never be used in online play (sv_pure 1 requires qvms).

So why have the feature at all?
I say, let the user choose.

Created attachment 2108 [details]
FreeBSD Makefile patch that applies to HEAD

The Makefile patch for HEAD differs a little. The rest of the patch set applies unchanged.

I have managed to include both the 1.36 release and SVN snapshots into the FreeBSD ports system. They peacefully coexist, keep their libraries separated but use the same game data. Maybe this illustrates why I want the DEFAULT_LIBDIR stuff.

# pkg_info -Lx quake3
Information for ioquake3-1.36:

Files:
/usr/local/bin/ioq3ded
/usr/local/bin/ioquake3
/usr/local/bin/ioquake3-smp
/usr/local/lib/ioquake3/baseq3/cgamex86_64.so
/usr/local/lib/ioquake3/baseq3/qagamex86_64.so
/usr/local/lib/ioquake3/baseq3/uix86_64.so
/usr/local/lib/ioquake3/missionpack/cgamex86_64.so
/usr/local/lib/ioquake3/missionpack/qagamex86_64.so
/usr/local/lib/ioquake3/missionpack/uix86_64.so
/usr/local/share/doc/ioquake3/README

Information for ioquake3-devel-1.36.s1582:

Files:
/usr/local/bin/ioq3ded-devel
/usr/local/bin/ioquake3-devel
/usr/local/bin/ioquake3-smp-devel
/usr/local/lib/ioquake3-devel/baseq3/cgamex86_64.so
/usr/local/lib/ioquake3-devel/baseq3/qagamex86_64.so
/usr/local/lib/ioquake3-devel/baseq3/uix86_64.so
/usr/local/lib/ioquake3-devel/missionpack/cgamex86_64.so
/usr/local/lib/ioquake3-devel/missionpack/qagamex86_64.so
/usr/local/lib/ioquake3-devel/missionpack/uix86_64.so
/usr/local/share/doc/ioquake3-devel/README

Information for quake3-data-1.32.b.3_2:

Files:
/usr/local/share/quake3/baseq3/pak1.pk3
/usr/local/share/quake3/baseq3/pak2.pk3
/usr/local/share/quake3/baseq3/pak3.pk3
/usr/local/share/quake3/baseq3/pak4.pk3
/usr/local/share/quake3/baseq3/pak5.pk3
/usr/local/share/quake3/baseq3/pak6.pk3
/usr/local/share/quake3/baseq3/pak7.pk3
/usr/local/share/quake3/baseq3/pak8.pk3
/usr/local/share/quake3/missionpack/pak1.pk3
/usr/local/share/quake3/missionpack/pak2.pk3
/usr/local/share/quake3/missionpack/pak3.pk3
/usr/local/share/pixmaps/quake3.xpm

There have been reports of problems with i386, so I'm going to post more patches, soon.

Created attachment 2113 [details]
Makefile patch to compile on FreeBSD

Created attachment 2114 [details]
Add HOMEPATH and DEFAULT_LIBDIR to README

Created attachment 2115 [details]
Add amd64 bugfix to qcommon.h

Created attachment 2116 [details]
Fix x86_64 assembler bug in vm_x86_64.c

Created attachment 2117 [details]
Add DEFAULT_LIBDIR support

Created attachment 2118 [details]
Add HOMEPATH support

All that stuff has now been tested on FreeBSD i386 and amd64.

I've broken the patches up into several chunks, the Makefile, vm_x86_64.c and qcommon.h patches are obligatory to get things to compile on FreeBSD.

The DEFAULT_LIBDIR thing is useful to package maintainers, not only on FreeBSD I assume.

The HOMEPATH support would also benefit standalone developers who want to stay as close to the original ioq3 code as possible.

I understand that I couldn't convince kevlarman of the usefulness. This is difficult to comprehend for someone who needs that stuff.

I hope that at least the Makefile patch and bugfixes can get committed.

Created attachment 2119 [details]
Makefile patch to compile on FreeBSD

I don't see a compelling reason for the LIBPATH and HOMEPATH stuff. As people have already tried to explain to you, there isn't really a good reason to distribute the .so files. The 64bit patches look sane enough though.

Just a FYI: we (or at least I) try very hard not to introduce #ifdef <platform> style code. Every time that is done you baloon your number of test cases and what's worse is you need to recompile and use a different platform to exercise these test cases.

(In reply to comment #17)
> I don't see a compelling reason for the LIBPATH and HOMEPATH stuff.
I believe in making the application follow the policy of the OS (instead of making the OS follow the policy of the app), this is what this is about.

You can install a number of q3 engines on FreeBSD, any of these would remove the ioq3 specific cvars from the configs, whenever run. This is why ioq3 needs its own user data on FreeBSD.

Luckily I have split up the patches, so you can single them out. I'll maintain them, because I consider them obligatory for using ioq3 on FreeBSD.

> As people
> have already tried to explain to you, there isn't really a good reason to
> distribute the .so files.
Between 10% and 20% (closer to the latter) performance gain in single player mode suffices for me as a good reason. For you people with kick-ass rigs it might not be a deal, but I'm running on shared memory.

> The 64bit patches look sane enough though.
Glad to hear.

> Just a FYI: we (or at least I) try very hard not to introduce #ifdef <platform>
> style code. Every time that is done you baloon your number of test cases and
> what's worse is you need to recompile and use a different platform to exercise
> these test cases.
I have removed all these from the patches. They were only in the original patch set.

(In reply to comment #18)
> I believe in making the application follow the policy of the OS (instead of
> making the OS follow the policy of the app), this is what this is about.

Then how does that make it an ioq3 problem? We can't make it fit the policy of the OS on every OS; there is no reason to make an exception for any platform, especially one as small as FreeBSD.

> You can install a number of q3 engines on FreeBSD, any of these would remove
> the ioq3 specific cvars from the configs, whenever run. This is why ioq3 needs
> its own user data on FreeBSD.

I don't see why they can't share the homepath? It's perfectly possible to do so with idq3 and ioq3.

> Between 10% and 20% (closer to the latter) performance gain in single player
> mode suffices for me as a good reason. For you people with kick-ass rigs it
> might not be a deal, but I'm running on shared memory.

So the cost is a whole lot of distruptive patching and unneccesary functionality while the payback is a performance gain on single player Q3 on FreeBSD. You're chasing a pretty tiny use case.

The OS bin libs should be considered to be useful for debugging only, they are not really intended for any other purpose.

Basically what I'm getting at is the LIBPATH and HOMEPATH stuff isn't going to be getting committed.

(In reply to comment #19)
> (In reply to comment #18)
> > I believe in making the application follow the policy of the OS (instead of
> > making the OS follow the policy of the app), this is what this is about.
> 
> Then how does that make it an ioq3 problem? We can't make it fit the policy of
> the OS on every OS; there is no reason to make an exception for any platform
Most Linux distributions and all other UNIX systems have the same policy. It's just become popular to ignore that. Doesn't make it right in my eyes.

> especially one as small as FreeBSD.
Apart from Ubuntu and Debian I feel pretty confident that FreeBSD is the largest Open Source platform around.

> Basically what I'm getting at is the LIBPATH and HOMEPATH stuff isn't going to
> be getting committed.
So close this bug. You haven't invalidated any of my arguments, I'm just shown that the priorities here are different. However, nobody seems to be acting upon it.

(In reply to comment #20)
> Most Linux distributions and all other UNIX systems have the same policy. It's
> just become popular to ignore that. Doesn't make it right in my eyes.

*nix/*bsd is effectively one platform in this context. There are other platforms.

> > especially one as small as FreeBSD.
> Apart from Ubuntu and Debian I feel pretty confident that FreeBSD is the
> largest Open Source platform around.

Ignoring the fact that Linux itself remains a relatively small platform, I don't think you'll find many statistics to actually back that claim up, not that it's important in the first place really.

> So close this bug. You haven't invalidated any of my arguments, I'm just shown
> that the priorities here are different. However, nobody seems to be acting upon
> it.

You seem determined to create conflict here. Your bug is only a couple of weeks old; the response you're getting is much quicker than average. If you're saying FreeBSD doesn't compile then that should be fixed and we would appreciate patches, but what we don't want are patches that add unnecessary functionality for reasons already discussed. The FreeBSD compile has worked in the past, but those maintaining it lost interest for one reason or another. At this time it did not require any library path hacks or changes to the home directory so I fail to see why it does now. If you do need changes in order to distribute ioq3 as a package/port/whatever then those should be confined to said distribution, as is the case with other distribution packages (and without causing any consternation I might add).

If you are just hell-bent on the bug being closed because you think we're stupid poo-poo-heads or something then you can do so yourself, but that won't really be helping anyone.

I don't see any big deal with the HOMEPATH thing. Mods could use this in the makefile to not have to touch the source code (where we have ".q3a" hardcoded). "HOMEPATH" is a little misleading, as it still respects $HOME (and still leaves the game name hardcoded on Mac OS X). I committed it, but someone should improve this, I think.

Libdir stuff seems reasonable to me. I might even use it to flip between two builds for comparison when debugging. Harmless enough in any case, so in it goes.

x86_64 fixes are no-brainers, in they go.

Makefile patch only touches FreeBSD-specific parts, so no need to worry there.

Okay, it's all in Subversion.

--ryan.

The HOMEPATH thing is silly. There is no reason for one platform to use a completely different home dir name than the others. If it's a problem on one platform (I don't believe it is), it's a problem on them all. It's fine how it is. Likewise, there is no good reason to start polluting trunk with extra stuff for library paths. If distribution people want this they can add it themselves. Lets try and get FreeBSD working, but without the extra unnecessary stuff.

I saw you reverted the changes in svn. I don't really feel strongly about this bug, so I'll leave you two to hash it out.

--ryan.

Created attachment 2211 [details]
Add DEFAULT_LIBDIR support

Created attachment 2212 [details]
Add HOMEPATH support

Created attachment 2213 [details]
Makefile patch to compile on FreeBSD

Created attachment 2214 [details]
Document HOMEPATH and LIBDIR

I have just added the current version of my SVN patchset.

All that needs to be applied to allow building ioq3 on FreeBSD is the Makefile patch.

The HOMEPATH and DEFAULT_LIBDIR patches are there for completeness, I know they won't be accepted.

However, they would allow throwing OS-X specific stuff out of the code and moving that into the appropriate places in the Makefile.

I hope you will apply the Makefile patch.

Created attachment 2215 [details]
Add amd64 bugfix to qcommon.h

The new Makefile that make ioquake3 follow the FreeBSD architectures instead of converting them to Linux also needs this q_platform.h change for client libraries to be successfully loadable on amd64 (shame on me for not testing this properly).

Created attachment 2231 [details]
Makefile patch to compile on FreeBSD

I obsolteted the x86_64 assembler patch, because it was committed to SVN a long time ago.

The Makefile patch was updated to apply to r1757.

Created attachment 2255 [details]
Makefile patch to compile on FreeBSD

New Makefile patch applies to r1769.

Changes since the last version of the patch:
- Add USE_MUMBLE support for FreeBSD
- Add USE_CURL support for FreeBSD

It still depends on patch 2215.

Change version from 1.36 to SVN HEAD.

* You still have bits of your HOMEPATH and LIBDIR changes in the Makefile changes.
* You set DEBUG_CFLAGS in the FreeBSD section; this is supposed to be set externally to the Makefile, or get a default if not.
* RELEASE_CFLAGS is also set in the Makefile, but this is not referenced anywhere; it's possible you started out patching before some recent changes.

I can make these changes myself if you like, but I have no FreeBSD machine to test so I can't guarantee I don't break something in the process.

Created attachment 2257 [details]
Makefile patch to compile on FreeBSD

(In reply to comment #34)
> * You still have bits of your HOMEPATH and LIBDIR changes in the Makefile
> changes.

Removed.

> * You set DEBUG_CFLAGS in the FreeBSD section; this is supposed to be set
> externally to the Makefile, or get a default if not.

Removed.

> * RELEASE_CFLAGS is also set in the Makefile, but this is not referenced
> anywhere; it's possible you started out patching before some recent changes.

I fixed that, also went through the gcc manual and removed some stuff that seemed redundant/counter-productive to me.

> I can make these changes myself if you like, but I have no FreeBSD machine to
> test so I can't guarantee I don't break something in the process.

I made the requested changes, built, installed and fragged some. I'm confident that this works fine if you have no objections.

Thank you for your time.

Fixed in r1770.