#4243 closed defect (fixed)
OSX: make bundle fails
| Reported by: | SF/meddlingmonk | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Port: Mac OS X |
| Version: | Keywords: | build | |
| Cc: | Game: |
Description
With revision 39539 of ports.mk can no longer successfully make bundle in OSX. Problem is at line 100 and make bundle fails with error that there is no libz.a and there definitely is not. I use Fink and do have zlib but that seems to be the only library that's giving make bundle trouble.
Ticket imported from: #2703992. Ticket imported from: bugs/4243.
Change History (11)
comment:1 by , 16 years ago
| Owner: | set to |
|---|
comment:2 by , 16 years ago
comment:3 by , 16 years ago
Let me clarify some things:
* FYI, DarwinPorts is called MacPorts these days ;-)
* The jzlib package has not much to do with zlib. It is a pure Java library (which tries to emulate zlib *for java programs*). In particular it is not surprising that there is no libz.a installed by this ;).
* Fink used to have a zlib package, too, before OSX bundled zlib. Since then, it seemed pointless to package zlib, and hence we dropped it
* We want to link against libz.a instead of libz.dylib so that our binary works across more OS X versions (and even on old ones without libz.dylib, or with incompatible ABI). So this is not about "work" but about portability.
It used to work because despite the last point we just linked against the libz.dylib anyway, ignoring the slightly reduced portability caused by this.
comment:4 by , 16 years ago
So possibly the simplest solution to this is on the side of the Fink user, since I hardly think that Fink is going to ever re-add zlib and libz.a is going to be needed. It's an easy matter to install zlib.a into /sw/lib from source. Unless there really is a solution on the coding side, perhaps the OSX build instructions in the readme only need to have the instructions for manually installing zlib for Fink users added.
comment:5 by , 16 years ago
I'd think "make bundle" is mainly useful for actually distributing builds, in which case using MacPorts (which does provide libz.a) or compiling your own, isn't too problematic (and should be done anyway, due to the porting issues fingolfin mentioned).
Alternative solutions are, of course, to either autodetect the presence of libz.a and use libz.dylib if not found, or provide a configure switch for this, but that may be just cluttering up the configure scripts for little practical purpse.
comment:6 by , 16 years ago
That last point you make is something I was thinking of, which is why I went looking for a simple way to get zlib without switching to Macports. But I think make bundle isn't just useful for distributing a build; bundles are convenient for launching a program. And the more people who compile and play with svn yadda yadda open source blah blah blah bug reports. So I'd still suggest just adding to the readme in the OSX compiling part stuff about if you have Fink you must get zlib source here and do this and that if you want to have compressed saved games. And that should be good enough because, really, why >should< you clutter up the configure scripts trying to cover every possible contingency (unless somehow you really wanted to)? So basically I've come to the conclusion that the fix is better done on the compilers' side rather than the coders' side (apart from the readme edit I suggested).
comment:7 by , 16 years ago
Actually, for almost all cases, there is no need to static link zlib (which is why I wrote "make bundle" to not do it). Libz is a system library on any recent OSX version. The only need to static link occurs if you want to create PowerPC builds supporting OS versions *before* 10.3.9.
For everybody else, insisting on static linking is a needless hassle. Instead of adding complicated instructions on how to manage that (regardless of Fink, MacPorts, whatever), I think we should just switch back to defaulting to dynamic link, and only make it possible to switch that to static linking *optionally*.
In other words: Dynamic linking should be the default, with the possibility of using static linking (with some extra work) *optionally*, not the converse, as it is right now!
E.g. introduce a ZLIB_LDFLAGS variable, which defaults to "-lz", but on static / cross compile builds, can be set to e.g. /opt/lib/libz.a
comment:9 by , 15 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:10 by , 15 years ago
I changed it now from static linking back to dynamic linking. The only people affected by this are pre-10.3.9 users, who will simply have to live with it -- SDL 1.2.14 does not support these systems anymore either. But if one really wants to attempt for older OS X versions, then one can override the zlib being used by setting the OSX_ZLIB variable, e.g.
make bundle OSX_ZLIB=/path/to/libz.a
comment:11 by , 6 years ago
| Component: | → Port: Mac OS X |
|---|
I've been doing a little poking around. Zlib seems to be a little complex on OSX. DarwinPorts has a package simply called zlib and maybe there is a libz.a in /opt/lib (I don't know because I don't use DarwinPorts). Fink instead has a package called jzlib (j for Java) but there's no libz.a in /sw/lib/. But I find that OSX has zlib built in. There is no libz.a in /usr/lib but there is a libz.dylib which is what I expected to find. So I experimented by changing line 100 of ports.mk to read "OSX_STATIC_LIBS += /usr/lib/libz.dylib" and make bundle worked and saved games made are the same size as with the previous build I made last week so presumably it works the way it should although I don't know whether that's the solution. I imagine it would take a bit of work to make ScummVM to rely entirely on the zlib built into OSX rather than the different versions available through Fink and DarwinPorts, but would it be less or more work than trying to take both other versions into account?