Hi Scott,

Am 10.02.2006 um 20:27 schrieb Scott:

I am attempting to build GIMP 2.3.7 on an Intel IMac. The configure goes
fine, however when I run make I get an error. The following is the tail
end of the output:

sorry, can't help with that, I'm still waiting for my new machine (MacBook).
How did you try to compile this? I mean, are there fink or darwinports or something like that involved or how did you satisfy all the dependencies of GIMP?

lexA ---
Live is like a chocolate box, you never know what you wanna get... GPG Signatur auf http://wernicke-online.net/Impressum/ prüfen

Am 10.02.2006 um 21:15 schrieb Scott:

So far I have compiled them all from source.. Since I am new to Mac's I am
not sure how to package them yet for easy install.. Otherwise I would make
what I have done thus far available on my site.

Well, there are lots of dependencies like gtk+ 2.8.8. So did you build anything of that already by yourself? On PPC I built gimp up to 2.3.5 with fink support - meaning fink did all the packages gimp depends on and for gimp itself i wrote a so called info file which tells fink how to build gimp. Unfortunately for GIMP 2.3.6 this didn't work because of an glib problem (IIRC) and to build GIMP 2.3.7 failes due to a not availability of gtk+ 2.8.8 on fink.

Once I figure out this GIMP issue then I will probably address packaging
them up. So far everything else has had no issues using the standard compile process.

Packaging on OS X is a bit complicated, because of the dependencies. So far there are two projects I know of, that provide a packaging system for OS X ( fink.sf.net and darwinports.org) and one project that provides a prebuild gimp application (gimp.app). gimp.app might even provide x86 code ?!

Unfortunately versions are a bit behind time sometimes (fink 2.0.6, darwinports 2.2.10, gimp.app 2.2.9 (?) ) and unfortunately none of them provides 2.3.x builds.

Fink and folks do not have Intel versions available yet, and I did not want to run in non-native mode.

neither fink nor darwinports provide lots of binaries. They just tell you dependencies, where to get the sources from and how to compile. So booth compile locally, which means they should lead to native binaries (in booth ways).
darwinports.org claims that their packages should build on x86 with no probs, fink is is some kind of translation process right now.

Let me know about your next steps. I'd be very interested in knowing how to get a 2.3.7 for the new Book.

lexA

Scott

---
Live is like a chocolate box, you never know what you wanna get... GPG Signatur auf http://wernicke-online.net/Impressum/ prüfen

On Fri, Feb 10, 2006 at 02:27:42PM -0500, Scott wrote:

