Posted: Mon Jun 13, 2005 8:03 am Post subject: OS version and compiling
psudo random question (more out of curiousity than anything)
how does the version of the OS that the progam is compiled on affect its performance?
I know you cannot go backwards (i.e. compile 10.4 -> run on 10.2) but would a version of Neo/J compiled on 10.3 run better on 10.3 than the 10.2 compiled one?
this is just me being curious, most of my programming ability (minus some dabbling in Java in college) is interpreted languages, not compiled ones, so i don't know much about how the compling process affects the final product.
Sadly, Patrick this is definately not true. I've been trying to build NeoOffice/J and OOo-MacOSX-X11 for over a month now. Success eludes me. I've asked for help. Remember, we were all 'newbies' once and I have a long programming background. I have tested and found errors in both OOo and Neo/J which either were fixed or disappeared with the next patch. However, I want to build Neo/J to see if it can be done. And I have reset my system to what should work. Oh well....
Sadly, Patrick this is definately not true. I've been trying to build NeoOffice/J and OOo-MacOSX-X11 for over a month now. Success eludes me. I've asked for help. Remember, we were all 'newbies' once and I have a long programming background. I have tested and found errors in both OOo and Neo/J which either were fixed or disappeared with the next patch. However, I want to build Neo/J to see if it can be done. And I have reset my system to what should work. Oh well....
Huh? My statement that compiling on a new OS version won't make Neo/J faster is not true? I don't understand how the fact that OOo doesn't compile on Tiger disproves my statement.
Sadly, Patrick this is definately not true. I've been trying to build NeoOffice/J and OOo-MacOSX-X11 for over a month now. Success eludes me. I've asked for help. Remember, we were all 'newbies' once and I have a long programming background. I have tested and found errors in both OOo and Neo/J which either were fixed or disappeared with the next patch. However, I want to build Neo/J to see if it can be done. And I have reset my system to what should work. Oh well....
pluby wrote:
Huh? My statement that compiling on a new OS version won't make Neo/J faster is not true? I don't understand how the fact that OOo doesn't compile on Tiger disproves my statement.
Patrick:
Let me clarify my point: Neo/J may work better on Tiger than on Panther or Jaguar, but it will NOT build on Tiger in its present state. I am downloading the RC (again) and will patch it to the current version. I found that OOo 1.9M109 runs faster in Tiger than did 1.1.4 built for Panther. This should also translate to a 'faster' Neo/J. Again, this does not reflect on the Neo/J team nor yourself.
Let me clarify my point: Neo/J may work better on Tiger than on Panther or Jaguar, but it will NOT build on Tiger in its present state. I am downloading the RC (again) and will patch it to the current version. I found that OOo 1.9M109 runs faster in Tiger than did 1.1.4 built for Panther. This should also translate to a 'faster' Neo/J. Again, this does not reflect on the Neo/J team nor yourself.
You are mixing apples and oranges. Yes, OOo 1.9M109 runs faster than OOo 1.1.4 because Sun's engineers rewrote lots of the OOo code in 1.9 so that it would run faster. This is not some OS compiling voodoo. This is just code refactoring.
Recompiling OOo 1.1.4 on Panther or Tiger won't make a difference per se because you are using 1) the same code and 2) the same compiler. The same compiler run with the same options against the same code will, in general, generate the same machine code.
The issue that you have with building is not rocket science but the normal hurdles that any large C/C++ project when porting to a newer OS version. Some are:
1. Header files or libraries have moved or been renamed so the compiler can't find them.
2. Conflicting copies of header files have been added to the OS and the compiler is picking up those new header files instead of the ones that you expect (hint: STL).
3. Conflicting function names have been added to OS libraries so the linker can't link.
In sum, OOo 1.1.4 does not build on Tiger. Why? Because OOo 1.1.4 predates Tiger by almost a year and, from what I have seen of Ed's recent posting, item #2 has occurred in Tiger.
I'll be blunt here. If you can't build it, then you have two choices: 1) spend the time to figure out what is wrong and submit a patch or 2) wait until someone else fixes it.
Please don't be offended, but if you choose option 2, don't complain to me as my feeling is that if you are having trouble fixing C/C++ build errors, the likelihood that you will be a productive code contributor to OOo or Neo/J is fairly small.
Again, the OOo code is not easy to compile or port to a new platform. That has been known for a long time and, unless Sun's engineers decide to rewrite the build system from scratch, is not likely to change.
Let me clarify my point: Neo/J may work better on Tiger than on Panther or Jaguar, but it will NOT build on Tiger in its present state. I am downloading the RC (again) and will patch it to the current version. I found that OOo 1.9M109 runs faster in Tiger than did 1.1.4 built for Panther. This should also translate to a 'faster' Neo/J. Again, this does not reflect on the Neo/J team nor yourself.
pluby wrote:
You are mixing apples and oranges. Yes, OOo 1.9M109 runs faster than OOo 1.1.4 because Sun's engineers rewrote lots of the OOo code in 1.9 so that it would run faster. This is not some OS compiling voodoo. This is just code refactoring.
I agree with this. If you rewrite some of the code, then those segments will run better.
pluby wrote:
Recompiling OOo 1.1.4 on Panther or Tiger won't make a difference per se because you are using 1) the same code and 2) the same compiler. The same compiler run with the same options against the same code will, in general, generate the same machine code.
It should. However, I lived through the Microsoft mantra of
"DOS is not done until Lotus will not run." This appears to be the same thing with MacOSX. I don't like this. If you can build a better 'mouse trap' then do so and put it on the market, not eliminate the entire market by nuking the mice.
pluby wrote:
The issue that you have with building is not rocket science but the normal hurdles that any large C/C++ project when porting to a newer OS version. Some are:
1. Header files or libraries have moved or been renamed so the compiler can't find them.
Exactly. I'm running into this problem with OOo1.9 and required libraries. It is very interesting when the ./configure file cannot find a header file in the appropriate directory (/usr/include). That is what I consider a serious bug.
pluby wrote:
2. Conflicting copies of header files have been added to the OS and the compiler is picking up those new header files instead of the ones that you expect (hint: STL).
I think there is an IZ for this and it appears to be fixed, but I could be wrong.
[quote="pluby"]3. Conflicting function names have been added to OS libraries so the linker can't link. [\quote]
That one really gets me. Why can't you name the new function with a new name? It is not that hard.
Quote:
In sum, OOo 1.1.4 does not build on Tiger. Why? Because OOo 1.1.4 predates Tiger by almost a year and, from what I have seen of Ed's recent posting, item #2 has occurred in Tiger.
But it appears that 1.1.5 will. I think all efforts on 1.1.4 are resting on one or two shoulders whereas 1.9 has the attention of Sun.
pluby wrote:
I'll be blunt here. If you can't build it, then you have two choices: 1) spend the time to figure out what is wrong and submit a patch or 2) wait until someone else fixes it.
Ok. I'll agree with 1 above, but I really don't want to duplicate efforts of others. I feel that working as a team is much better than a bunch of individuals. I like the teamwork that I see between Ed, Smokey and yourself.
Also, this breaks building Neo/J on Tiger too. Of course, you are using Jaguar/Panther to build on.
pluby wrote:
Please don't be offended, but if you choose option 2, don't complain to me as my feeling is that if you are having trouble fixing C/C++ build errors, the likelihood that you will be a productive code contributor to OOo or Neo/J is fairly small.
I'm not offended. I just stating that I'm having problems building one of the required packages to build OOo/NeoJ. It is definately NOT a c/C++/Java/Python code problem, but just a plain old script error. This is what bothers me.
pluby wrote:
Again, the OOo code is not easy to compile or port to a new platform. That has been known for a long time and, unless Sun's engineers decide to rewrite the build system from scratch, is not likely to change.
Sometimes a complete rewrite is what is needed. However, I don't think that Sun will dedicate the necessary resources to rewrite OO from the ground up. This in no way reflects what is happening with NeoJ, as you have to take what they give you and add to it. Of course, you could always make your patches available here (I know that they were given to the base OO project and I applaud your efforts).
BTW, if you want I can e-mail you off of the list with the problem I have and see what you think about it. As I said, it is a basic script fault and that is very frustrating. And this one is definately not Sun's or the OO project's fault.
Exactly. I'm running into this problem with OOo1.9 and required libraries. It is very interesting when the ./configure file cannot find a header file in the appropriate directory (/usr/include). That is what I consider a serious bug.
This is why porting work is so tedious. What works on Linux (i.e. what most OOo developers are using) doesn't necessarily work on Mac OS X since Apple likes to "think different" put things in different places than most other Unix platforms.
jjmckenzie51 wrote:
That one really gets me. Why can't you name the new function with a new name? It is not that hard.
In theory, it is easy. However, in projects like OOo, many open source projects are pulled in and since those projects were probably developed in Linux or Windows, it is easy to see how simple function names can exist in an open source project and Mac OS X. More often than not, the duplicate symbols are for the software package but the OS has a different version of the library and OOo depends on one specific version. This seems to happen a lot with the STL.
jjmckenzie51 wrote:
I'm not offended. I just stating that I'm having problems building one of the required packages to build OOo/NeoJ. It is definately NOT a c/C++/Java/Python code problem, but just a plain old script error. This is what bothers me.
But remember, you and Ed are the only ones who are trying to compile OOo 1.1.4 on Tiger. I don't think it is realistic to expect Linux and Windows developers to accurately guess what is different on your platform especially when your platform is not that the OOo site supports.
jjmckenzie51 wrote:
BTW, if you want I can e-mail you off of the list with the problem I have and see what you think about it. As I said, it is a basic script fault and that is very frustrating. And this one is definately not Sun's or the OO project's fault.
I would suggest that you create a "building on Tiger" topic in the NeoOffice/J Development forum so that you and Ed can your Tiger build issues as I do not have a Tiger machine and so guessing at what is different in Tiger is not going to be a good use of either of our time. Ed has been trying to compile on Tiger and has already committed and STL fix for the OOo code about a week ago.
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
