Posted: Mon Feb 04, 2008 9:26 am Post subject: Neooffice in universal binaries, one question more
Hello,
I read the posts about this subject, and the problem of the weight of a such image is important, but we use NeoOffice in education where we have to do an image of the system which will be used on Intel and PPC macs. NeoOffice will oblige us to do one image for PPC Macs, and one for Intel Macs.
So i have 2 questions :
- Is it possible to have an universal version of NeoOffice for this particular situation ?
- If not, what will be the best way to avoid using 2 images for the different macs, if we couldn't have an universal version of NeoOffice ?
Posted: Mon Feb 04, 2008 10:04 am Post subject: Re: Neooffice in universal binaries, one question more
oihenart wrote:
So i have 2 questions :
- Is it possible to have an universal version of NeoOffice for this particular situation ?
- If not, what will be the best way to avoid using 2 images for the different macs, if we couldn't have an universal version of NeoOffice ?
Even if you write code to splice all of the binaries in NeoOffice together using the lipo command, I do not think this is possible as the PowerPC and the Intel binaries use different compilers.
AFAIK, lipo doesn't care about compilers; Mozilla apps, for instance, use gcc3 for the PPC half and gcc4 for Intel and are lipoed.
The drawback to making your own Universal app is of course patches; I think when this was last discussed, the story went something like "patch PPC version on PPC, patch Intel version on Intel, lipo the newly-patched binaries into a new Universal app" and then (re)deploy.
Smokey _________________ "[...] whether the duck drinks hot chocolate or coffee is irrelevant." -- ovvldc and sardisson in the NeoWiki
Note that if you lipo your binaries, it is now your own product and 1) you cannot redistribute it with the NeoOffice name because 2) we cannot support it.
In other words, if anyone wants to experiment with lipoing their binaries, great. But don't expect use to use our very limited resources to fix any problems that you create.
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Tue Feb 05, 2008 11:11 pm Post subject:
The primary problem you will have with using lipo is that lipo is designed to make a single image of different macho executable formats of the same name and with same entry points (not required, but in theory). The OOo and Neo build system compiles and links to different OOo-specific extensions for most all of its dynamic libraries (macxp vs. macxi).
Pavel did work a while back to provide a universal version, but I do not know the specifics and I don't think it was adopted. There may be ways to hork around the link lines with otool or install_name_tool but any libraries that don't adhere to whatever naming conventions used for the merged library won't be able to be loaded by the dynamic linker.
Still, universal is needed in one situation (which I think is esoteric, personally...) network install mounts that are used by both PowerPC and Intel machines or a startup disk that has been set up to be universal (and my understanding is that 10.5 no longer installs a universal kernel). Addressing that case is just not worth the overall pain of nearly doubling download size which stresses both users and the bandwidth of our mirrors.
If we were a for profit product selling DVDs my opinion would of course be different
Still, universal is needed in one situation (which I think is esoteric, personally...) network install mounts that are used by both PowerPC and Intel machines
That's our situation. But i understand that is complicated and expensive to make an UB of NeoOffice. So i will probably put both versions of NeoOffice on our image, one in a PPC folder, the other in a Intel folder. We use NetRestore and when we will restore one mac, we will use a post-action script which will move NeoOffice either from PPC or Intel folder to Applications and then delete the folders.
OPENSTEP wrote:
and my understanding is that 10.5 no longer installs a universal kernel
What do you mean exactly ? An image of a computer system in 10.5 done in an Intel Mac can be used in an PPC mac, no ?
Joined: May 25, 2003 Posts: 4752 Location: Santa Barbara, CA
Posted: Wed Feb 06, 2008 11:41 pm Post subject:
Yeah for now the easiest solution would be to do the separate folders for Neo. Since we link to different library names for both architectures, there's no simple shell script way I can think of to combine them. It may exist though, but it's just not on our list of things to worry about right now.
I had heard that a single image of 10.5 would no longer do both PPC and Intel. I may be totally wrong; it used to work in prerelease 10.5. I could totally be wrong and I haven't tried it yet with release 10.5 myself.
Posted: Thu Aug 21, 2008 1:40 pm Post subject: Making a Universal Binary for College Lab Deployment
I'm a college professor and we are trying to deploy Neooffice and Leopard in a mixed PPC/Intel lab. Our admins here are not very Mac savvy, hence my involvement in the project. We are simply Carbon Copy Cloning a master image from an external hard drive through out the lab.
I have read the various other Universal Binary posts and understand the decisions made given the resources at hand. I'm not questioning the UB decision in the slightest.
A Neooffice Universal Binary is definitely what we need here however. To that end I've tried to "lipo" Intel and PPC versions of 2.2.4 Patch 5 to create my own Universal Binary. I'm not much of a terminal user however and something is not working:
Posted: Thu Aug 21, 2008 1:54 pm Post subject: Re: Making a Universal Binary for College Lab Deployment
JT wrote:
A Neooffice Universal Binary is definitely what we need here however. To that end I've tried to "lipo" Intel and PPC versions of 2.2.4 Patch 5 to create my own Universal Binary. I'm not much of a terminal user however and something is not working:
So let me get this straight. You are going to modify the binaries of our production release and then use our brand name so that we get to pick up to support load that you will likely generate.
What you are trying to do will definitely break and will not be patchable so you will creating something that 1) is likely to generate lots of support load and 2) is something that we cannot fix.
You are free to change the NeoOffice code and modify that. But what you are not free to do is modify the code or release and use our trademarked name on it.
If you want to this, by all means do it. However, you should build NeoOffice from source with your own brand name on it and not ours.
This may sound harsh, but we have extremely limited funds and support volunteers and we cannot afford to support your experimentation in a production environment.
I can't help thinking it'd be less work in the long run to maintain 2 master clones, one for ppc and one for intel machines. I think you've been lucky so far to have your one clone work fine on both platforms - it's generally a pretty risky affair cloning e.g. prefs from a ppc to an intel machine, I'd expect trouble sooner or later doing that.
I can't help thinking it'd be less work in the long run to maintain 2 master clones, one for ppc and one for intel machines. I think you've been lucky so far to have your one clone work fine on both platforms - it's generally a pretty risky affair cloning e.g. prefs from a ppc to an intel machine, I'd expect trouble sooner or later doing that.
..and if your ratio of Intel to PowerPC Macs is similar to our download ratio, you could easily to the following (this assumes that PowerPC Macs are less common than Intel Macs and that the machine that you make your Carbon Copy Cloner image from is an Intel Mac):
1. Install PowerPC Mac and rename "NeoOffice.app" "NeoOffice for older Macs.app"
2. Drag "NeoOffice for older Macs.app" to /Applications folder of machine that you make Carbon Copy Cloner image from.
3. Install Intel Mac on machine that you make Carbon Copy Cloner image from and leave the default " NeoOffice.app" name
4. Create Carbon Copy Cloner image.
With the above, most users are very likely to try the "NeoOffice.app" installation first. If they have an Intel Mac, it will work. If they have a PowerPC Mac, Mac OS X Leopard will display an error dialog that you cannot run the app on that machine's hardware. Then, hopefully the user sees the "NeoOffice for older Macs.app" right next to it in the Finder and they try using that.
With the above, users can install patches that we release as NeoOffice's patch installer will find the "NeoOffice for older Macs.app".
Edit: I forgot to add that if you do the above, when a user installs any of our patches, the patch installer will only update the installation that matches their hardware and the non-matching installation will not be touched.
I guess I've unwittingly hit a nerve here. I apologize. It was not my intention to upset anyone or to capriciously compromise the Neooffice product. I was just looking for a solution to our particular needs-- which I have to say is where I feel the responses so far make some unfair assumptions...
Such as why would _your_ proportion of PPC to Intel downloads have anything to do with the distribution of PPC and Intel machines in _our_ labs? Every school lab I've been in (too many to count) is the product of available money and institutional priorities that intersect with Apple's product cycles in random and often rather inconvenient ways. Our lab happens to be half PPC and half Intel. Your proposed solution means that half our undergrad users will receive some perplexing error message if they try to use Neooffice. In a real world most students receiving such a message will just give up and move on. Are they lazy? No, it just means they want to be able to sit down and get some work done, which leads to another assumption in your responses: that we would want our users to apply patches.
Imagine you're a student with a paper due. You've left your distracting dorm room and gone to the Mac Lab in the Library. You find a free computer, sit down, and login. As soon as you login three windows pop up asking if you want to update something-- god knows what. Or imagine you are an instructor. You have a limited amount of time to accomplish some very specific things with students on the computers. As each student logs in they get a random custom mix of update messages for everything from CS2 to Firefox. So then you waste several minutes helping students dismiss and sort through all those messages. You've just lost a lot of instructional momentum.
A well run computer lab uses a standard, stable, predictable setup that only changes during periods of downtime and disuse, that is, semester breaks. One of the first things administrators do when they install software on their master image is turn off all the auto update functions. Leaving them on means they get applied haphazardly and also means you have an unstable, unpredictable work environment. My original thinking for a Neooffice Universal Binary was that every semester I'd create a new UB with the latest patches-- a few extra steps than just applying one patch to one version of Neooffice-- but vastly less work than maintaining separate masters for PPC and Intel-- which leads to the next assumption that seems to underly your responses so far...
Namely that Universal Binaries are some esoteric technology not even fully embraced by Apple and truly needed in a few, rare circumstances, if ever. When Apple first released their Intel hardware administrators enthusiastically embraced it _and_ started working on creating universal boot disks. Though it proved difficult, admins were able to come up with a reliable way to make a Universal system under 10.4, but they also came to a consensus that when possible it would be better to wait for Apple to release an officially universal operating system. From an administrator's perspective this is one of the main features of Leopard, and it's a feature that has worked well and consistently (in my experience and from all I've read) from version 10.5.0 to 10.5.4. It's a feature that enables admins to streamline much of what they do from diagnostic disks, to Netboot, to master images, and software distribution. Universal Binaries are preferable from a user's perspective for the simple reason that they make a major technology change transparent. Why should a user have to care or pay attention to the fact that one virtually identical-looking iMac has this chip or that chip in it?
Which let me say again here, I'm not questioning the seemingly very reasonable decisions that the Neooffice team has made about not releasing a Universal Binary. Believe me, working at a tiny, cash-strapped school I understand the delicate balancing of priorities that must occur when resources are limited. That's why I was trying to create a UB myself-- but it was apparently not a good idea-- and if you'd have simply said, "No we don't want to help you make a UB because we feel it would compromise the integrity of our product."-- I'd have been cool with that. Instead you try to convince me that we don't need a UB, without really knowing anything about our needs or even asking any questions to help clarify them. I'd humbly suggest that you might want try listening with an open mind to the needs of your users. Honestly your responses leave a bit of a bad taste in my mouth and really remind me of my interactions with Quark in the 90's (but that another story).
So what's the outcome for my computer lab? I'll do as you suggest, two copies of Neooffice in the Applications folder with the PPC version named "NeoOffice for older Macs.app." Am I going to feature Neooffice in the dock where students can easily access it? No, because on half the computers it's going to produce some baffling error message that is going to frustrate users. Instead I'll put Word 2004 in the dock and leave the Neooffice(s) buried in the Apps folder.
Thanks for your time and attention, gentlemen. I truly do appreciate it. Boards like this are one of the reasons I like to use small, independently published software. I am sorry however that we weren't able to find a more agreeable solution.
Well, insofar as I'm involved in this, I'll say that I rejoice in your good fortune in running the same clone on both ppc and intel machines without problems - I do know folk who've had a much more hairy/disastrous experience trying to do that, hence my comment. Of course, it may be that they were trying to do this with older versions of the OS, in which case my comment was irrelevant.
I'm sorry there's no obvious solution to your problem that doesn't involve you going down a path that'll create more work. I can think of various scripting solutions (that would rename the processor-appropriate version to NeoOffice the first time someone launches it, for example), but they're still going to make more work in preparing the clone master, and I get that you're not going to want to do that just for the one app.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