gimp-composite-sse.c: In function 'gimp_composite_scale_rgba8_rgba8_rgba8_sse': gimp-composite-sse.c:786: error: PIC register '%ebx' clobbered in 'asm' make[3]: *** [libcompositesse_a-gimp-composite-sse.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

-----------------------------------------------------

I then can seem to run a make install, but there is no gimp executable. Only gimp-remote seems to get installed. Can someone perhaps lead me in the right direction with this?

recently there was the same problem with mmx. if you run ./configure --help it will tell you how to build without this sse stuff. these are some "optimizations" that were included by some guy from Sun and seem to be unmaintained lately.

if you are using apple products, you probably are not interested in speed so probably building without that stuff will not seem to hurt performance.

carol

Am 10.02.2006 um 23:32 schrieb Carol Spears:

if you are using apple products, you probably are not interested in speed so probably building without that stuff will not seem to hurt performance.

couldn't you've been simply nice and friendly?

Since he tries to build GIMP for the new Intel Macs he's proven to care about performance anyway :)

lexA

carol

On Fri, Feb 10, 2006 at 11:49:09PM +0100, Axel Wernicke wrote:

Am 10.02.2006 um 23:32 schrieb Carol Spears:

if you are using apple products, you probably are not interested in speed so probably building without that stuff will not seem to hurt performance.

couldn't you've been simply nice and friendly?

Since he tries to build GIMP for the new Intel Macs he's proven to care about performance anyway :)

could you assume for a moment that i was being nice and friendly?

after a while, when people suggest that you are not being nice and not being friendly when you are, you start to wonder if the person suggesting this is being friendly and is being nice.

do people run apple because it is really fast? i am sorry if i got this wrong. i thought they run apple because the products are so sealed up and lovely to look at and the fellow users are so united in thinking. the only apple products i have had opportunity to work with are really slow or in need of a huge network of other apples in which to be able to function on.

if anyone were to suggest that i am using my computer because speed is not an issue, i would probably have to agree.

carol

Am 11.02.2006 um 05:43 schrieb Scott:

recently there was the same problem with mmx. if you run ./configure --help it will tell you how to build without this sse stuff. these are
some "optimizations" that were included by some guy from Sun and seem to
be unmaintained lately.

I ran it with --disable-mmx, now ld does not support the -rpath switch on
OS X. And there does not seem to be an option to disable it in the configure, at least that I found .

Thats the one I got on PPC since 2.3.6! Folks at IRC told me that this would be an issue outside of GIMP, so I gave up for a while :(

But this Imac is the 2.0 DC w/1gb of RAM. Under normal usage it runs nicely, it does seem to stumble sooner under high load then my Sun Ultra
20 (opteron) does. But, generally speaking it is a good performer..

sounds like outperfoming my iBook 800 will be an easy job for the MacBook Pro :)

Thanks for all your help..

Scott

Greetings, lexA

..on Sat, Feb 11, 2006 at 09:14:39AM -0500, Scott wrote:

The MacBook Pro will out perform in power save mode!

hmm, i wouldn't believe everything Steve tells you.. you know what he's like ;)

let's just hope Apple doesn't deliberately throttle OSX quite as much this time to boost hardware sales. memory management in OSX Tiger seems really poor. this seems to explain some of it..

http://www.anandtech.com/mac/showdoc.aspx?i=2436&p=2

julian

Am 11.02.2006 um 15:14 schrieb Scott:

Am 11.02.2006 um 05:43 schrieb Scott:

recently there was the same problem with mmx. if you run ./ configure
--help it will tell you how to build without this sse stuff. these are
some "optimizations" that were included by some guy from Sun and seem to
be unmaintained lately.

I ran it with --disable-mmx, now ld does not support the -rpath switch on
OS X. And there does not seem to be an option to disable it in the configure, at least that I found .

Thats the one I got on PPC since 2.3.6! Folks at IRC told me that this would be an issue outside of GIMP, so I gave up for a while :(

My research indicates this is an issue with GIMP and not something outside
of it. I came across another program with this issue that the programmer
fixed after the users created enough noise.

I unfortunately forgot the url, but one of the users went round and round
with the developer because originally he was not going to fix it. He used
the "it is an issue outside" also, for which the users started calling him
arrogant for having that mentality.

I am sure I will eventually fix GIMP or come up with a work around, at which point I will forward the info on for your consumption.

so, may be we should kick this issue to GIMP-dev and ask for help. May be even a bug should filed for this?

Hopefully somebody can bring some light into this.

!lexA

Scott

---
Live is like a chocolate box, you never know what you wanna get... GPG Signatur auf http://wernicke-online.net/Impressum/ prüfen

Scott wrote:

sounds like outperfoming my iBook 800 will be an easy job for the MacBook Pro :)

The MacBook Pro will out perform in power save mode!

So it is another device that just switches on the "power save" LED and continues to consume the same amount of power? :)

Michael

On Fri, Feb 10, 2006 at 11:43:55PM -0500, Scott wrote:

On Fri, Feb 10, 2006 at 02:27:42PM -0500, Scott wrote:

gimp-composite-sse.c: In function 'gimp_composite_scale_rgba8_rgba8_rgba8_sse': gimp-composite-sse.c:786: error: PIC register '%ebx' clobbered in 'asm' make[3]: *** [libcompositesse_a-gimp-composite-sse.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

-----------------------------------------------------

I then can seem to run a make install, but there is no gimp executable. Only gimp-remote seems to get installed. Can someone perhaps lead me in the right direction with this?

recently there was the same problem with mmx. if you run ./configure --help it will tell you how to build without this sse stuff. these are some "optimizations" that were included by some guy from Sun and seem to be unmaintained lately.

I ran it with --disable-mmx, now ld does not support the -rpath switch on OS X. And there does not seem to be an option to disable it in the configure, at least that I found .

i took a few seconds and ran ./autogen.sh --help and i found an option to --enable-sse enable SSE support (default=auto)

this is what the error message complained about. the error message did not complain about mmx although, i think that disabling it should not have messed up -rpath.

i am sorry if using mmx as a suggestion to look for sse configuration options was confusing.

carol

Am 11.02.2006 um 19:35 schrieb Carol Spears:

On Fri, Feb 10, 2006 at 11:43:55PM -0500, Scott wrote:

I ran it with --disable-mmx, now ld does not support the -rpath switch on
OS X. And there does not seem to be an option to disable it in the configure, at least that I found .

i took a few seconds and ran ./autogen.sh --help and i found an option to --enable-sse enable SSE support (default=auto)

this is what the error message complained about. the error message did
not complain about mmx although, i think that disabling it should not have messed up -rpath.

i am sorry if using mmx as a suggestion to look for sse configuration options was confusing.

carol

indeed the -rpath problem is completely not related to the SSE issue. I'm on PPC ( no SSE at all) and have the -rpath issue since GIMP 2.3.6

in hope for help

lexA

On Sat, Feb 11, 2006 at 07:42:12AM +0100, Axel Wernicke wrote:

Am 11.02.2006 um 00:41 schrieb Carol Spears:

could you assume for a moment that i was being nice and friendly?

after a while, when people suggest that you are not being nice and not being friendly when you are, you start to wonder if the person suggesting this is being friendly and is being nice.

do people run apple because it is really fast? i am sorry if i got this
wrong. i thought they run apple because the products are so sealed up and lovely to look at and the fellow users are so united in thinking. the only apple products i have had opportunity to work with are really slow or in need of a huge network of other apples in which to be able to
function on.

if anyone were to suggest that i am using my computer because speed is not an issue, i would probably have to agree.

=:)

actually, i have been corrected on a few things. a hacker voluntarily read apple advertising to me. i guess that ppc was 4times faster than intel and now this new thing is 4times faster than ppc. i have no idea how to do the maths with this new information. how long before this fine boxen are overtaking the speed of light itself?

carol

..on Sat, Feb 11, 2006 at 05:27:36PM -0500, Scott wrote:

Actually the Intel version are faster IF your application is not running in emulation mode. That being said, there are not a lot of applications that are nativly supporting the Intel chip. Which is the primary reason I want to compile GIMP.

I will say this IMac is faster then my P4 3ghz Suse Linux box at work when I am using applications that are native.

4x faster is unrealistic, I would say maybe 1.5 - 2x's faster then the G5.

i guess i'm getting off topic here, but out of interest which (native) applications do you have on both SuSE and the IntelMac to compare their respective performance? very few of us have played with the IntelMac so i'm sure there'd be a few interested to know which applications are faster on which platform.

julian

On 2/11/06, Axel Wernicke wrote:

Am 11.02.2006 um 15:14 schrieb Scott:

Am 11.02.2006 um 05:43 schrieb Scott:

I ran it with --disable-mmx, now ld does not support the -rpath switch on
OS X. And there does not seem to be an option to disable it in the configure, at least that I found .

So am I to take it that this is an issue with libtool on OS X? Does it work with newer/older versions of libtool? Is this problem specific to MacOS on x86?

Rockwalrus

