1.2 crashes on fresh Tiger system

[alexcurylo]

So I updated my application to use 1.2, and just got my first report
from a user running Tiger who had not previously installed a 1.1.x
version.

What happens in that instance is it crashes on launch.

Library not loaded: @executable_path/../Frameworks/Growl-
WithInstaller.framework/Versions/A/Growl-WithInstaller
Referenced from: /Applications/Play MPE Player.app/Contents/MacOS/
Play MPE Player
Reason: no suitable image found. Did find:
/Applications/Play MPE Player.app/Contents/MacOS/../Frameworks/Growl-
WithInstaller.framework/Versions/A/Growl-WithInstaller: unknown
required load command 0x8000001F
/Applications/Play MPE Player.app/Contents/MacOS/../Frameworks/Growl-
WithInstaller.framework/Versions/A/Growl-WithInstaller: unknown
required load command 0x8000001F

Any suggestions what to do about that?

[Chris Forsythe]

You're using the with-installer framework right?

Chris

> --
>
> You received this message because you are subscribed to the Google
> Groups "Growl Discuss" group.
> To post to this group, send email to growld...@googlegroups.com.
> To unsubscribe from this group, send email to growldiscuss...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en
> .
>
>

[Laurent Daudelin]

Hmmm.. the infamous unknown required load command. If I recall correctly, this has to do with the library being compiled in 10.6 without having the directive to the linker that it can be used on 10.5. In 10.6, the linker is apparently compressing the segment loader of dynamic libraries but those compressed segments are unrecognized under 10.5. The compilation has to had to the LDFLAGS something like mmacosx-version-min=10.4 (or mmacosx-version-min=10.5, depending). I've ran into similar issues while trying to compile open source dynamic libraries and that fixed it, although for me the message was slightly different: unknown required load command 0x80000022. Looks pretty close, though.

-Laurent.

-- 

Laurent Daudelin

AIM/iChat/Skype:LaurentDaudelin  http://nemesys.dyndns.org

Logiciels Nemesys Software               laurent....@gmail.com

Photo Gallery Store: http://laurentdaudelin.shutterbugstorefront.com/g/galleries

[alexcurylo]

On Nov 26, 8:25 pm, Chris Forsythe <ch...@growl.info> wrote:
> You're using the with-installer framework right?

Quite sure, as the error shows "Did find: ... /Frameworks/Growl-
WithInstaller.framework/..."

[Chris Forsythe]

I'd assume you would know for sure since you said that you put out the
application.

I saw that but wanted to confirm before I update my 10.4 box to the
latest version of 10.4 and then try reproducing with your app. What is
your app anyhow?

Chris

[alexcurylo]

On Nov 26, 8:56 pm, Chris Forsythe <ch...@growl.info> wrote:
>
> I'd assume you would know for sure since you said that you put out the  
> application.

Oh, I never trust what I think my code does until I see an actual
crash report...

> > I saw that but wanted to confirm before I update my 10.4 box to the  
> latest version of 10.4 and then try reproducing with your app. What is  
> your app anyhow?

Pre-release music distribution.

http://plaympe.com/

[alexcurylo]

On Nov 26, 8:56 pm, Chris Forsythe <ch...@growl.info> wrote:
> I saw that but wanted to confirm before I update my 10.4 box to the  
> latest version of 10.4 and then try reproducing with your app.

Hmmm ... I see they've pulled the crashing version from the website,
so if you really want to reproduce with it email me.

[Chris Forsythe]

Oh you don't make this application? If so can you mail them and ask
them to contact us if they're having problems with it?

Chris

[alexcurylo]

On Nov 26, 10:20 pm, Chris Forsythe <ch...@growl.info> wrote:
>
> Oh you don't make this application?

I build it on contract. I don't control what they put up on their
website. Which, understandably enough, is currently the last version
that doesn't crash, which includes 1.1.6.

> If so can you mail them and ask  
> them to contact us if they're having problems with it?

They would tell you to get the crashing version from me.

[Chris Forsythe]

On Nov 27, 2009, at 12:26 AM, alexcurylo wrote:

>
>
> On Nov 26, 10:20 pm, Chris Forsythe <ch...@growl.info> wrote:
>>
>> Oh you don't make this application?
>
> I build it on contract. I don't control what they put up on their
> website. Which, understandably enough, is currently the last version
> that doesn't crash, which includes 1.1.6.

Fair enough. Do you also modify the code on contract? If so that's
what we'd need anyhow, possibly. Do you have a 10.4 test system? I
have a 10.4 system if you do not.

Chris

[alexcurylo]

On Nov 26, 10:38 pm, Chris Forsythe <ch...@growl.info> wrote:
>
> Fair enough. Do you also modify the code on contract? If so that's  
> what we'd need anyhow, possibly.

Yes, I'm the one that does all the Mac development.

> Do you have a 10.4 test system? I  
> have a 10.4 system if you do not.

On my lone Tiger system it starts up fine. It is a PowerPC, though,
and the crashing system is Intel, which perhaps is significant. I
don't have any Tiger-capable Intel machines available to explore that.

I also see that other people have also run into this same exact
problem; which you can find in the thread I started about upgrading to
1.2, no less.

http://www.cocoaforge.com/viewtopic.php?f=6&p=121752

[Chris Forsythe]

On Nov 27, 2009, at 12:53 AM, alexcurylo <al...@alexcurylo.com> wrote:

> On Nov 26, 10:38 pm, Chris Forsythe <ch...@growl.info> wrote:
>>
>> Fair enough. Do you also modify the code on contract? If so that's
>> what we'd need anyhow, possibly.
>
> Yes, I'm the one that does all the Mac development.

Good, the ability to work with us directly and recompile is a good
thing. :)

>
>> Do you have a 10.4 test system? I
>> have a 10.4 system if you do not.
>
> On my lone Tiger system it starts up fine. It is a PowerPC, though,
> and the crashing system is Intel, which perhaps is significant. I
> don't have any Tiger-capable Intel machines available to explore that.
>

I have a mbp that might be able to run it, but it's got a busted
SuperDrive which makes things not fun.

My test box is also ppc

> I also see that other people have also run into this same exact
> problem; which you can find in the thread I started about upgrading to
> 1.2, no less.
>
> http://www.cocoaforge.com/viewtopic.php?f=6&p=121752
>

[Rudy Richter]

since peter hasn't chimed in on this thread yet i'll clarify several
problems.

problem 1:
The 1.2 frameworks as originally shipped do not work on 10.4. this is
supposed to be resolved in the 1.2.1 framework

problem 2:
The 1.2 WithInstaller framework does not check the running OS to
determine what version its being run under, so if the user doesn't
have Growl installed on 10.4, the WithInstaller isn't going to install
1.1.6 (the last 10.4 compat release). afaik the way the code is now
WithInstaller would attempt to install 1.2. http://code.google.com/p/growl/issues/detail?id=50

chris, i think we should accelerate the WithInstaller evisceration
plan as documented in the wiki prior to 1.3.

-rudy

On Nov 27, 10:31 am, Chris Forsythe <ch...@growl.info> wrote:

[Evan Schoenberg, M.D.]

On Nov 27, 2009, at 6:36 PM, Rudy Richter <rari...@gmail.com> wrote:

> since peter hasn't chimed in on this thread yet i'll clarify several
> problems.
>
> problem 1:
> The 1.2 frameworks as originally shipped do not work on 10.4. this is
> supposed to be resolved in the 1.2.1 framework
>
> problem 2:
> The 1.2 WithInstaller framework does not check the running OS to
> determine what version its being run under, so if the user doesn't
> have Growl installed on 10.4, the WithInstaller isn't going to install
> 1.1.6 (the last 10.4 compat release). afaik the way the code is now
> WithInstaller would attempt to install 1.2. http://code.google.com/p/growl/issues/detail?id=50
>
> chris, i think we should accelerate the WithInstaller evisceration
> plan as documented in the wiki prior to 1.3.

