too much dynamic loading?
Hi, As libjpeg and libpng bumped their major versions in the last months I had to adjust some of my library requires in my wine.spec file. This caused me thinking if it is really necessary to dynamically load nearly every library. Can we make some of those direct linking? libjpeg and libpng and some other lowlevel libraries might be useful. Opinions? Ciao, Marcus
On Fri, May 21, 2010 at 12:59 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote:
As libjpeg and libpng bumped their major versions in the last months I had to adjust some of my library requires in my wine.spec file.
This caused me thinking if it is really necessary to dynamically load nearly every library.
Can we make some of those direct linking? libjpeg and libpng and some other lowlevel libraries might be useful.
+1 for static linking them. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Fri, May 21, 2010 at 01:03:09PM -0400, Steven Edwards wrote:
On Fri, May 21, 2010 at 12:59 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote:
As libjpeg and libpng bumped their major versions in the last months I had to adjust some of my library requires in my wine.spec file.
This caused me thinking if it is really necessary to dynamically load nearly every library.
Can we make some of those direct linking? libjpeg and libpng and some other lowlevel libraries might be useful.
+1 for static linking them.
No static linking either, its the nightmare of security maintainers ;) But which distro doesnt have libjpeg or libpng? or libX11.so, libXext.so., libncurses.so... To show what I mean ... I currently have this line in my .spec file: Requires: libX11.so.6 libXext.so.6 libXcursor.so.1 libXi.so.6 libXxf86vm.so.1 libXrender.so.1 libXrandr.so.2 libXinerama.so .1 libXcomposite.so.1 libGL.so.1 libGLU.so.1 libxslt.so.1 libncurses.so.5 libfreetype.so.6 libpng12.so.0 libjpeg.so.62 libfontcon fig.so.1 libcups.so.2 to make sure everything is installed. I might forget stuff and so reduce functionality unintentionally. While this is not necessary on 32bit systems, it is definitely necessary on a 64bit system, where the 32bit Wine has to pull its requires or they will not be installed. Ciao, Marcus
On Fri, May 21, 2010 at 1:28 PM, Marcus Meissner <marcus(a)jet.franken.de>wrote:
No static linking either, its the nightmare of security maintainers ;)
Good point. Direct Linking then. I am just in favor of changing it to something other than the status quo because all of this dynamic loading stuff never wants to work right on OS X. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Fri, 21 May 2010, Steven Edwards wrote:
On Fri, May 21, 2010 at 1:28 PM, Marcus Meissner <marcus(a)jet.franken.de>wrote:
No static linking either, its the nightmare of security maintainers ;)
Good point. Direct Linking then. I am just in favor of changing it to something other than the status quo because all of this dynamic loading stuff never wants to work right on OS X.
I'm not convinced direct linking will work better on Mac OS X, unless you ship libpng and libjpeg with Wine. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Dieu dit: "M-x Lumière". Et la lumière fut.
I'm not convinced direct linking will work better on Mac OS X, unless you ship libpng and libjpeg with Wine.
And libgnutls (plus prereqs libgpg-error & libgcrypt). And libgphoto2, libexif, libtiff, libgsm, libjbig... - there's a laundry list of libraries that are required for a full-featured Wine install, and prereqs of prereqs, prereqs of THOSE. You get the point. Static libraries on Mac OS X/Darwin also misbehave in odd ways that you simply don't see with dylibs as well. I package all of these up with osxwinebuilder, building shared libs from source, and it's a bit tricky. Things fail in unforeseen ways if a user's modified their environment. I had an issue this morning where libghoto2 was failing for version 2.4.9+, but working for anything older. Turns out that GD had been installed into /usr from source on Leopard, the user upgraded to Snow Leopard (which broke a few of GD's reqs), and libgphoto2 2.4.9+ now checks for GD, which it found, mysteriously breaking the compile. Had GD been compiled statically, it may have worked - or not. But that's not something I (or Wine) check for, just something I didn't consider until today when a prereq broke. Wine really wants to map and use share libraries like they're supposed to be used: dynamically, when a module needs them. Pain in getting to that point on Macs is one reason there's not a binary Wine package available; licensing and binary distribution questions/methods is another. Static libraries may be a quick workaround, but ultimately full shared library coverage for all prereqs on all supported platforms is the way to go. If you want a bad example, take a look at GSM. configure simply won't work with/find a static libgsm on OS X, but a manually-built dylib works just fine from what I can glean. The fact that the distributor (s) don't include an easy method for building shared GSM libs on OS X made this a little tricky to workaround IMO. But it's doable. Kind of ranting. Let me know if clarification is needed on any point. Standard Wine on OS X may not work in a Mac user-friendly way, but it works very well if you just forego a GUI, have good prereq coverage and use it from the terminal. That's good enough for me! -r
ryan woodsmall wrote:
I'm not convinced direct linking will work better on Mac OS X, unless you ship libpng and libjpeg with Wine.
And libgnutls (plus prereqs libgpg-error & libgcrypt). And libgphoto2, libexif, libtiff, libgsm, libjbig... - there's a laundry list of libraries that are required for a full-featured Wine install, and prereqs of prereqs, prereqs of THOSE. You get the point. Static libraries on Mac OS X/Darwin also misbehave in odd ways that you simply don't see with dylibs as well.
Does not Wine's configure not include these if they are not found? Yes, a MacOSX build should either: 1. Get them. 2. Ship with them, build for the LCD MacOSX version (right now that it is, believe it or not, Tiger [MacOSX 10.4.11].) MacOSX does not include many UNIX type programs and utilities because they are not used in the base product. MacPorts and Fink are two porting efforts to bring UNIX utilities/programs to MacOSX and most of the utilities can be built from source. However, MacOSX Wine distributors cannot rely on which version of a utility I installed and even if I did. Many MacOSX users have been quietly surprised when their favorite Windows program causes a complete system lockup because of a faulty or incomplete Wine installation.... James McKenzie
Marcus Meissner wrote:
On Fri, May 21, 2010 at 01:03:09PM -0400, Steven Edwards wrote:
On Fri, May 21, 2010 at 12:59 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote:
As libjpeg and libpng bumped their major versions in the last months I had to adjust some of my library requires in my wine.spec file.
This caused me thinking if it is really necessary to dynamically load nearly every library.
Can we make some of those direct linking? libjpeg and libpng and some other lowlevel libraries might be useful.
+1 for static linking them.
No static linking either, its the nightmare of security maintainers ;)
But which distro doesnt have libjpeg or libpng? or libX11.so, libXext.so., libncurses.so...
How about MacOSX or Solaris? They don't come with these. James McKenzie
On Sun, May 23, 2010 at 4:13 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote:
Marcus Meissner wrote:
On Fri, May 21, 2010 at 01:03:09PM -0400, Steven Edwards wrote:
On Fri, May 21, 2010 at 12:59 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote:
As libjpeg and libpng bumped their major versions in the last months I had to adjust some of my library requires in my wine.spec file.
This caused me thinking if it is really necessary to dynamically load nearly every library.
Can we make some of those direct linking? libjpeg and libpng and some other lowlevel libraries might be useful.
+1 for static linking them.
No static linking either, its the nightmare of security maintainers ;)
But which distro doesnt have libjpeg or libpng? or libX11.so, libXext.so., libncurses.so...
How about MacOSX or Solaris? They don't come with these.
OSX 10.5+ comes with X11 installed. OpenSolaris has X11 and friends as well, though Solaris may not. -- -Austin
Austin English wrote:
On Sun, May 23, 2010 at 4:13 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote:
Marcus Meissner wrote:
On Fri, May 21, 2010 at 01:03:09PM -0400, Steven Edwards wrote:
On Fri, May 21, 2010 at 12:59 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote:
As libjpeg and libpng bumped their major versions in the last months I had to adjust some of my library requires in my wine.spec file.
This caused me thinking if it is really necessary to dynamically load nearly every library.
Can we make some of those direct linking? libjpeg and libpng and some other lowlevel libraries might be useful.
+1 for static linking them.
No static linking either, its the nightmare of security maintainers ;)
But which distro doesnt have libjpeg or libpng? or libX11.so, libXext.so., libncurses.so...
How about MacOSX or Solaris? They don't come with these.
OSX 10.5+ comes with X11 installed. OpenSolaris has X11 and friends as well, though Solaris may not.
Austin: I'm referring to the 'little' things, like openssl. MacOSXs version is not the same as Linux. Also, the level of library support varies greatly between versions of MacOSX. See my reply to Ryan for more on this. Also, we have to keep in mind that there are still Intel Mac users that are running MacOSX 10.4, which did not come with X11 installed. James McKenzie
On Sun, May 23, 2010 at 5:20 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote:
I'm referring to the 'little' things, like openssl. MacOSXs version is not the same as Linux. Also, the level of library support varies greatly between versions of MacOSX.
See my reply to Ryan for more on this.
Also, we have to keep in mind that there are still Intel Mac users that are running MacOSX 10.4, which did not come with X11 installed.
Not counting X11.app in this but, in the past I spoke with Alexandre about putting together a Winesupport.Framework or some such that would contain all of the libraries required for an offical OS X release and he was not opposed to linking to it on winehq.org and making it part of the support requirements. The problem is that putting this package together and maintain it is going to require a bit of heavy lifting. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
participants (6)
-
Austin English -
Francois Gouget -
James McKenzie -
Marcus Meissner -
ryan woodsmall -
Steven Edwards