[Xquartz-dev] Compatibility error problem in libpng15.15 when compiling on 10.8 and deploying on 10.9

[Stefano Borini]

On Wed, Jan 15, 2014 at 12:47:38AM -0800, Jeremy Huddleston Sequoia wrote:
> > I am having a problem with XQuartz 2.7.2 (but also latest) and a program I am deploying, specifically due to libpng15.15. I envision a more general issue, as my software also depends on other X libraries.
> > 
> > I am compiling on 10.8/XCode 5, freshly installed. 10.8 comes with X11 libs but no headers,
> 
> No, it doesn't.  10.8 doesn't come with X11 at all.

A freshly installed copy of 10.8 has /usr/X11/lib, which contains .dylibs for X, in addition to libpng and so on. It does not come with a X11 server.

> > I then packaged my .app and tried to run it on a customer's machine (10.9, upgraded from 10.6.8) but I get a Compatibility error in libpng15.15 (claims 25.0.0, but wants the one of the XQuartz I had, 27.0.0). I did change the path to the proper one with install_name_tool.
> 
> What exactly did you do with install_name_tool?  You shouldn't need to change anything.  It is correctly /opt/X11/lib/libpng15.15.dylib

If the customer had XQuartz, of course it would have worked, but I was hoping that the /usr/X11/lib libraries I told about 
were satisfying my dependency, something that apparently is not true (25.0.0 vs 27.0.0). I used install_name_tool to change
in the deployed application the path to the libpng lib from /opt to /usr, then shipped it to the customer.

> > - use XQuartz to compile and link, then ship XQuartz .dylibs as private libraries in my .app, or
> 
> No.
> 
> > - other options ?
> 
> Tell the customer to install a version of XQuartz greater than or equal to what you build with.

I expect some resistance from the marketing dept for this.

> Either that, or you'll need to build the dylibs yourself, package them in your app bundle and change all the dylib ids to be relative to the executable path.

would it be possible to package the dylibs from XQuartz as I said above ?

> > I am sure I am not the only one having faced this problem, so I assume a best or common practice exists.
> > 
> > Note that I can't deploy XQuartz on the customer's machine, and I should not need an X server.
> 
> Then you should not be linking against the libraries in /opt/X11/lib?  Customers will only have those if they've installed XQuartz

I would indeed liked to link against the ones in /usr/X11/lib, but I needed the
headers. When I installed XQuartz for the first time, I expected it to provide
just the header for those libraries. Yesterday I discovered this is not true.

> > The app is in Qt, running native, but some libraries I am using do need X libraries, in addition to libpng, freetype etc...
> 
> Why would you need X11 libraries if you're not communicating with an X11 server?

Some of the libraries we depend on need libpng and libfreetype. Initially
I thought about compiling my own ones, but then I saw they were on the mac
already, in /usr/X11/lib as I said, although there were no headers. 

I am still investigating exactly the details and see what is needed and what is
not (the porting is in progress). I am sure about png/freetype, not 100% sure
about the rest of the X11 libs.

> If all you need are things like pixman, cairo, libpng, and libfreetype, then you really should just package up your own copies.  Installing XQuartz is overkill for your customers.

I agree, although I would have preferred not to. Nothing personal, it's just additional work, and I want to do it
only if there's a valid reason for it.

Thanks

Stefano Borini