I have started the new withInstaller implementation locally. Next week
I'll have it decent enough to commit in a branch. I'll need some
serverside support to implement the plan: i'd like a PHP file that
redirects to the appropriate current installation ZIP file (the
prefpane) based on either header sniffing or a passed argument.

-Evan

[alexcurylo]

On Nov 27, 3:36 pm, Rudy Richter <rarich...@gmail.com> wrote:
> since peter hasn't chimed in on this thread yet i'll clarify several
> problems.
>
> problem 1:
> The 1.2 frameworks as originally shipped do not work on 10.4. this is
> supposed to be resolved in the 1.2.1 framework

OK, I downloaded the source (e7d9d4a57253) to test this, and I can't
build the Growl-WithInstaller.framework target because I don't have a
Growl code-signing certificate so GrowlHelperApp won't build. I
presume that someone with authority has to make a distributable build
of Growl-WithInstaller.framework then? Or is there one kicking around
somewhere that I've missed?

[Peter Hosey]

On Nov 27, 2009, at 15:36:21, Rudy Richter wrote:
> The 1.2 WithInstaller framework does not check the running OS to

> determine what version its being run under…

Yes it does. It checks for 10.3, not 10.5, but it does check.

The solution to that is simple: Update the check.

[Peter Hosey]

On Nov 27, 2009, at 16:32:32, alexcurylo wrote:
> I can't build the Growl-WithInstaller.framework target because I
> don't have a Growl code-signing certificate so GrowlHelperApp won't
> build.

You should be able to build in the Debug configuration.

[Peter Hosey]

On Nov 27, 2009, at 18:55:09, Peter Hosey wrote:
> Update the check.

Done in [2f99d2f175f4]. Version 1.2.1 of the framework will not ask to
install Growl on Tiger (or Panther).

[Rudy Richter]

I meant to say that WithInstaller has no code to conditionally install
0.7.6 or 1.1.6 or 1.2 based on the running OS.

-rudy

[Evan Schoenberg, M.D.]

On Nov 28, 2009, at 9:57 AM, Rudy Richter wrote:

> I meant to say that WithInstaller has no code to conditionally install
> 0.7.6 or 1.1.6 or 1.2 based on the running OS.

Right.

Rudy, could you please create a:
http://growl.info/growl_download_for_framework.php
which redirects to a Growl.prefPane.zip of the current version for the querying OS? I ask since the website was previously made to do this detection, so I figure you already know what needs doing. I'll be sending NSURLDownload that direction in the new Growl.framework's installation routines.

Cheers,
Evan

>
> -rudy
>
> On Nov 27, 9:55 pm, Peter Hosey <p...@growl.info> wrote:
>> On Nov 27, 2009, at 15:36:21, Rudy Richter wrote:
>>
>>> The 1.2 WithInstaller framework does not check the running OS to
>>> determine what version its being run under…
>>
>> Yes it does. It checks for 10.3, not 10.5, but it does check.
>>
>> The solution to that is simple: Update the check.
>

[Chris Forsythe]

This caused the reported crasher?

[Rudy Richter]

Nope, the way it was built caused the crash (the build settings were
only building a 10.4 compat framework for the debug build
configuration).

The side discussion of the replacement for WithInstaller is what the
next discussion would be, that WithInstaller doesn't install Growl on
10.4.

-rudy

On Nov 28, 5:48 pm, Chris Forsythe <ch...@growl.info> wrote:
> This caused the reported crasher?
>

[BJ Homer]

Is there an ETA on the 1.2.1 framework? I don't need an exact date,
certainly, but is it something we're looking at on a this-week
timeframe or a next-month timeframe? I'm working on a product that
supports 10.4-10.6, and I want to want to compile 64-bit where
possible. My understanding is that the 1.1.6 framework was not 64-bit
clean.

Just trying to figure out if this is going to affect our shipping date
or not. Thanks for all the work!

-BJ

