librelist archives

Re: [homebrew] GTK+ native build?

From:

Charlie Sharpsteen

Date:

2010-11-14 @ 18:02

On Sat, Nov 13, 2010 at 11:28 PM, John Pye <john.pye@anu.edu.au> wrote:
> Hi all
>
> I just downloaded and tried Homebrew but my experience hasn't been so good.

Sorry to hear that you have been hitting some bumps in the road.
Thanks for taking the time to try our package manager though!


> Firstly, I moved my old /usr/local to /usr/local-old then installed 'brew'
> using the 'chown and curl' method from this page:
>
> https://github.com/mxcl/homebrew/wiki/Installation
>
> After that, I did 'brew install scons' and that seemed to work OK. But next
> I tried 'brew install gtk+' and the compilation completed without
> complaining (except for a warning that I should upgrade XCode to 3.1.4 (I
> currently have 3.1.2). Then I tried to run 'gtk-demo' and I received a
> segmentation fault.
>
> Two problems with this...
>
> 1. getting a segfault is definitely bad. how is that possible given that I
> just successfully built and linked everything from source?

Segmentation faults are examples of "run time" errors and
unfortunately there are a zillion ways to create them.  One thing that
makes segfaults particularly annoying is that they are difficult or
impossible for the compiler to catch as they rely on conditions
produced in the program during execution---a state which is unknown at
compile time.

In order to get this resolved, you should first upgrade to XCode
3.1.4.  We all build and test formulas for OS X 10.5.x using this
version of XCode and it may be difficult or impossible for us to
reproduce errors in software that was compiled under an older version.

If the still produces segfaulting binaries, open an issue at:

    http://github.com/mxcl/homebrew/issues

It would probably be helpful to include the output of:

  otool -L /path/to/segfaulting/program

So we could see which libraries it is linked against.  The output of
`brew --config` and `brew doctor` could be useful as well.


> 2. the resulting GTK+ is the X11 version. That's not what I want; I want to
> build a native GTK+, as described:
>
> http://gtk-osx.sourceforge.net/
> http://ascendwiki.cheme.cmu.edu/Porting_to_Mac
>
> I note that MacPorts addresses this issue by allowing users to specify build
> 'variants', but I can't see how that would work with Homebrew, which only
> seems to allow dependencies against package names, not versions of specific
> packages nor variants. Also, I believe only specific versions of GTK+ have
> been patched for 'native' use on OS X.
>
> Cheers
> JP

The reason is that no one has contributed a build for GTK-OSX that has
been accepted.  We did have a pull request open that contributed a
GTK-OSX, but it needed someone to volunteer a significant amount of
work for polishing and testing before it could be brought into the
master branch.  No one stepped forward to donate the time and now I
can't find the pull request in the issue tracker, which is a shame as
it looked like there was some good work there.


-Charlie

I just posted an update to GTK+ for Leopard; I did a fresh Leopard +
Xcode install on a separate partition, and had to add an explicit
keg-only dependency to GTK+.

As far as using a native (Quartz) back-end, there is work on other
branches to enable this, but we haven't pulled any of it into master
due to the difficulties in testing it across 10.5 and 10.6, and
because it will require more "system duplicates" of stuff that comes
in 10.6 but is compiled against X11 instead of Quartz.

If a group wants to get together, do config testing, and present a
series of tested commits for a native back-end, we'd certainly
consider merging it, or at the very least linking to the alt repo from
the wiki.


On the Xcode issue, we really do suggest updating to 3.1.4 over 3.1.2.

Hi Adam

Adam Vandenberg wrote:
> I just posted an update to GTK+ for Leopard; I did a fresh Leopard +
> Xcode install on a separate partition, and had to add an explicit
> keg-only dependency to GTK+.
>
> As far as using a native (Quartz) back-end, there is work on other
> branches to enable this, but we haven't pulled any of it into master
> due to the difficulties in testing it across 10.5 and 10.6, and
> because it will require more "system duplicates" of stuff that comes
> in 10.6 but is compiled against X11 instead of Quartz.
>   

If you can point me at any of these branches, that would be great.

> If a group wants to get together, do config testing, and present a
> series of tested commits for a native back-end, we'd certainly
> consider merging it, or at the very least linking to the alt repo from
> the wiki.
>   

A native GTK+ in Homebrew would be really valuable. Essentially noone
would be coding a GTK app for Mac without wanting to 'go native' because
the X11 version of GTK is so un-user-friendly. Anything you can do to
help us non-project-members access and attempt to use the GTK 'brew',
even if it's just a rough alpha, would be very helpful. Happy to give
feedback/bug reports through whatever are the appropriate channels.

FWIW a key issue with GTK is how to package the resulting application.
John Rall's work with 'ige-mac-bundler' etc would also, ideally be
brought into Homebrew, but I can see that it would be a bit of work.

The alternative, quite apart from Homebrew, would be for someone to
develop a stable GTK Framework that can simply be unpacked somewhere
(for developers) or inserted into a Bundle (for end-users). I have been
working on this a little bit. I'm not sure that Homebrew helps in that
case, though -- its emphasis is rather on developer tools rather than
end-user packaging of apps?


>
> On the Xcode issue, we really do suggest updating to 3.1.4 over 3.1.2.
>   

I will set about downloading it. It's huge 3 GB download though.

Cheers
JP

        
        The alternative, quite apart from Homebrew, would be for someone 
todevelop a stable GTK Framework that can simply be unpacked somewhere(for
developers) or inserted into a Bundle (for end-users). I have beenworking 
on this a little bit. I'm not sure that Homebrew helps in thatcase, though
-- its emphasis is rather on developer tools rather thanend-user packaging
of apps?I'm very keen for Homebrew to support this properly.Homebrew is 
"the missing package manager for Mac", symlinking frameworks into /Library
is a missing package management facility for Mac that we should therefore 
do.What we need is a simple thing that makes a framework for such 
experimentation.Max

On 15 November 2010 03:39, Max Howell <max@methylblue.com> wrote:
> I'm very keen for Homebrew to support this properly.
> Homebrew is "the missing package manager for Mac", symlinking frameworks
> into /Library is a missing package management facility for Mac that we
> should therefore do.
> What we need is a simple thing that makes a framework for such
> experimentation.


I agree, this would be great. With GTK though, I want us to make sure
we go at the same rate as upstream rather than forcing alpha software
on our users. If it gets to a point where we can build it sensibly AND
it's stable then awesome. Until then, we should default to the X11
version.

-- 
Mike McQuaid
http://mikemcquaid.com

Hi Mike

On 16/11/10 6:23 AM, Mike McQuaid wrote:
> On 15 November 2010 03:39, Max Howell<max@methylblue.com>  wrote:
>> I'm very keen for Homebrew to support this properly.
>> Homebrew is "the missing package manager for Mac", symlinking frameworks
>> into /Library is a missing package management facility for Mac that we
>> should therefore do.
>> What we need is a simple thing that makes a framework for such
>> experimentation.
>
> I agree, this would be great.

Agreed, but it does represent additional package-specific work on top of 
the relatively simple process of creating a 'brew'.

> With GTK though, I want us to make sure
> we go at the same rate as upstream rather than forcing alpha software
> on our users. If it gets to a point where we can build it sensibly AND
> it's stable then awesome. Until then, we should default to the X11
> version.

I think that it really great if it were possible to support both 
simultaneously. Some packages will continue to want X11 GTK, but the 
native GTK is actively under development and IMHO quite stable enough 
for many applications. I regularly use a packaged copy of Gedit that 
uses native GTK+ and it's very reliable. If native GTK can be supported 
through Homebrew then this would be a huge aid in building GTK 
applications on Mac, because the 'jhbuild' process is complicated and 
involves learning a new toolset ('jhbuild') that most Linux developers 
won't even have needed to use. The jhbuild process also creates a messy 
spray of special folders in one's home directory (~/.local, ~/gtk/inst, 
~/.jhbuild*).

