IBM

ritchan wrote:

sybrfreq wrote: Right, I've never heard about that website before but "the license was easy to crack and therefore the software is crap" means I won't bother with it again.

Huh? Do you realize you're doing the same thing as he did?

Yes I realize I am saying the same thing as bri3d. You might say I am agreeing with him.

Regarding the ELF/XCOFF thing. The original post was refering to XLC10 on Linux, hence the ELF library. On AIX with XLC9 it's an 'ar' library with a single XCOFF 'shr.o' shared object.

sybrfreq wrote:

ritchan wrote:

sybrfreq wrote: Right, I've never heard about that website before but "the license was easy to crack and therefore the software is crap" means I won't bother with it again.

Huh? Do you realize you're doing the same thing as he did?

Yes I realize I am saying the same thing as bri3d. You might say I am agreeing with him.

No, you just exemplified what he was talking about here:

I wonder why the author remarks that because IBM's DRM is bad, their compiler must be bad as well though - it's a foolish generalization and discards most real-world facts about software licensing.

ritchan wrote: No, you just exemplified what he was talking about here:

I wonder why the author remarks that because IBM's DRM is bad, their compiler must be bad as well though - it's a foolish generalization and discards most real-world facts about software licensing.

Naah, it's ambiguous pronoun reference - the "it" he was referring to was the blog, not the compiler.

correct.

Anyways, my point was pretty much moot anyways. A person buying the program or switching to an alternative when the trial is over? Crazy!

@porter: would you be so kind to provide me the source of x.c? i'm such a shitty developer so my efforts leading nowwhere without guidance

Alas my 7043-240 died a year or so ago. My recollections are although the module compiled and didn't stop XLC working, it still broke after the 90 days. I ended up just resetting the machines time back for XLC compilations.

Candidly, there is no longer any performance gulf of substance between xlC and gcc anyway. xlC may be able to better optimize some types of code, and its vectorization is probably better, but on the whole its drawbacks far outweigh any small performance gains you'd see.

edit: content removed

First of all, I would work on the object file (shr.o), not the archive.

Then, you've disassembled everything, including the relevant data structure, as code . Good luck interpreting that as PPC instructions

Last but not least, regardless of the totally trivial protection mechanism of the IBM compiler, 'circumventing a copyright protection' is *illegal* in many parts of the world, including the US and Europe. I would hate to see this board go away because of the wrath of some IBM lawyer.

you're right, will remove this post...

LD_PRELOAD is often used to emend the runtime behavior of such libraries. The advantage here is that you don't need to reverse engineer the target library much at all. Just dl_load it under a different name, call it, and fiddle with the return value all you want.

ClassicHasClass wrote: ...there is no longer any performance gulf of substance between xlC and gcc anyway.

When I read this bit in Mendoza's UNIX to Linux Porting: A Comprehensive Reference , I was surprised that XLC made so much use of the GNU resources.

...the XL C/C++ compilers employ the same GNU libraries, linker, assembler, and binutils as GCC...optimization routines have been developed for and tailored to the POWER architecture. High-performance computing applications, especially those heavily reliant on floating-point operations, often benefit significantly from a simple recompile with XL C/C++.