On Nov 27, 4:36 pm, Rudy Richter <rarich...@gmail.com> wrote:
> since peter hasn't chimed in on this thread yet i'll clarify several
> problems.
>
> problem 1:
> The 1.2 frameworks as originally shipped do not work on 10.4. this is
> supposed to be resolved in the1.2.1framework
>
> problem 2:
> The 1.2 WithInstaller framework does not check the running OS to
> determine what version its being run under, so if the user doesn't
> have Growl installed on 10.4, the WithInstaller isn't going to install
> 1.1.6 (the last 10.4 compat release). afaik the way the code is now

> WithInstaller would attempt to install 1.2.http://code.google.com/p/growl/issues/detail?id=50

[Christopher Forsythe]

Let me look through and make sure, but I think we'll start a beta this month. What's your ship date?

[BJ Homer]

Well, we were hoping to make it within a couple weeks. Sooner, if
possible, so that testing can start looking at it.

Is it just a problem with the build settings used to make 1.2? Could I
download the 1.2 source, change something in the build settings, and
then build our own copy?

-BJ

> > growldiscuss...@googlegroups.com<growldiscuss%2Bunsubscribe@google groups.com>

> > > > > .
> > > > > For more options, visit this group athttp://
> > groups.google.com/group/growldiscuss?hl=en
> > > > > .
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "Growl Discuss" group.
> > To post to this group, send email to growld...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > growldiscuss...@googlegroups.com<growldiscuss%2Bunsubscribe@google groups.com>

[Peter Hosey]

On Dec 3, 2009, at 10:38:25, Christopher Forsythe wrote:
> Let me look through and make sure, but I think we'll start a beta
> this month.

It can be today. What do you think?

[Peter Hosey]

On Dec 3, 2009, at 14:18:36, BJ Homer wrote:
> Is it just a problem with the build settings used to make 1.2? Could
> I download the 1.2 source, change something in the build settings,
> and then build our own copy?

That should work if you're not using G-WI.framework. G-WI requires the
certificate for a release build of GHA, without which (a) the build
will fail or, if you delete the certificate build setting, (b) users
will have difficulties getting Growl to access the Keychain (which
they'll then email *us* about).

Best to wait for the official 1.2.1.

[BJ Homer]

We're not using the G-WI.

I agree that waiting for 1.2.1 would be ideal, but not delaying our
ship date would also be ideal. How long does the beta period usually
go?

-BJ

[Peter Hosey]

On Dec 3, 2009, at 14:47:01, BJ Homer wrote:
> How long does the beta period usually go?

It depends on how many problems we have with the release. This one
should be fairly quiet. A release this month is not outside the realm
of possibility.

That reminds me, I should ship the release version of GrowlMail 1.2.1.

[Evan Schoenberg, M.D.]

On Dec 3, 2009, at 4:49 PM, Peter Hosey wrote:

> On Dec 3, 2009, at 14:47:01, BJ Homer wrote:
>> How long does the beta period usually go?
>
> It depends on how many problems we have with the release. This one
> should be fairly quiet. A release this month is not outside the realm
> of possibility.

As the Growl.framework files haven't changed, and it's just a build setting, you should be safe using the beta's framework assuming it works for you, in my opinion.

Actually, it'd be reasonable to branch from 1.2, fix the build setting, and release as 1.2.1; the same fix would be applied on tip, and development continue as before. That would make 1.2.1 not include any changes since the 1.2 release. Does that sound reasonable, Peter?

-Evan

[Christopher Forsythe]

I'm ok with either this or with Evan's suggestion. 

[BJ Homer]

On Dec 3, 4:25 pm, Christopher Forsythe <ch...@growl.info> wrote:
> I'm ok with either this or with Evan's suggestion.

Having an official build with the build setting fix, even if only
released as a "hotfix" or something, would be very helpful. It's
easier to convince others that we're release-ready if I'm not swapping
in a beta build. Of course, the actual Growl.framework would actually
be identical in both the beta and Evan's proposed 1.2.1, but that
"beta" tag will make a difference to some people.

[Peter Hosey]

On Dec 3, 2009, at 15:37:09, BJ Homer wrote:
> Of course, the actual Growl.framework would actually be identical in

> both the beta and Evan's proposed 1.2.1…

No, it would not.

[Peter Hosey]

On Dec 3, 2009, at 14:56:50, Evan Schoenberg, M.D. wrote:
> Actually, it'd be reasonable to branch from 1.2, fix the build
> setting, and release as 1.2.1; the same fix would be applied on tip,
> and development continue as before. That would make 1.2.1 not
> include any changes since the 1.2 release. Does that sound
> reasonable, Peter?

Yes, but there are some other fixes in 1.2.1 that are worth getting
out there. For one example, Growl as forwarding destination is broken
as of 1.2, and fixed in [8b8d2ecd6c25]. Another is the MailMe no-Mail-
prefs fix from yesterday.

More relevantly to the (non-installer) framework:

changeset: 4460:3cbd662ab3c1
summary: Always look for a running GHA and register with that,
instead of trying to register with a GHA that isn't running.

changeset: 4513:845941e3fa7f
summary: Fixed a leak when running the framework under GC, found
by the Clang Static Analyzer.

changeset: 4538:987d555071f6
summary: Don't leak the event after sending it.

changeset: 4539:383d84e26955
summary: Fixed a couple of minor leaks under garbage-collection.
Found using Instruments.

[Evan Schoenberg, M.D.]

If we trust these fixes, then we should include them. If we don't, we should release a 1.2.1 with the show-stopper fixed, and follow up with getting these into the wild when possible. I'm not convinced that we get a very high adoption rate on our beta SDKs, though if you have download numbers I could be easily shown mistaken. That, in turn, leads me to feel that an SDK-focused beta is of relatively low yield, especially for a limited changeset.

-Evan

[Peter Hosey]

On Dec 3, 2009, at 16:23:01, Evan Schoenberg, M.D. wrote:
> I'm not convinced that we get a very high adoption rate on our beta
> SDKs, though if you have download numbers I could be easily shown
> mistaken.

Fair point. I haven't looked (actually, since it's on CacheFly, Chris
would have to look), but I share your expectation.