On Sun, Feb 12, 2006 at 06:05:14PM -0500, Scott wrote:

..on Sat, Feb 11, 2006 at 05:27:36PM -0500, Scott wrote:

Actually the Intel version are faster IF your application is not running in emulation mode. That being said, there are not a lot of applications that are nativly supporting the Intel chip. Which is the primary reason I
want to compile GIMP.

I will say this IMac is faster then my P4 3ghz Suse Linux box at work when
I am using applications that are native.

4x faster is unrealistic, I would say maybe 1.5 - 2x's faster then the G5.

i guess i'm getting off topic here, but out of interest which (native) applications do you have on both SuSE and the IntelMac to compare their respective performance? very few of us have played with the IntelMac so
i'm sure there'd be a few interested to know which applications are faster on which platform.

At present GIMP 2.3.5, as anything newer will not compile due to rpath. OpenOffice, Firefox, and Thunderbird. Sadly the GIMP 2.2.10 package, which I think is PPC (gimp.org) performs better then my GIMP on my Suse box. And that is using Rosetta, or whatever the hell they call it.

There are various other small OSS installed, but mostly in support of the above applications. On most things my compile times are shorter, however on the Mac I do make -j3 and my Linux box a -j2.

Considering that you're not comparing it on the same hardware, this isn't at all valid.

Linux is quite a bit faster given the same hardware than OS X. That's the original point: if you're running OS X, you're not really caring about raw speed.

-Yosh

On Sat, Feb 11, 2006 at 03:42:56PM +0100, Axel Wernicke wrote:

Am 11.02.2006 um 15:14 schrieb Scott:

I am sure I will eventually fix GIMP or come up with a work around, at which point I will forward the info on for your consumption.

so, may be we should kick this issue to GIMP-dev and ask for help. May be even a bug should filed for this?

Hopefully somebody can bring some light into this.

As I told you on IRC, engage the libtool people about it. Unless you feel like donating a decent OS X 10.4 machine to a developer, this isn't going to be fixed by just sitting around and whining for it to happen.

You want it fixed, and you're the one who has access to the platform for testing and investigation, so you have to do some legwork.

-Yosh

..on Mon, Feb 13, 2006 at 11:48:34AM -0800, Manish Singh wrote:

At present GIMP 2.3.5, as anything newer will not compile due to rpath. OpenOffice, Firefox, and Thunderbird. Sadly the GIMP 2.2.10 package, which I think is PPC (gimp.org) performs better then my GIMP on my Suse box. And that is using Rosetta, or whatever the hell they call it.

There are various other small OSS installed, but mostly in support of the above applications. On most things my compile times are shorter, however on the Mac I do make -j3 and my Linux box a -j2.

Considering that you're not comparing it on the same hardware, this isn't at all valid.

Linux is quite a bit faster given the same hardware than OS X. That's the original point: if you're running OS X, you're not really caring about raw speed.

before i took OSX off the G5 altogether i performed a few amatuer benchmarks of my own, between Ubuntu and OSX using 'time' and simply logging system load.

the one area i could determine in which OSX clearly has Ubuntu PPC nailed was that of ripping and encoding DVD's. what would take 70m on Ubuntu would take around 45 mins in OSX with both the same codec and container targets.

this was regardless of the fact that Ubuntu had DMA enabled for both the HDD and the DVD.

strangely encoding from DV to a theora target was around 20% faster in Ubuntu. 3D performance with either the stock FOSS ati driver, or ATI's FGLRX was much much better in Ubuntu i used Quake3 Arena and rendering the same scene using Blender/Yafray on both OS's. this may be due to the fact OSX hits the GPU for fast blitting (the OSX interface can be thought of as an OpenGL scene).

mixing 8 identical tracks down to one stereo track in audacity was around a third faster in Ubuntu, as was network performance generally (that i found very strange and never did get to the bottom of).

can't wait to see how Linux looks on a Core Duo..

julian