| Previous · Next | |
| User | Message |
|
preaction
|
Date: 3/1/2011 12:01 pm · Subject: WRE: To Share or not to Share · Rating: -1
I just got done fixing a problem with the WRE compiling on OS X 10.6 (Snow Leopard). After multiple other problems, the final problem became the shared libraries the WRE compiles: The OS X ImageIO library saw the WRE's libgif, libjpeg, libpng, and libtiff and tried to load its symbols from those. This didn't work because OS X's ImageIO expected a different name for some unknown reason (__cg_something instead of _something). By removing all the --enabled-shared from the affected libraries, I fixed the problem: ImageMagick statically linked to the libraries, and OS X's ImageIO could not see the shared libs to get confused about. This brings up an idea: If we disabled shared libraries as much as possible in the WRE, we could play nicely as a rogue stack inside of the user's operating system. However, I am not well-versed in this area, so I don't know the potential problems involved. Here are my guesses: 1) If people are using the WRE stack to run things other than WebGUI, we could make it more difficult for them (upgrading the WRE would mean rebuilding those other things to link against the new versions). 2) Statically-linked libraries use more memory, disk space, or other resources (they copy the symbols directly into the executable, instead of linking at runtime). Are these actual problems? If they are problems, are they worth keeping shared modules for? |
| Back to Top |
Rate [ | ]
|
|
perlDreamer
|
Date: 3/1/2011 12:31 pm · Subject: Re: W To Share or not to Share · Rating: -1
With WebGUI 8, what advantages does the WRE give? Now that we don't have to have a FAT apache and a THIN apache, is it worth shipping binaries instead of local system packages? Colin |
| Back to Top |
Rate [ | ]
|
|
knowmad
|
Date: 3/1/2011 12:40 pm · Subject: Re: WRE: To Share or not to Share · Rating: -1
Doug, given the continuing downward cost for resources and servers, I can't imagine that the slight increase in memory usage will be a big deal. Also, we run a few other non-webgui sites out of the WRE but nothing else. Not being a system programmer, I don't know all the issues of shared vs. static but this move sounds reasonable as long as it doesn't impact Apache's ability to use shared memory (that would have a massive RAM impact). Colin, I still think there's a good use-case for having the WRE. Perhaps it doesn't need to keep packaging mysql and apache, but it bundles up all the Perl modules and helper scripts needed to run WebGUI into an easy download.
William ---- |
| Back to Top |
Rate [ | ]
|
|
perlDreamer
|
Date: 3/1/2011 1:01 pm · Subject: Re: W To Share or not to Share · Rating: -1
I think we're in violent agreement. After having gone through the Debian packaging with SquOnk, they would really rather that we spell out requirements in terms of their packaging requirements. So, you can imagine that webgui.deb/rpm includes all of WebGUI, including sbin, and spells out which versions of which perl modules are needed. Then, there's a webgui_wre.deb/rpm which incudes WRE/lib and WRE/sbin, log rotation settings, PID file locations and so on which are specific to the OS. However, since we're shipping native binaries, we don't need wreservice, we use the system standard service command. However, there'd still be addsite, removesite, backup and the others. |
| Back to Top |
Rate [ | ]
|
|
preaction
|
Date: 3/1/2011 1:11 pm · Subject: Re: WRE: To Share or not to Share · Rating: -1
Plain Black uses the WRE to deploy its servers, and we will continue to do so. The WRE will continue to be "the way Plain Black recommends", even if we are making it easier to deploy WebGUI on just about anything and moving some things the WRE provides into WebGUI itself. There are plans for the WRE, but we can discuss those later when I've got something to show off. Right now I'm just trying to ask about something I don't know enough about. Will not offering dynamically-linked/shared libraries inside the WRE stack cause more problems than it fixes? If it will cause problems, I will only disable sharing on those libraries I absolutely need to compile on the system in question. If it won't cause problems, I'll disable as many as possible. |
| Back to Top |
Rate [ | ]
|
|
scottwalters
|
Date: 3/1/2011 1:24 pm · Subject: Re: WRE: To Share or not to Share · Rating: -1
Static is fantastic. Many Linux app projects distribute statically linked versions but in this case it sounds like there's more incentive for static Mac apps. I don't know what the norm is there with .dmgs people download. With Linux and Unix-like systems, you can at least set the LD_RUN_PATH to create the correct view of user and system libraries. Without that (and again, this might exist for OSX as well, but I wouldn't know about it), the situation for trying to use user-land dynamic libraries would be pretty bleak. The libraries the the WRE uses are generally pretty small. It isn't loading all of GTK or anything on that order. If one library is quite large, don't bundle it but instead require it to be installed independentally. |
| Back to Top |
Rate [ | ]
|
|
preaction
|
Date: 3/1/2011 1:39 pm · Subject: Re: WRE: To Share or not to Share · Rating: -1
OS X has "DYLD_LIBRARY_PATH" and "DYLD_FALLBACK_LIBRARY_PATH" which from what I've read should have corrected this problem, but it seems when dyld finds a lib, it uses that lib forever, not caring if it can't find the right symbols inside. It's like DLL hell or something. I still don't even know why OS X's ImageIO was being loaded at all. I can't find any reference to its necessity in ImageMagick's website or docs, but I've given up on many things about compiling stuff making sense. |
| Back to Top |
Rate [ | ]
|