I wonder if it's even worth making beta SDK disk images. Do any of you
out there ever use them?

> That, in turn, leads me to feel that an SDK-focused beta is of
> relatively low yield, especially for a limited changeset.

Yeah. The beta won't be the SDK alone; it'll be everything.

A risk of releasing framework 1.2.1 now is that if we find any serious
bugs during the subsequent Growl 1.2.1 beta that we would otherwise
fix in 1.2.1, we'll have to hold the fixes for Growl (and its
framework) 1.2.2.

That said, I don't know of any offhand, I don't see any obvious
regressions looking at the diffs, and BeepHammer does work as of tip.
Therefore, I think the risk is acceptable, so we can go ahead with
your suggestion of jumping straight to 1.2.1 release on the framework.

Chris, what do you think?

[Chris Forsythe]

On Dec 3, 2009, at 10:45 PM, Peter Hosey wrote:

On Dec 3, 2009, at 16:23:01, Evan Schoenberg, M.D. wrote:

Chris, what do you think?

I'm glad Launchpad was down so I had time to actually research this. Based on the results of what I've found, here's my thoughts.

Summary

- We need to change our release policy. We will no longer beta test SDK changes for benign changes. Major changes and major releases should still remain as a beta SDK, since it's not that much more difficult to add those in.

- We also need to put 1.2.1 out right now 

- We should delete 1.1.6 betas entirely along with 1.2 betas.

Details

We have 4 pretty benign changes to the framework. To be honest if it weren't for the fact that we're a system framework basically, I wouldn't care about betas at all, I'd just hand it out to a few people who are really good at feedback and see what they thought, then release. In fact if we had 4 or 8 really good feedback people to give us a full list of their feedback, we may not even need beta testing as much as 

However, I don't think we should change things just based on conjecture. My thoughts are typically that you weigh things out and the most convincing item wins.

Facts

- We also can't determine the actual amount of people who use the beta framework, we can only determine download counts. (this is true for Growl itself)

- We need better statistics so that we know what's out there, especially with 1.3 coming up.

- We need to get 1.2.1 changes out shortly.

