Compatibility error problem in libpng15.15 when compiling on 10.8 and deploying on 10.9
Good morning/afternoon, 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, so I installed XQuartz and compiled without a problem. The application runs on this machine. 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. I think I see where the problem is, namely, I am binding to the XQuartz libpng (27.0.0), but this is not available on the customers' 10.9, where the libpng is only 25.0.0. However, I fail to see what's the proper way of dealing with it. Should I - unpack only the .h files out of XQuartz (or get them in any other way) and link against the .dylib provided by Apple on 10.8, or - use XQuartz to compile and link, then ship XQuartz .dylibs as private libraries in my .app, or - other options ? 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. The app is in Qt, running native, but some libraries I am using do need X libraries, in addition to libpng, freetype etc... Thank you for your attention and help, Stefano Borini
On Jan 14, 2014, at 12:01, Stefano Borini <stefano.borini@ferrara.linux.it> wrote:
Good morning/afternoon,
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.
so I installed XQuartz and compiled without a problem. The application runs on this machine.
Great.
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
I think I see where the problem is, namely, I am binding to the XQuartz libpng (27.0.0), but this is not available on the customers' 10.9, where the libpng is only 25.0.0. However, I fail to see what's the proper way of dealing with it. Should I
- unpack only the .h files out of XQuartz (or get them in any other way) and link against the .dylib provided by Apple on 10.8, or
There are no such libs.
- 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. 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.
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
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? 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. Furthermore, there are native OS X APIs available for your use as well which may be better suited.
Thank you for your attention and help,
Stefano Borini
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/xquartz-dev
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
On Jan 15, 2014, at 5:52 AM, Stefano Borini wrote:
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.
Those libraries are bogus. If a process loads one of those: a) that process is terminated, and b) the system puts up a dialog telling the user that they need to install XQuartz to get X functionality. (For what it's worth, (a) is nasty. Our product had code which tried to dynamically load various FreeType libraries to find a "best" one, relying on dlopen() to report failure if it couldn't load one. Touching the FreeType library in /usr/X11/lib was like stepping on a land mine.) I'm not at all sure that those libraries are even usable as stub libraries for linking. Only after installing XQuartz are those libraries replaced by (links to?) the real libraries. That allows binaries that were linked to libraries in /usr/X11/lib to load, because such binaries might have been created in the days before XQuartz installed to /opt/X11.
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.
The important thing to understand is that libpng and libfreetype and the like are not "X11 libs". They happen to have been installed with X11 because they were needed by X11. If they are needed by your program, then they should be installed by/with your program in an analogous manner.
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.
There's a valid reason for it. Regards, Ken
On 1/15/14 2:58 PM, Ken Thomases wrote:
On Jan 15, 2014, at 5:52 AM, Stefano Borini wrote:
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.
Those libraries are bogus.
wow... sneaky. I would have never found out. Thanks.
The important thing to understand is that libpng and libfreetype and the like are not "X11 libs". They happen to have been installed with X11 because they were needed by X11. If they are needed by your program, then they should be installed by/with your program in an analogous manner.
After this discussion, I managed to successfully run the application on the customer's computer. I did so by copying the libpng and libfreetype from XQuartz into the .app. Apparently, it is working, so I will most likely build my own versions without relying on XQuartz for the final deployment.
There's a valid reason for it.
Ok. I guess I will explore a bit further and then start packaging these additional components as well. Thank you all for the help, it was extremely useful. Kind Regards Stefano Borini
On Jan 15, 2014, at 11:00, Stefano Borini <stefano.borini@ferrara.linux.it> wrote:
After this discussion, I managed to successfully run the application on the customer's computer. I did so by copying the libpng and libfreetype from XQuartz into the .app. Apparently, it is working, so I will most likely build my own versions without relying on XQuartz for the final deployment.
Make sure your dylibs have a relative id (relative to @executable_path, @loader_path, or @rpath).
participants (3)
-
Jeremy Huddleston Sequoia
-
Ken Thomases
-
Stefano Borini