I don't think this is a matter of 'forcing alpha software on our users'. 
It's more about providing choice and convenience to your users, who are 
primarily, I would say, developers who know what they're doing, rather 
than end-users who don't understand the details.

Cheers
JP

On 14 November 2010 10:50, Adam Vandenberg <flangy@gmail.com> wrote:
> On the Xcode issue, we really do suggest updating to 3.1.4 over 3.1.2.

Yes, please do this. I really wish people wouldn't file bug reports
when they ignore warnings, it's frankly a bit inconsiderate of other
people's time, we've added a check there to let you know that it might
cause problems.

-- 
Cheers,
Mike McQuaid
http://mikemcquaid.com/

I didn't file a bug report. I wrote to the mailing list. Most of the
replies were friendly.

Mike McQuaid wrote:
> On 14 November 2010 10:50, Adam Vandenberg <flangy@gmail.com> wrote:
>   
>> On the Xcode issue, we really do suggest updating to 3.1.4 over 3.1.2.
>>     
>
> Yes, please do this. I really wish people wouldn't file bug reports
> when they ignore warnings, it's frankly a bit inconsiderate of other
> people's time, we've added a check there to let you know that it might
> cause problems.
>
>   


-- 
Dr John Pye
Dept of Engineering
Australian National University

On 15/11/2010, at 12:43 PM, John Pye wrote:
> I didn't file a bug report. I wrote to the mailing list. Most of the
> replies were friendly.

Yeah, all good.  Lots of different personalities and approaches. :)

With your prob, do you reckon you'll have a chance to try the updated 
Xcode, and see if that allows things to recompile ok?

No guarantees... but it wouldn't be hugely surprising if it does the trick. :)

On 14 November 2010 17:49, Justin Clift <jclift@redhat.com> wrote:
> Yeah, all good.  Lots of different personalities and approaches. :)

I'm the grumpy uncle in the Homebrew family :)

-- 
Mike McQuaid
http://mikemcquaid.com