- We need to be confident that the framework works to the best of our ability.

- Here are download numbers from Cachefly year to date:

Here are the GCH numbers:

The downloads here are the most telling from the Growl server:

      1 ..

      1 Growl-1.1.3b2.dmg

      1 Growl-1.1.3b4-SDK.dmg

      1 Growl-1.1.5b1.dmg

      1 Growl-1.1.5b2-SDK.dmg

      1 Growl-1.1.5b2.dmg

      1 Growl-1.1.5b3-SDK.dmg

      1 Growl-1.1.5b3.dmg

      1 Growl-1.1.6b1-SDK.dmg

      1 Growl-1.1.6b1.dmg

      1 Growl-1.1.6b2-SDK.dmg

      1 Growl-1.1.6b2.dmg

      1 Growl-1.1.6b3-SDK.dmg

      1 Growl-1.1.6b3.dmg

      1 Growl-1.1.6b4-SDK.dmg

      1 Growl-1.1.6b4.dmg

      1 Growl-1.2b1-SDK.dmg

      1 Growl-1.2b2-SDK.dmg

      1 Growl-1.2b4-SDK.dmg

      1 Growl-1.2b5-SDK.dmg

      1 Growl-1.2b6-SDK.dmg

      1 Growl-1.2b7-SDK.dmg

      1 Growl-1.2b7.dmg

      1 files

      1 growl-0.7.6.dmg

      1 growl-1.1.6.dmg

      2 Growl-1.1.3b4.dmg

      2 Growl-1.1.4b1.dmg

      2 Growl-1.1.4b2-SDK.dmg

      2 Growl-1.1.5b1-SDK.dmg

      2 Growl-1.2b3-SDK.dmg

      2 Growl-1.2b6.dmg

      3 Growl-1.1.1.dmg

      3 Growl-1.1.4b1-SDK.dmg

      3 Growl-1.1.4b2.dmg

      3 Growl-1.2b1.dmg

      4 Growl-1.1.1-SDK.dmg

      4 Growl-1.2b2.dmg

      5 Growl-1.2b5.dmg

      9 Growl-1.2b3.dmg

     22 Growl-1.2b4.dmg

     28 11-03_ChatBubble.dmg

     39 07-21_MasterShake.dmg

     42 09-13_jewelcase_v1.dmg

     44 07-21_Meatwad.dmg

     69 Growl-0.7.6.dmg

   1060 

   1275 Growl-1.1.6.dmg

I didn't want to spend more time trying to figure out the right syntax to grab every line, however everyone should be able to tell that very few people download beta sdk disk images.

- Another fact is that we have no structured release dates that Developers would hold their releases on in order to include updates to our framework, and no data to back up the need to continue pushing sdk releases. However, I think we get testing of the SDK based on people using it in their applications, in our own Extras, and in general based on how Growl is architected basically.

- It is my opinion that Developers are slow to adopt updated versions of our frameworks. With good reason.

Conclusions

Based on these facts, I think I'm fine with just releasing 1.2.1. I do not believe that anyone specifically pushes their release plans based on our release plans. Also, 1.2 was out for at least a month with nobody catching the 10.4 issue really until this thread means I think that we're better off release it and letting people test it with their beta testers and provide feedback and continue to test through Extras.

I think we need to change our whole release policy, create a release policy wiki page, and publish it.

I think the 1200+ SDK downloads on the GCH page is a misnomer. We do not have 1200+ app devs using Growl. We also don't see those numbers reflected in the beta SDK download, even if the final SDK download number is fully legitimate.

[Peter Hosey]

On Dec 3, 2009, at 22:11:27, Chris Forsythe wrote:
> Based on these facts, I think I'm fine with just releasing 1.2.1.

Of the non-installer framework, you mean? With a Growl 1.2.1 beta to
follow at some point.

We would need to amend the build system to produce an archive holding
only the non-installer framework (since G-WI depends on a release of
Growl). Perhaps we should do that anyway, and move the bindings to a
separate zip archive (and, for that matter, another separate version
track—I think the last time we made a change to any of them was a
Python fix a few versions ago).

> I think the 1200+ SDK downloads on the GCH page is a misnomer.

Agreed. I think a major reason is the bindings: Anybody who wants to
use Growl from their Python or Ruby script gets counted there, too.

[Chris Forsythe]

On Dec 4, 2009, at 12:24 AM, Peter Hosey wrote:

> On Dec 3, 2009, at 22:11:27, Chris Forsythe wrote:
>> Based on these facts, I think I'm fine with just releasing 1.2.1.
>
> Of the non-installer framework, you mean? With a Growl 1.2.1 beta to
> follow at some point.

Sorry, yes. I thought I was just commenting on that specifically.

>
> We would need to amend the build system to produce an archive holding
> only the non-installer framework (since G-WI depends on a release of
> Growl). Perhaps we should do that anyway, and move the bindings to a
> separate zip archive (and, for that matter, another separate version
> track—I think the last time we made a change to any of them was a
> Python fix a few versions ago).
>

I'm fine with splitting them, but that's obviously not as big of a
priority.

>> I think the 1200+ SDK downloads on the GCH page is a misnomer.
>
> Agreed. I think a major reason is the bindings: Anybody who wants to
> use Growl from their Python or Ruby script gets counted there, too.

I don't think so. I think it's a combination. Either way we'll know
for sure once we split it out, and know where to focus developer based
efforts.

Rudy wants to jetison the bindings with 1.3 anyhow and force everyone
onto gntp based bindings. I'm alright with that, and I think that'd be
a good time to go through that change.

Chris

[Chris Forsythe]

On Dec 4, 2009, at 12:24 AM, Peter Hosey wrote:

> On Dec 3, 2009, at 22:11:27, Chris Forsythe wrote:
>> Based on these facts, I think I'm fine with just releasing 1.2.1.
>
> Of the non-installer framework, you mean? With a Growl 1.2.1 beta to
> follow at some point.

After sleeping on it, my numbers would support just pushing the whole
SDK now.

[BJ Homer]

On Fri, Dec 4, 2009 at 6:41 AM, Chris Forsythe <ch...@growl.info> wrote:

After sleeping on it, my numbers would support just pushing the whole
SDK now.

This would be very useful. Word at work today is that I need to have this working for Tiger. So if this isn't coming out today, then I need to either do a conditional compile to use the 1.1.6 framework on Tiger builds (undesirable, but feasible), or download the 1.2 project and implement the Tiger fix myself.  (Again, this is only for Growl.framework, not WithInstaller.)  So… if the SDK isn't releasing today, can anyone point me to the revision that fixed the "Growl.framework won't launch on Tiger" issue?

Thanks. I don't intend to be pushy; just trying to figure out how to get things working.

-BJ

[Evan Schoenberg, M.D.]

Well, previous discussion indicated that the problem would likely be that the Minimum OS X Version was set to 10.5 rather than 10.4.

Here's how the configuration looks:`

This leads to building with -mmacosx-version-min=10.4 in the build settings per XCode's output, for both ppc and intel builds. (No, I'm not sure what the 10.5 setting is supposed to be accomplishing).

The resulting built framework has ppc, i386, an x86_64 architectures:

[evands:Shindig] [12:12:30] [Fri Dec 04] [~/Coding/growl-default/build/Debug/Growl.framework] 

=> file Growl

Growl: Mach-O universal binary with 3 architectures

Growl (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

Growl (for architecture i386): Mach-O dynamically linked shared library i386

Growl (for architecture ppc): Mach-O dynamically linked shared library ppc

I'm not sure why the current framework isn't working, honestly.  Anyone have any thoughts?

-Evan

[BJ Homer]

On Fri, Dec 4, 2009 at 11:17 AM, Evan Schoenberg, M.D. <eva...@dreskin.net> wrote:

Well, previous discussion indicated that the problem would likely be that the Minimum OS X Version was set to 10.5 rather than 10.4.

Here's how the configuration looks:`

This leads to building with -mmacosx-version-min=10.4 in the build settings per XCode's output, for both ppc and intel builds. (No, I'm not sure what the 10.5 setting is supposed to be accomplishing).

The resulting built framework has ppc, i386, an x86_64 architectures:

[evands:Shindig] [12:12:30] [Fri Dec 04] [~/Coding/growl-default/build/Debug/Growl.framework] 

=> file Growl

Growl: Mach-O universal binary with 3 architectures

Growl (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

Growl (for architecture i386): Mach-O dynamically linked shared library i386

Growl (for architecture ppc): Mach-O dynamically linked shared library ppc

I'm not sure why the current framework isn't working, honestly.  Anyone have any thoughts?

-Evan

The 10.5 setting would be for x86_64, which will never need to be 10.4 compatible.

I've downloaded the 1.2 and hg projects, and compared them. In the 1.2 code, the conditional build setting for Intel (only applies to i386) was not present.  That's likely the cause of the issue; I'll be able to verify in about 10 minutes.

-BJ

[Evan Schoenberg, M.D.]

On Dec 4, 2009, at 12:23 PM, BJ Homer wrote:

> The 10.5 setting would be for x86_64, which will never need to be 10.4 compatible.

Oh, of course. Thanks :)

>
> I've downloaded the 1.2 and hg projects, and compared them. In the 1.2 code, the conditional build setting for Intel (only applies to i386) was not present. That's likely the cause of the issue; I'll be able to verify in about 10 minutes.

I'd forgotten that 1.2 wasn't compiled from the default branch. That explains that.

-Evan

[BJ Homer]

K, I can verify that adding the conditional build setting on the Growl.framework target (Setting deployment target on i386 to 10.4) fixes the issue. 

-BJ

[Peter Hosey]

On Dec 4, 2009, at 10:32:21, Evan Schoenberg, M.D. wrote:
> I'd forgotten that 1.2 wasn't compiled from the default branch.

Huh? Yes it was.

[Evan Schoenberg, M.D.]

Then this was fixed - intentionally or unintentionally - by someone who didn't mention it in their commit log, as I reviewed all commits on the default branch since 1.2 was released and there's no mention of fixing this problem.

-Evan

[Peter Hosey]

Rudy did mention it, sort of, but it wasn't the only fix in that
commit and he didn't address the 10._5_ to 10.4 change directly:

http://growl.info/hg/growl-development/rev/fac59330ff0c

> The project was also incorrectly targeting both frameworks in terms
> of deployment OS for the various architectures, G-WI was still
> targeting ppc at 10.3

The diff shows the full extent of the change:

<http://growl.info/hg/growl-development/diff/fac59330ff0c/Growl.xcodeproj/project.pbxproj
>

If you look at the graph log with hg glog -r4461:1.2, you can see that
this is the very next commit on the default branch after I tagged 1.2.

[Peter Hosey]

On Dec 3, 2009, at 09:40:55, BJ Homer wrote:
> Is there an ETA on the 1.2.1 framework?

I've just uploaded it to the files area on the GCH site:

http://growl.googlecode.com/files/Growl-1.2.1-Framework.tbz

This is the non-installer framework and (for debugging purposes) its
dSYM bundle.

[Matthew Butch]

Awesome, because I just coming here to ask about 1.2 crashes on 10.4 Intel systems. I'm going to put at a beta build for testers and see if they can confirm it too.

Thanks!

-Matt

> --
>
> You received this message because you are subscribed to the Google Groups "Growl Discuss" group.
> To post to this group, send email to growld...@googlegroups.com.

> To unsubscribe from this group, send email to growldiscuss...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/growldiscuss?hl=en.
>
>
>

--

Matthew Butch
President
Volitans Software
Developer of SMART Utility, the hard drive diagnostic application
http://www.volitans-software.com

Sent with Mac OS X Snow Leopard Mail 4.1 (1076)

[Chetan]

Can you also upload the with-installer framework 1.2.1 please?

- Chetan

[Christopher Forsythe]

We don't have a Growl 1.2.1 yet, so we haven't got a 1.2.1 withinstaller yet. :)