librelist archives

« back to archive

Building shoes for 32-bit OSX

Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-24 @ 04:02
Hi, shoes list!

I'm just getting into shoes, having watched it for a while. Eventually, I'd
like to be able to run hackety-hack on my 32-bit imac. But first I need to
get shoes built, and I'm having some trouble.

I have gotten the rake task to succeed, but Shoes.app fails on launch, with
no console message. shoes-bin fails with the message

UTF_7 is not a class

As far as I can tell, the only places "UTF_7" occurs are:

dist/lib/shoes.rb|10 col 6| %w[UTF_7 UTF_16BE UTF_16LE UTF_32BE
UTF_32LE].each do |enc|
dist/ruby/lib/uri/common.rb|721 col 35| HTML5ASCIIINCOMPAT =
[Encoding::UTF_7, Encoding::UTF_16BE, Encoding::UTF_16LE,
lib/shoes.rb|10 col 6| %w[UTF_7 UTF_16BE UTF_16LE UTF_32BE UTF_32LE].each do
|enc|
Shoes.app/Contents/MacOS/lib/shoes.rb|10 col 6| %w[UTF_7 UTF_16BE UTF_16LE
UTF_32BE UTF_32LE].each do |enc|
Shoes.app/Contents/MacOS/ruby/lib/uri/common.rb|721 col 35|
HTML5ASCIIINCOMPAT = [Encoding::UTF_7, Encoding::UTF_16BE,
Encoding::UTF_16LE,

Which is all ruby code. I was sure if the build failed it would be because
of a C library. I had to do ugly things to get the build to work. First, I
tried compiling from source as described on the
wiki<https://github.com/shoes/shoes/wiki/Building-Shoes-on-Mac-OS-X-10.6>
into
/tmp/dep. The portaudio build failed because it wants the MacOSX10.4u.sdk,
which I don't have. Installing that SDK seemed like a huge process for this
little library. I decided to try building the dependencies with
homebrew<http://mxcl.github.com/homebrew/> instead,
into /usr/local. This worked for all of the dependencies (including
portaudio, somehow) except for libpng, which OS X already includes
at /usr/X11/lib/libpng12.0.dylib. Homebrew builds but does not install
cairo, libiconv, and gettext, so as not to conflict with built-in versions.
This messes with the build process because it assumes all libs will be in
the same directory. I began to copy the missing files into /usr/local/lib,
one-by-one (these are homebrew-generated files). The OS X libpng file had
the wrong version number, so I just renamed it. Finally, I realized that the
homebrew pango build didn't include the atsui files, or any .la files, even
when I rewrote the formula to mimic the instructions on the wiki. So I just
copied the missing pango files in from the version I built in /tmp/dep, on
the off-chance that it would just work, or that I could at least isolate
that as the problem. Here is all of the suspect file manipulation:

cd /usr/local/lib

# Homebrew-generated
cp ../Cellar/cairo/1.10.2/lib/libcairo.2.dylib .
cp ../Cellar/libiconv/1.13.1/lib/libiconv.2.dylib .
cp ../Cellar/gettext/0.18.1.1/lib/libintl.8.dylib .

# OS X version
cp /usr/X11/lib/libpng12.0.dylib ./libpng14.14.dylib

# Built following wiki
cp /tmp/dep/lib/pango/1.6.0/modules/pango-arabic-lang.la
cp /tmp/dep/lib/pango/1.6.0/modules/pango-indic-lang.la
cp /tmp/dep/lib/pango/1.6.0/modules/pango-basic-atsui.la
cp /tmp/dep/lib/pango/1.6.0/modules/pango-basic-atsui.so

At this point, the rake task succeeds, and Shoes.app is built, but fails as
described above.

Any ideas where to go from here?

Thanks!

Eric

Re: [shoes] Building shoes for 32-bit OSX

From:
Steve Klabnik
Date:
2011-05-24 @ 12:05
>
> UTF_7 is not a class
>

Ahhh, this is THE error message.


> The portaudio build failed because it wants the MacOSX10.4u.sdk, which I
> don't have. Installing that SDK seemed like a huge process for this little
> library.


Absolutely. This is strange, I don't have 10.4.sdk... I wonder why it
doesn't want you to?


> The OS X libpng file had the wrong version number, so I just renamed it.


This is probably a good candidate for updating it, then.


> Any ideas where to go from here?
>

So. UTF_7.

Looking inside the Ruby source, UTF_7 is only mentioned twice: Once in
the dist/ruby/lib/uri/common.rb
you found, and once here:
https://github.com/ruby/ruby/blob/trunk/enc/utf_7.h

As you can see, it's a dummy encoding. When you delete the reference in
uri/common, it should complain about the next encoding. When you delete the
entire array, it SHOULD actually start up. This is where I was at a few days
ago.

Now, when Shoes gets built, it makes a ton of dynamic libraries, .dylibs,
and re-roots them into the .app by using install_name_tool -change to refer
to ones inside of the .app rather than the ones in /tmp/dep. See all those
lines fly by in the install process? Check out the manual for
install_name_tool. And if you run 'otool -L /tmp/dep/lib/libshoes.dylib' for
example, you'll see this:

$ otool -L /tmp/dep/lib/libruby.dylib

/tmp/dep/lib/libruby.dylib:

/tmp/dep/lib/libruby.1.9.1.dylib (compatibility version 1.9.1, current
> version 1.9.1)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 125.2.10)


That first line is changed by doing install_name_tool.id, and the second two
lines are the ones it references, which the first is changed by doing
install_name_tool -change.

What I thought was the problem was that not all of these references were
getting properly changed. When I started running otool -L on all of the
dylibs inside of the generated .app, it seemed like a bunch of them still
referred to /tmp/dep! hence this commit:
https://github.com/shoes/shoes/commit/19418cc0bbc19714edcc45134144d7fbe2134058

A bunch of extra install_name_tool calls. Now, after that, it was still
complaining about an undefined constant UTF_7. So I added that first line in
lib/shoes.rb to define it. Incredibly hacky. And, on my machine, it now
works.

I'm still not comfortable with this reference, exactly. And since it doesn't
quite work on your machine, I'm still not quite sure what isn't right.

Thoughts?

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-25 @ 06:24
>
> The portaudio build failed because it wants the MacOSX10.4u.sdk, which I
>> don't have. Installing that SDK seemed like a huge process for this little
>> library.
>
>
> Absolutely. This is strange, I don't have 10.4.sdk... I wonder why it
> doesn't want you to?
>

Apparently this problem is caused by the fact that I've installed XCode4,
which removed support for ppc and for OS X 10.3. When I looked into the
portaudio/configure file, I saw that I didn't actually need
MacOSX10.4u.sdk—MacOSX10.5.sdk would also work (XCode4 doesn't install this,
but I have an old copy lying around). So, for anyone running into this
problem in the future, here's a workaround. I manually edited the
portaudio/configure file, lines 20668-20670 to look like this:

if [ -d /Developer-old/SDKs/MacOSX10.5.sdk ] ; then
     SHARED_FLAGS="-Werror -framework CoreAudio -framework AudioToolbox
-framework AudioUnit -framework Carbon -dynamiclib -arch x86_64 -arch i386
-isysroot /Developer-old/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.3";
     CFLAGS="-Werror $CFLAGS -arch x86_64 -arch i386 -isysroot
/Developer-old/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.3";

- removed references to "-arch ppc64" and "-arch ppc" (2 places each)
- changed SDK root (3 places) from Developer to Developer-old (where
my MacOSX10.5.sdk happens to be)

Eric

Re: [shoes] Building shoes for 32-bit OSX

From:
Date:
2011-05-25 @ 18:59
Hi, there:)

Eric, how about my shoes? I usually build dependencies thus:

1. git clone git://github.com/shoes/shoes.git
2. Check out shoes/builddeps.sh which tells wanted dependencies and their versions
3. Put those unziped dependencies in /usr/local/src
4. Execute shoes/builddeps.sh

Portaudio trouble is probably solved by this code in shoes/builddeps.sh:
  ./configure --prefix=/tmp/dep --disable-mac-universal

And I use a Ruby downloaded from the official web site, I didn't know 
there is GitHub version.
Steve, isn't your Ruby official??


Anyway, I report here about shoes/lib/shoes.rb on my environment.
-----------------------------------------------------------------
There is 2 codes for Encoding class.

1.
class Encoding
  %w[UTF_7 UTF_16BE UTF_16LE UTF_32BE UTF_32LE].each do |enc|
    eval "class #{enc};end"
  end
end

2.
class Encoding
 %w[ASCII_8BIT UTF_16BE UTF_16LE UTF_32BE UTF_32LE US_ASCII].each do |ec|
   eval "#{ec} = '#{ec.sub '_', '-'}'"
 end unless RUBY_PLATFORM =~ /linux/
end

When I delete both, built Shoes can get full Encoding.list, but which 
cannot start up unless 
refernece to the inside of /tmp/dep/lib/ruby/1.9.1/x86_64-darwin10.7.0/enc.

When I restore the former only, Shoes DOES start up UNLESS 
/tmp/dep/lib/ruby/1.9.1/x86_64-darwin10.7.0/enc,
but Encoding.list returns just [#<Encoding:ASCII-8BIT>, 
#<Encodoing:UTF-8>, #<Encoding:US-ASCII>]
on the sample program, expert-irb.rb
(I usually open the Shoes manual and test Encoding.list thus).

I think my Shoes still remains something to load at 
/tmp/dep/lib/ruby/1.9.1/x86_64-darwin10.7.0/enc.
Otherwise there might be multi-ending about Encoding's C definition, 
according to whether we on 32bit, 64bit, or what Ruby is used...
But don't believe me so seriously :)

-vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-25 @ 21:07
On May 25, 2011, at 2:00 PM, "vhuto@me.com" <vhuto@me.com> wrote:

> Hi, there:)
>
> Eric, how about my shoes?

I downloaded your build, but it wouldn't launch. I'm not near my
machine now, so I can't tell you the exact message.

> I usually build dependencies thus:
>
> 1. git clone git://github.com/shoes/shoes.git
> 2. Check out shoes/builddeps.sh which tells wanted dependencies and 
their versions
> 3. Put those unziped dependencies in /usr/local/src
> 4. Execute shoes/builddeps.sh

That was the first strategy I tried, but I couldn't get portaudio or
pixman to compile.  I noticed the rake deps task and tried it. I ran
into the same trouble as with builddeps.sh, but I *love* the fact that
rake knows when a dependency has already been built. Same effect,
though. Any reason the rake task is not the preferred method of
building deps?

>
> Portaudio trouble is probably solved by this code in shoes/builddeps.sh:
>  ./configure --prefix=/tmp/dep --disable-mac-universal
>

I thought that should handle it, too, but it didn't. The problem is
thatthe sdk that ships with xcode4 doesn't support ppc or OSX10.3,
both of which are hard coded in the configure. I manually removed
references to the ppc arch. But I did get it to compile.

Pixman was not finding the pkg.m4 headers, so I had to copy those over
manually. It compiled finally, too. I'm still working through some new
issues in the latter part of the build.


> Anyway, I report here about shoes/lib/shoes.rb on my environment.
> -----------------------------------------------------------------
> There is 2 codes for Encoding class.
>
> 1.
> class Encoding
>  %w[UTF_7 UTF_16BE UTF_16LE UTF_32BE UTF_32LE].each do |enc|
>    eval "class #{enc};end"
>  end
> end
>
> 2.
> class Encoding
> %w[ASCII_8BIT UTF_16BE UTF_16LE UTF_32BE UTF_32LE US_ASCII].each do |ec|
>   eval "#{ec} = '#{ec.sub '_', '-'}'"
> end unless RUBY_PLATFORM =~ /linux/
> end
>
> When I delete both, built Shoes can get full Encoding.list, but which 
cannot start up unless
> refernece to the inside of /tmp/dep/lib/ruby/1.9.1/x86_64-darwin10.7.0/enc.

I would expect your ruby path to be i386, not x86_64, if you're on a
32-bit machine. That's what mine is anyway :/ Hmmm

>
> When I restore the former only, Shoes DOES start up UNLESS 
/tmp/dep/lib/ruby/1.9.1/x86_64-darwin10.7.0/enc,
> but Encoding.list returns just [#<Encoding:ASCII-8BIT>, 
#<Encodoing:UTF-8>, #<Encoding:US-ASCII>]
> on the sample program, expert-irb.rb
> (I usually open the Shoes manual and test Encoding.list thus).
>
> I think my Shoes still remains something to load at 
/tmp/dep/lib/ruby/1.9.1/x86_64-darwin10.7.0/enc.
> Otherwise there might be multi-ending about Encoding's C definition, 
according to whether we on 32bit, 64bit, or what Ruby is used...
> But don't believe me so seriously :)

Don't believe me too seriously either :)

Thanks for the input. I hope to get to the point sure I can play in
irb within shoes, too!

>
Eric

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-26 @ 02:04
>
> > Eric, how about my shoes?
>
> I downloaded your build, but it wouldn't launch. I'm not near my
> machine now, so I can't tell you the exact message.
>
>
When I tried to launch Shoes.app, I got the error:

LSOpenURLsWithRole() failed with error -10810 for the file
/Users/eric/projects/shoes-vhuto/shoes/Shoes.app.

I also copied your dep directory to /tmp/dep, sourced use-tmp-dep, and did a
rake. That failed with this error:

-bash: /tmp/dep/bin/rake: /tmp/dep/bin/ruby: bad interpreter: Bad CPU type
in executable

Seems like we might not working on the same architecture? :(

Here's mine:
http://www.everymac.com/systems/apple/imac/stats/imac_cd_1.83_17.html


Eric

Re: [shoes] Building shoes for 32-bit OSX

From:
Date:
2011-05-26 @ 07:28
> -bash: /tmp/dep/bin/rake: /tmp/dep/bin/ruby: bad interpreter: Bad  
> CPU type in executable
>
> Seems like we might not working on the same architecture? :(
>
> Here's mine: 
http://www.everymac.com/systems/apple/imac/stats/imac_cd_1.83_17.html
>
>
> Eric

You got it!
Googling told me that pairing my machine and Snow Leopard goes mad.
Its processor knows 64bit but Apple likely limits its behavior to  
32bit, (so I cannot enjoy 64bit Shoes),
however, its compiling is likely done to 64bit architecture.
I could compile dependencies in 32bit-targeting by attaching -- 
target=i386-apple-darwin10 to each configure.
On this case I should edit rake codes samely, which is bad way I  
think. So I gave this up.

Simply I had Shoes built on OSX10.5.
Could you test it? This building seems to be done to i386 arch,  
because just Leopard treats my machine as 32bit maybe...

my32bitShoes_10.5.zip  at  https://public.me.com/vhuto

-vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-26 @ 12:56
On Thu, May 26, 2011 at 2:28 AM, <vhuto@me.com> wrote:

> -bash: /tmp/dep/bin/rake: /tmp/dep/bin/ruby: bad interpreter: Bad CPU type
> in executable
>
> Seems like we might not working on the same architecture? :(
>
> Here's mine:
> http://www.everymac.com/systems/apple/imac/stats/imac_cd_1.83_17.html
>
>
> Eric
>
>
> You got it!
> Googling told me that pairing my 
machine<http://www.everymac.com/systems/apple/macbook/stats/macbook-core-2-duo-2.0-aluminum-13-late-2008-unibody-specs.html>
and
> Snow Leopard goes mad.
> Its processor knows 64bit but Apple likely limits its behavior to 32bit,
> (so I cannot enjoy 64bit Shoes),
> howe ver, its compiling is likely done to 64bit architecture.
> I could compile dependencies in 32bit-targeting by attaching
> --target=i386-apple-darwin10 to each configure.
> On this case I should edit rake codes samely, which is bad way I think. So
> I gave this up.
>

I'm hoping to get to a point where the rake task will be parameterized to
build according to your architecture. It's part-way there.


> Simply I had Shoes built on OSX10.5.
> Could you test it? This building seems to be done to i386 arch, because
> just Leopard treats my machine as 32bit maybe...
>
> my32bitShoes_10.5.zip  at  https://public.me.com/vhuto
>

I'll give it a shot. I'm on Snow Leopard, though. Not sure what difference
that will make...

Eric

Re: [shoes] Building shoes for 32-bit OSX

From:
vhuto
Date:
2011-05-26 @ 13:36
> I'm hoping to get to a point where the rake task will be  
> parameterized to build according to your architecture. It's part-way  
> there.

I don't have native command of English. So I might not be  
understanding what you mean.., I usually edit rakefile friends.

shoes/make/darwin/env.rb; line 72-76:
----------------------------------------------------
else
   LINUX_CFLAGS << " -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch  
x86_64"
   LINUX_LDFLAGS << " -arch x86_64"
   ENV['MACOSX_DEPLOYMENT_TARGET'] = '10.6'
end

->

else
   LINUX_CFLAGS << " -isysroot /Developer/SDKs/MacOSX10.5.sdk -arch  
i386"
   LINUX_LDFLAGS << " -arch i386"
   ENV['MACOSX_DEPLOYMENT_TARGET'] = '10.5'
end


shoes/make/darwin/env.rb; line 190-200:
-------------------------------------------------------

     def make_stub
       ENV['MACOSX_DEPLOYMENT_TARGET'] = '10.4'
       sh "gcc -O -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386  
-arch ppc -framework Cocoa -o stub platform/mac/stub.m -I."
     end

     def make_app(name)
       bin = "#{name}-bin"
       rm_f name
       rm_f bin
       sh "#{CC} -Ldist -o #{bin} bin/main.o #{LINUX_LIBS} -lshoes - 
arch x86_64"
     end

->

     #def make_stub
     #  ENV['MACOSX_DEPLOYMENT_TARGET'] = '10.4'
     #  sh "gcc -O -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch  
i386 -arch ppc -framework Cocoa -o stub platform/mac/stub.m -I."
     #end

     def make_app(name)
       bin = "#{name}-bin"
       rm_f name
       rm_f bin
       sh "#{CC} -Ldist -o #{bin} bin/main.o #{LINUX_LIBS} -lshoes - 
arch i386"
     end

I change these SDK version and -arch codes according to my environment.

Uh, and also I modify use-tmp-dep thus:
------------------------------------------------------
RUBYOPT="-I/tmp/dep/lib/ruby/site_ruby/1.9.1 -I/tmp/dep/lib/ruby/1.9.1  
-I/tmp/dep/lib/ruby/1.9.1/powerpc-darwin9.8.0"
->
RUBYOPT="-I/tmp/dep/lib/ruby/site_ruby/1.9.1 -I/tmp/dep/lib/ruby/1.9.1  
-I/tmp/dep/lib/ruby/1.9.1/i386-darwin9.8.0"


That's all I usually do for my Shoes. :)

> I'll give it a shot. I'm on Snow Leopard, though. Not sure what  
> difference that will make...
>
> Eric


Please me!!
This vesrion can work on my 10.6 environment. If it dosen't work on  
yours, I will be bummed :(
It says that my build is dependent on a particular architecture...i686??

-vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
Steve Klabnik
Date:
2011-05-26 @ 14:43
Parameterized would be fine, that was a task I wanted to do. My philosophy
is 'get it working, then fix It's but if you want to try to do both, I won't
stop you. :)

There's a lot of cleaning up to do in the build process. I'm excited to be
working on it with you guys. :)

Re: [shoes] Building shoes for 32-bit OSX

From:
Steve Klabnik
Date:
2011-05-26 @ 01:56
>
> Any reason the rake task is not the preferred method of
> building deps?
>

Because I was working on it as a replacement, but it's not fully cooked yet.
:) The issue is that the task builds to ./deps, and the rest of the tasks
expect things to be in /tmp/dep. Maybe changing the rake task to build into
/tmp would work?

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-26 @ 12:53
>
> Any reason the rake task is not the preferred method of
>> building deps?
>>
>
> Because I was working on it as a replacement, but it's not fully cooked
> yet. :) The issue is that the task builds to ./deps, and the rest of the
> tasks expect things to be in /tmp/dep. Maybe changing the rake task to build
> into /tmp would work?
>

Got it! What I've been doing so far is replacing the hard-coded paths
(./deps and /tmp/dep) with a variable SHOES_DEPS_PATH based on
ENV['SHOES_DEPS_PATH']. Would it make sense to carry that through to the
rest of the tasks? I could do that.

Re: [shoes] Building shoes for 32-bit OSX

From:
Steve Klabnik
Date:
2011-05-25 @ 19:06
Github is a mirror of the official svn, yes.

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-31 @ 03:28
Steve,

I've been looking into install_name_tool, and I think I've made some
progress on this front. The otool -L and otool -D output looks good on all
my lib files, and on shoes-bin (see my github
fork<https://github.com/wasnotrice/shoes/commits/OSX-32bit>for
Rakefile changes). However, Shoes.app still crashes silently, and
shoes-bin and shoes-launch still fail with "UTF_7 is not a class". Starting
to look into main.skel to pinpoint where the error comes from.

Eric



Now, when Shoes gets built, it makes a ton of dynamic libraries, .dylibs,
> and re-roots them into the .app by using install_name_tool -change to refer
> to ones inside of the .app rather than the ones in /tmp/dep. See all those
> lines fly by in the install process? Check out the manual for
> install_name_tool. And if you run 'otool -L /tmp/dep/lib/libshoes.dylib' for
> example, you'll see this:
>
> $ otool -L /tmp/dep/lib/libruby.dylib
>
> /tmp/dep/lib/libruby.dylib:
>
>  /tmp/dep/lib/libruby.1.9.1.dylib (compatibility version 1.9.1, current
>> version 1.9.1)
>
>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>> 125.2.10)
>
>
> That first line is changed by doing install_name_tool.id, and the second
> two lines are the ones it references, which the first is changed by doing
> install_name_tool -change.
>
> What I thought was the problem was that not all of these references were
> getting properly changed. When I started running otool -L on all of the
> dylibs inside of the generated .app, it seemed like a bunch of them still
> referred to /tmp/dep! hence this commit:
> https://github.com/shoes/shoes/commit/19418cc0bbc19714edcc45134144d7fbe2134058
>
> A bunch of extra install_name_tool calls. Now, after that, it was still
> complaining about an undefined constant UTF_7. So I added that first line in
> lib/shoes.rb to define it. Incredibly hacky. And, on my machine, it now
> works.
>
> I'm still not comfortable with this reference, exactly. And since it
> doesn't quite work on your machine, I'm still not quite sure what isn't
> right.
>
> Thoughts?
>

Re: [shoes] Building shoes for 32-bit OSX

From:
Date:
2011-05-31 @ 17:01
Hi, all.

> Steve,
> 
> I've been looking into install_name_tool, and I think I've made some 
progress on this front. The otool -L and otool -D output looks good on all
my lib files, and on shoes-bin (see my github fork for Rakefile changes). 
However, Shoes.app still crashes silently, and shoes-bin and shoes-launch 
still fail with "UTF_7 is not a class". Starting to look into main.skel to
pinpoint where the error comes from.
> 
> Eric

Eric, dosen't Shoes work if you change "tmp/dep" name into, for example, 
"tmp/dep-dummy"?
When I succeed in Shoes build, I always change the directory name where 
original dependencies exist. Or my Shoes dosen't start up.

Well, it builds using 10.6―it just doesn't run :) I can switch gears and 
work on getting it to build against 10.5 first, though. Out of curiosity, 
what is the benefit of using 10.5 for the 32-bit build? I know 10.5 
includes support for 10.3, but I don't think we're using that, are we?

I don't need 10.3, neither. But 10.6 users can execute Shoes-10.5, the 
opposite is...?
Working on 32bit-10.6 could apply to 10.5, then it's OK, I think:)


I've been rambling about Encoding.list...
Steve, I'd like you to send me your Shoes.app. I want to look into the 
"enc" directory.
Would you?

-vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
vhuto
Date:
2011-06-02 @ 07:06
Hmm. calm.

Shoes.app do
  test_code = %q{
    # Edit here!
    cd 
'/Users/vhuto/Desktop/shoes/Shoes.app/Contents/MacOS/ruby/lib/x86_64-darwin10.7.0/'

    Dir['**/*.bundle'].map {|bun| bun.sub /.bundle/, '' }.find_all 
{|library| not require library }
  }

  test_edit = edit_box( width:1.0, text:test_code )

  button('I cannot require...') do
    @result.text= eval(test_edit.text).join("\n")
  end

  @result = para
end

This App says that my Shoes cannot require these libraries...
* digest/md5
* digest/sha1
* digest
* dl
* etc
* fcntl
* fiddle
* openssl
* socket
* stringio
* strscan
* syck
* zlib

But these `otool -l` look fine.
Some encodings seem to be not bundled on my environment same as these...
...
...
But wait! OMG!! I found that
  MY SHOES CAN GET FULL ENCODING.LIST AFTER RUNNNIG THE ABOVE APP!!!!!!!!


I wonder why these encodngs should be required manually, thought I CAN GET!

Now this code works!
  "\u3042".encode 'shift_jis'
  => "\x{82A0}"

So I think encoding conversion is working, too ;)

-vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
Steve Klabnik
Date:
2011-06-02 @ 12:15
Interesting! 

Ill try this with my Shoes, and post a link to my copy tonight. I was 
playing with some things and broke it. :( 

Re: [shoes] Building shoes for 32-bit OSX

From:
vhuto
Date:
2011-06-03 @ 06:38
Hi, the breaker:)

But I would rather worry how is Eric doing...
If his and my conditions are too different, it might be better that I 
separate my list from here...
I go ahead for now:)

I edited shoes/lib/shoes.rb thus:
===============================
Dir.chdir "#{DIR}/ruby/lib/x86_64-darwin10.7.0/enc/" do
  Dir['**/*.bundle'].each {|bun| require bun.sub(/.bundle/, '') }
end

#class Encoding
#  %w[UTF_7 UTF_16BE UTF_16LE UTF_32BE UTF_32LE].each do |enc|
#    eval "class #{enc};end"
#  end
#end

#class Encoding
# %w[ASCII_8BIT UTF_16BE UTF_16LE UTF_32BE UTF_32LE US_ASCII].each do |ec|
#   eval "#{ec} = '#{ec.sub '_', '-'}'"# end unless RUBY_PLATFORM =~ /linux/
#end
===============================


This build enables me to boot up Shoes without changing "/tmp" directory 
name. Progress new!

But if I leave the directory,
  /tmp/dep/lib/ruby/1.9.1/x86_64-darwin10.7.0/enc
as it is, Console.app shouts tons of report that each of Encoding 
Constants is already initialized.
===============================
11/06/03 2:15:55	[0x0-0xb30b3].org.hackety.shoes[18848]	
/Users/vhuto/Desktop/shoes/Shoes.app/Contents/MacOS/ruby/lib/x86_64-darwin10.7.0/enc/encdb.bundle:
warning: already initialized constant ASCII_8BIT
11/06/03 2:15:55	[0x0-0xb30b3].org.hackety.shoes[18848]	
/Users/vhuto/Desktop/shoes/Shoes.app/Contents/MacOS/ruby/lib/x86_64-darwin10.7.0/enc/encdb.bundle:
warning: already initialized constant Big5
.
.
.
===============================
This report dosen't come when I change that directory name, which tells 
that even after install_name_tool, some reference to the original 
dependencies still remains, I think...
But I remember you said Encoding.list is fine on your Shoes from the outset.
So, it occurs only on my environment??

Of course there is more C-like solution rather than such a direct bundle 
requiring.., isn't it?


-vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
Steve Klabnik
Date:
2011-06-03 @ 13:01
>
> Of course there is more C-like solution rather than such a direct bundle
> requiring.., isn't it?
>

I am not sure. This is a part of Ruby that I don't know a whole lot about,
to be honest. Hmm...

Also, I apologize for being so late with my Shoes. I forgot that yesterday
was a meeting of my local Ruby Brigade, so I ended up doing that all evening
instead of compiling. I _might_ get it in tonight, we'll see; I'm leaving on
a trip to New York.

Re: [shoes] Building shoes for 32-bit OSX

From:
vhuto
Date:
2011-06-03 @ 13:43
Wow, New York! Then I can wait till your return:) Have a fun!!


I also apologize here. My last app code has a bug :(
> Shoes.app do
>  test_code = %q{
>    # Edit here!
>    cd 
'/Users/vhuto/Desktop/shoes/Shoes.app/Contents/MacOS/ruby/lib/x86_64-darwin10.7.0/'
> 
>    Dir['**/*.bundle'].map {|bun| bun.sub /.bundle/, '' }.find_all 
{|library| not require library }
>  }
>  test_edit = edit_box( width:1.0, text:test_code )
>  button('I cannot require...') do
>    @result.text= eval(test_edit.text).join("\n")
>  end
>  @result = para
> end
> 
> This App says that my Shoes cannot require these libraries...
> * digest/md5
> * digest/sha1
> * digest
> * dl
> * etc
> * fcntl
> * fiddle
> * openssl
> * socket
> * stringio
> * strscan
> * syck
> * zlib

These libraries are already required. So the :require method returns false
to them.
There is nothing wrong about them x)

-vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-06-03 @ 17:46
Vhuto,

I'm sorry to be slow in responding. This week, I don't have much time
to look into our Shoes problem, but I'm excited by your success.
Sounds like you are getting close! I'll have more time after this
week.

Eric

On Jun 3, 2011, at 1:38 AM, vhuto <vhuto@me.com> wrote:

> Hi, the breaker:)
>
> But I would rather worry how is Eric doing...
> If his and my conditions are too different, it might be better that I 
separate my list from here...
> I go ahead for now:)
>
> I edited shoes/lib/shoes.rb thus:
> ===============================
> Dir.chdir "#{DIR}/ruby/lib/x86_64-darwin10.7.0/enc/" do
>  Dir['**/*.bundle'].each {|bun| require bun.sub(/.bundle/, '') }
> end
>
> #class Encoding
> #  %w[UTF_7 UTF_16BE UTF_16LE UTF_32BE UTF_32LE].each do |enc|
> #    eval "class #{enc};end"
> #  end
> #end
>
> #class Encoding
> # %w[ASCII_8BIT UTF_16BE UTF_16LE UTF_32BE UTF_32LE US_ASCII].each do |ec|
> #   eval "#{ec} = '#{ec.sub '_', '-'}'"# end unless RUBY_PLATFORM =~ /linux/
> #end
> ===============================
>
>
> This build enables me to boot up Shoes without changing "/tmp" directory
name. Progress new!
>
> But if I leave the directory,
>  /tmp/dep/lib/ruby/1.9.1/x86_64-darwin10.7.0/enc
> as it is, Console.app shouts tons of report that each of Encoding 
Constants is already initialized.
> ===============================
> 11/06/03 2:15:55    [0x0-0xb30b3].org.hackety.shoes[18848]    
/Users/vhuto/Desktop/shoes/Shoes.app/Contents/MacOS/ruby/lib/x86_64-darwin10.7.0/enc/encdb.bundle:
warning: already initialized constant ASCII_8BIT
> 11/06/03 2:15:55    [0x0-0xb30b3].org.hackety.shoes[18848]    
/Users/vhuto/Desktop/shoes/Shoes.app/Contents/MacOS/ruby/lib/x86_64-darwin10.7.0/enc/encdb.bundle:
warning: already initialized constant Big5
> .
> .
> .
> ===============================
> This report dosen't come when I change that directory name, which tells 
that even after install_name_tool, some reference to the original 
dependencies still remains, I think...
> But I remember you said Encoding.list is fine on your Shoes from the outset.
> So, it occurs only on my environment??
>
> Of course there is more C-like solution rather than such a direct bundle
requiring.., isn't it?
>
>
> -vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
vhuto
Date:
2011-06-10 @ 10:41
Hello, OSX guys.

I'm now Githuber. I don't know how to get ahead, but it's exciting!

Not knowing how I should treat Encoding, it's task.rb only.
* Copy libruby.dylib's symbolics
* Important install_name_tool
    (concerning with gem install?)
* Not important install_name_tool

Please on me.

-vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-06-18 @ 10:41
Vhuto,

I have finally gotten your new build code from Github. I merged in your
latest commit, 
8dde037<https://github.com/vhuto/shoes/commit/8dde03711777a71c4b9e5ac8b41efeeb0a9915c1>,
but no luck so far. :( Still getting the UTF_7 error message.

However, you made me remember that I had been compiling my extensions
against my system ruby, not the packaged ruby. This is a good thing to know.
See my separate post on this problem.

Eric

On Fri, Jun 10, 2011 at 5:41 AM, vhuto <vhuto@me.com> wrote:

> Hello, OSX guys.
>
> I'm now Githuber <https://github.com/vhuto/shoes/commits/OSX>. I don't
> know how to get ahead, but it's exciting!
>
> Not knowing how I should treat Encoding, it's task.rb only.
> * Copy libruby.dylib's symbolics
> * Important install_name_tool
>     (concerning with gem install?)
> * Not important install_name_tool
>
> Please on me.
>
> -vhuto
>

Re: [shoes] Building shoes for 32-bit OSX

From:
vhuto
Date:
2011-06-11 @ 09:28
Uh-oh, I found my short tasks.rb is not good when I call "shoes-bin" on 
the command line.
I have not called Shoes from command line, but it's useful.
It seems that this call doesn't go via "shoes-launch" and 
DYLD_LIBRARY_PATH is not set, then fails.
Commands "shoes" and "shoes-launch" are OK.

So, should I think over this command?
If so, I'll look over my Shoes edition again.

-vhuto

Re: [shoes] Building shoes for 32-bit OSX

From:
Steve Klabnik
Date:
2011-05-31 @ 11:11
Cool! These changes look good. Also, interesting, you're building against 
10.6, even though you're 32 bit? What happens if you build against the 
10.5 SDK? It should be on your computer, too.

Originally, we were talking about doing 32-bit 10.5 and 64 bit 10.6 
builds, basically. I didn't realize we could do 32-bit 10.6 builds that 
easily, too.

Does Shoes.app still crash if you have my UTF-monkeypatching? I guess it 
does, you didn't delete those lines... 

On Monday, May 30, 2011 at 11:28 PM, Eric Watson wrote:

> Steve,
> 
> I've been looking into install_name_tool, and I think I've made some 
progress on this front. The otool -L and otool -D output looks good on all
my lib files, and on shoes-bin (see my github fork 
(https://github.com/wasnotrice/shoes/commits/OSX-32bit) for Rakefile 
changes). However, Shoes.app still crashes silently, and shoes-bin and 
shoes-launch still fail with "UTF_7 is not a class". Starting to look into
main.skel to pinpoint where the error comes from. 
> 
> Eric 
> 
> 
> 
> > Now, when Shoes gets built, it makes a ton of dynamic libraries, 
.dylibs, and re-roots them into the .app by using install_name_tool 
-change to refer to ones inside of the .app rather than the ones in 
/tmp/dep. See all those lines fly by in the install process? Check out the
manual for install_name_tool. And if you run 'otool -L 
/tmp/dep/lib/libshoes.dylib' for example, you'll see this: 
> > 
> > >  $ otool -L /tmp/dep/lib/libruby.dylib 
> > >  /tmp/dep/lib/libruby.dylib:
> > > /tmp/dep/lib/libruby.1.9.1.dylib (compatibility version 1.9.1, 
current version 1.9.1)
> > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 125.2.10)
> > 
> > 
> > That first line is changed by doing install_name_tool.id 
(http://install_name_tool.id), and the second two lines are the ones it 
references, which the first is changed by doing install_name_tool -change.

> > 
> > What I thought was the problem was that not all of these references 
were getting properly changed. When I started running otool -L on all of 
the dylibs inside of the generated .app, it seemed like a bunch of them 
still referred to /tmp/dep! hence this commit: 
https://github.com/shoes/shoes/commit/19418cc0bbc19714edcc45134144d7fbe2134058

> > 
> > A bunch of extra install_name_tool calls. Now, after that, it was 
still complaining about an undefined constant UTF_7. So I added that first
line in lib/shoes.rb to define it. Incredibly hacky. And, on my machine, 
it now works. 
> > 
> > I'm still not comfortable with this reference, exactly. And since it 
doesn't quite work on your machine, I'm still not quite sure what isn't 
right.
> > 
> > Thoughts? 

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-31 @ 14:42
On May 31, 2011, at 6:12 AM, Steve Klabnik <steve@steveklabnik.com> wrote:

 Cool! These changes look good. Also, interesting, you're building against
10.6, even though you're 32 bit?


That's Xcode4 talking again. It moved out all pre10.6 sdks. Given that, I
figured building against 10.6, with a deployment target of 10.4, would be
most flexible.

What happens if you build against the 10.5 SDK? It should be on your
computer, too.


I'll give it a try. I do have it.

Originally, we were talking about doing 32-bit 10.5 and 64 bit 10.6 builds,
basically. I didn't realize we could do 32-bit 10.6 builds that easily, too.


Well, it builds using 10.6—it just doesn't run :) I can switch gears and
work on getting it to build against 10.5 first, though. Out of curiosity,
what is the benefit of using 10.5 for the 32-bit build? I know 10.5 includes
support for 10.3, but I don't think we're using that, are we?

Does Shoes.app still crash if you have my UTF-monkeypatching? I guess it
does, you didn't delete those lines...


Yes, exactly.

 On Monday, May 30, 2011 at 11:28 PM, Eric Watson wrote:

Steve,

I've been looking into install_name_tool, and I think I've made some
progress on this front. The otool -L and otool -D output looks good on all
my lib files, and on shoes-bin (see my github
fork<https://github.com/wasnotrice/shoes/commits/OSX-32bit>for
Rakefile changes). However, Shoes.app still crashes silently, and
shoes-bin and shoes-launch still fail with "UTF_7 is not a class". Starting
to look into main.skel to pinpoint where the error comes from.

Eric



Now, when Shoes gets built, it makes a ton of dynamic libraries, .dylibs,
and re-roots them into the .app by using install_name_tool -change to refer
to ones inside of the .app rather than the ones in /tmp/dep. See all those
lines fly by in the install process? Check out the manual for
install_name_tool. And if you run 'otool -L /tmp/dep/lib/libshoes.dylib' for
example, you'll see this:

$ otool -L /tmp/dep/lib/libruby.dylib
/tmp/dep/lib/libruby.dylib:
 /tmp/dep/lib/libruby.1.9.1.dylib (compatibility version 1.9.1, current
version 1.9.1)
 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.10)


That first line is changed by doing install_name_tool.id, and the second two
lines are the ones it references, which the first is changed by doing
install_name_tool -change.

What I thought was the problem was that not all of these references were
getting properly changed. When I started running otool -L on all of the
dylibs inside of the generated .app, it seemed like a bunch of them still
referred to /tmp/dep! hence this commit:
https://github.com/shoes/shoes/commit/19418cc0bbc19714edcc45134144d7fbe2134058

A bunch of extra install_name_tool calls. Now, after that, it was still
complaining about an undefined constant UTF_7. So I added that first line in
lib/shoes.rb to define it. Incredibly hacky. And, on my machine, it now
works.

I'm still not comfortable with this reference, exactly. And since it doesn't
quite work on your machine, I'm still not quite sure what isn't right.

Thoughts?

Re: [shoes] Building shoes for 32-bit OSX

From:
Steve Klabnik
Date:
2011-05-31 @ 15:06
> That's Xcode4 talking again. It moved out all pre10.6 sdks. Given that, I
figured building against 10.6, with a deployment target of 10.4, would be
most flexible.

Oh, I didn't notice that. Wait, you can deploy it on stuff as early as 10.4?
I thought building against the 10.6 sdk meant it could only be deployed
there. TIL.

> Well, it builds using 10.6—it just doesn't run :) I can switch gears and
work on getting it to build against 10.5 first, though. Out of curiosity,
what is the benefit of using 10.5 for the 32-bit build? I know 10.5 includes
support for 10.3, but I don't think we're using that, are we?

No, see my above confusion. I'd like to support 10.5+, screw 10.3. Heh.

> Yes, exactly.

Well, I guess I knew that wasn't a real solution from the beginning.

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-24 @ 17:57
On Tue, May 24, 2011 at 7:05 AM, Steve Klabnik <steve@steveklabnik.com>wrote:
>
> Looking inside the Ruby source, UTF_7 is only mentioned twice: Once in 
the dist/ruby/lib/uri/common.rb
> you found, and once here:
> https://github.com/ruby/ruby/blob/trunk/enc/utf_7.h
>

I think the Ruby source really does only contain the string UTF_7 once, in
uri/common.rb. This other file is called 'utf_7.h', but the string inside
the file is UTF-7, not UTF_7. Still, it is a connection, and this seems like
the spot where a UTF_7 class should be created. Here are some other
UTF-7-related spots in the Ruby source:

encoding.c, line 430<https://github.com/ruby/ruby/blob/trunk/encoding.c#L430>

ext/win32ole/win32ole.c<https://github.com/ruby/ruby/blob/trunk/ext/win32ole/win32ole.c>(7
lines, but probably not the issue here)
lib/net/imap.rb, line
936<https://github.com/ruby/ruby/blob/trunk/lib/net/imap.rb#L936>
lib/net/imap.rb, line
952<https://github.com/ruby/ruby/blob/trunk/lib/net/imap.rb#L952>

Also related, possibly, the ENC_DUMMY define used in enc/utf_7:

enc/encdb.c, line 19<https://github.com/ruby/ruby/blob/trunk/enc/encdb.c#L19>

and the actual function:

encoding.c, line 374<https://github.com/ruby/ruby/blob/trunk/encoding.c#L374>

But there is a problem here. These references are from github HEAD. On my
clone of ruby github:

imac:ruby eric$ pwd
/Users/eric/projects/ruby
imac:ruby eric$ Ack UTF[-_]?7
enc/utf_7.h
3:ENC_DUMMY("UTF-7");
4:ENC_ALIAS("CP65000", "UTF-7");

encoding.c
430: * Returns 1 when the encoding is Unicode series other than UTF-7 else
0.

ext/win32ole/win32ole.c
903:    ENC_MACHING_CP(enc, "UTF-7", 65000);
964:        case CP_UTF7:
973:            rb_raise(eWIN32OLERuntimeError, "codepage should be
WIN32OLE::CP_ACP, WIN32OLE::CP_OEMCP, WIN32OLE::CP_MACCP,
WIN32OLE::CP_THREAD_ACP, WIN32OLE::CP_SYMBOL, WIN32OLE::CP_UTF7,
WIN32OLE::CP_UTF8, or installed codepage.");
1039:  case CP_UTF7:
1046:            rb_raise(eWIN32OLERuntimeError, "codepage should be
WIN32OLE::CP_ACP, WIN32OLE::CP_OEMCP, WIN32OLE::CP_MACCP,
WIN32OLE::CP_THREAD_ACP, WIN32OLE::CP_SYMBOL, WIN32OLE::CP_UTF7,
WIN32OLE::CP_UTF8, or installed codepage.");
1308:            cp == CP_UTF7 ||
9160:    rb_define_const(cWIN32OLE, "CP_UTF7", INT2FIX(CP_UTF7));

lib/net/imap.rb
197:  # [[UTF7]]
198:  #    Goldsmith, D. and Davis, M., "UTF-7: A Mail-Safe Transformation
Format of
928:    # Decode a string from modified UTF-7 format to UTF-8.
930:    # UTF-7 is a 7-bit encoding of Unicode [UTF7].  IMAP uses a
951:    # Encode a string from UTF-8 format to modified UTF-7.

lib/uri/common.rb
841:  HTML5ASCIIINCOMPAT = [Encoding::UTF_7, Encoding::UTF_16BE,
Encoding::UTF_16LE,

test/win32ole/test_win32ole.rb
482:    def test_const_CP_UTF7
483:      assert_equal(65000, WIN32OLE::CP_UTF7)

And now on my download of ruby-1.9.2-p180:

imac:ruby-1.9.2-p180 eric$ Ack UTF[-_]?7
imac:ruby-1.9.2-p180 eric$

There's nothing there!!! Not even the enc/utf_7.h file exists:

imac:ruby-1.9.2-p180 eric$ ls enc | grep utf
imac:ruby-1.9.2-p180 eric$

Surely this might have something to do with the problem.

>
>
As you can see, it's a dummy encoding. When you delete the reference in
> uri/common, it should complain about the next encoding. When you delete the
> entire array, it SHOULD actually start up. This is where I was at a few days
> ago.
>

I tried this, but it didn't make a difference--I think there's a linking
problem, as you describe below. Also, this whole Encoding thing is new in
1.9, where in a regular ruby, Encoding::UTF_7 *is* a class:

imac:ruby eric$ rvm use 1.8.7
Using /Users/eric/.rvm/gems/ruby-1.8.7-p334
imac:ruby eric$ irb
ruby-1.8.7-p334 :001 > Encoding::UTF_7
NameError: uninitialized constant Encoding
from (irb):1
ruby-1.8.7-p334 :002 > quit
imac:ruby eric$ rvm use 1.9.2-p180
Using /Users/eric/.rvm/gems/ruby-1.9.2-p180
imac:ruby eric$ irb
ruby-1.9.2-p180 :001 > Encoding::UTF_7
 => #<Encoding:UTF-7 (dummy)>
ruby-1.9.2-p180 :002 > Encoding::UTF_7.class
 => Encoding
ruby-1.9.2-p180 :003 >

Now, when Shoes gets built, it makes a ton of dynamic libraries, .dylibs,
> and re-roots them into the .app by using install_name_tool -change to refer
> to ones inside of the .app rather than the ones in /tmp/dep. See all those
> lines fly by in the install process? Check out the manual for
> install_name_tool. And if you run 'otool -L /tmp/dep/lib/libshoes.dylib' for
> example, you'll see this:
>
> $ otool -L /tmp/dep/lib/libruby.dylib
>
> /tmp/dep/lib/libruby.dylib:
>
>  /tmp/dep/lib/libruby.1.9.1.dylib (compatibility version 1.9.1, current
>> version 1.9.1)
>
>  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
>> 125.2.10)
>
>
> That first line is changed by doing install_name_tool.id, and the second
> two lines are the ones it references, which the first is changed by doing
> install_name_tool -change.
>
> What I thought was the problem was that not all of these references were
> getting properly changed. When I started running otool -L on all of the
> dylibs inside of the generated .app, it seemed like a bunch of them still
> referred to /tmp/dep! hence this commit:
> https://github.com/shoes/shoes/commit/19418cc0bbc19714edcc45134144d7fbe2134058
>
> A bunch of extra install_name_tool calls. Now, after that, it was still
> complaining about an undefined constant UTF_7. So I added that first line in
> lib/shoes.rb to define it. Incredibly hacky. And, on my machine, it now
> works.
>
> I'm still not comfortable with this reference, exactly. And since it
> doesn't quite work on your machine, I'm still not quite sure what isn't
> right.
>
> Thoughts?
>

I agree this seems like the problem area. I need to look into
install_name_tool and friends. But for now, check out my shoes-bin. I think
it illustrates this problem. Those paths should all be internal to
Shoes.app, shouldn't they?

Îúíþ 
8__PAGEZEROŒ__TEXT__text__TEXT\
°\
€__symbol_stub__TEXT

N
€__stub_helper__TEXT\
\€__cstring__TEXTì
Éì__unwind_info__TEXTµHµH__DATA
__program_vars__DATA __nl_symbol_ptr__DATA 

__la_symbol_ptr__DATA  4 __data__DATAT T|__OBJC0
__image_info__OBJC0 8__LINKEDIT@0„"€00880<1t°1D3@
P
Ð2


/usr/lib/dyld̹ÿï i7+¢ÖJ
Û
ÞP\

T 
/usr/local/Cellar/ruby/1.9.2-p180/lib/libruby.1.9.1.dylib
Lû*û*/usr/local/Cellar/cairo/1.10.2/lib/libcairo.2.dylib
Xñ
ñ
/usr/local/Cellar/pango/1.28.0/lib/libpangocairo-1.0.0.dylib
P/usr/local/Cellar/giflib/4.1.6/lib/libgif.4.1.6.dylib
P/usr/local/Cellar/pixman/0.20.2/lib/libpixman-1.0.dylib
H

/usr/local/Cellar/jpeg/8c/lib/libjpeg.8.dylib
Pñ
ñ
/usr/local/Cellar/pango/1.28.0/lib/libpango-1.0.0.dylib
Tñ
ñ
/usr/local/Cellar/glib/2.28.6/lib/libgobject-2.0.0.dylib
Tñ
ñ
/usr/local/Cellar/glib/2.28.6/lib/libgmodule-2.0.0.dylib
Tñ
ñ
/usr/local/Cellar/glib/2.28.6/lib/libgthread-2.0.0.dylib
Pñ
ñ
/usr/local/Cellar/glib/2.28.6/lib/libglib-2.0.0.dylib
P
/usr/local/Cellar/gettext/0.18.1.1/lib/libintl.8.dylib

8@executable_path/libshoes.dylib
4
}/usr/lib/libSystem.B.dylibj‰åƒäðƒì‹]‰
$M‰L$ƒÃÁãˉ\$‹ƒÃ
Àu÷‰\$
è
‰$èôU‰åWVSì\è]‹E
‰
Ìïÿÿ‹“q‹
‰Mä1ÉèF‹
Ìïÿÿ‹‰
Ôïÿÿƒ}~E‹•ÌïÿÿƒÂ‰•Ðïÿÿ‹Ìïÿÿ‹qÇ
Äïÿÿü»A¹ó¦¸t
¶Fÿ¶Oÿ)È
Àt0è$
À„Ÿè1À‹“q‹Mä3

¿Ä\[^_]Ë
Ôïÿÿ‰D$
ƒI‰D$ÇD$½äïÿÿ‰<$èÃ=ÿw±‹uƒî‹•Ìïÿÿ‹‰B
àïÿÿ‰$è‹è€‰<$èr‹Ðïÿÿ‰L$‰4$èr‰$èpéhÿÿÿ‹
ÌïÿÿƒÀ‹Uƒê‰D$‰$èhƒ‰D$‹
Ôïÿÿ‰$èVé)ÿÿÿè
‹
$Ãÿ%  ÿ%$ ÿ%( ÿ%, ÿ%0 ÿ%4 ÿ%8 ÿ%< ÿ%@ ÿ%D ÿ%H ÿ%L ÿ%P
hézhéph-éfh9é\hOéRh`éHhwé>h‹é4h é*hµé hÈéhÚé
hðéh ÿ% --rubybegin;DIR =
File.expand_path(File.dirname(%%q<%s>));$:.replace([DIR+'/ruby/lib/'+PLATFORM,
DIR+'/ruby/lib', DIR+'/lib', '.']);require 'shoes/cache';DIR;rescue Object
=> e;puts(e.message);end/


\
44
4
T X \ `
\
f
p
z
„
Ž
˜
¢
¬
¶
À
Ê
Ô

@___stack_chk_guardQr
@dyld_stub_binder€ôÿÿÿÿÿÿÿÿr

@__NSGetEnvironr$
@___stack_chk_failr(

@_exitr,@_rb_eval_stringr0@_ruby_initr4@_ruby_init_stackr8@_ruby_optionsr<@_ruby_run_noder@@_ruby_snprintfrD
@_shoes_finalrH
@_shoes_initrL
@_shoes_set_argvrP
@_shoes_start_
startK_'mainPNXArgUenvirongmh_execute_headerG_prognamelÜšc]vbÔ
Ø Ü à 
€
 ! T ) X 1 ` =Q \ Zš
`\
fu‡š
°»ÌÚéø
!
.

@@




___i686.get_pc_thunk.bx_pvars_NXArgc_NXArgv___progname__mh_execute_header_environ_mainstart__NSGetEnviron___stack_chk_fail___stack_chk_guard_exit_rb_eval_string_ruby_init_ruby_init_stack_ruby_options_ruby_run_node_ruby_snprintf_shoes_final_shoes_init_shoes_set_argv_shoes_startdyld_stub_binder


Eric

Re: [shoes] Building shoes for 32-bit OSX

From:
Eric Watson
Date:
2011-05-25 @ 01:57
>
> What I thought was the problem was that not all of these references were
>> getting properly changed. When I started running otool -L on all of the
>> dylibs inside of the generated .app, it seemed like a bunch of them still
>> referred to /tmp/dep! hence this commit:
>> https://github.com/shoes/shoes/commit/19418cc0bbc19714edcc45134144d7fbe2134058
>>
>> A bunch of extra install_name_tool calls. Now, after that, it was still
>> complaining about an undefined constant UTF_7. So I added that first line in
>> lib/shoes.rb to define it. Incredibly hacky. And, on my machine, it now
>> works.
>>
>> I'm still not comfortable with this reference, exactly. And since it
>> doesn't quite work on your machine, I'm still not quite sure what isn't
>> right.
>>
>
One problem with my build is that, in the extra install_name_tool calls, I
didn't change the old install name from /tmp/dep to /usr/local. The man page
says this should cause the calls to be ignored, which they seem to have
been. I'll have to redo that.

Another problem I noticed in my process is that I built against ruby-1.9.2,
which I shouldn't have. I think I got confuses by the fact that the link on
the wiki didn't work (I thought it was because the link text was bad, but
actually it was just an ftp link that the browser didn't handle), so I
browsed to ruby-lang, except that they only have 1.9.2 there, which I didn't
think about. Anyway, I updated the wiki with a clickable http link to
1.9.1-p387, and downloaded it. I'll try building against that and see if
there's any difference.

Eric

Re: [shoes] Building shoes for 32-bit OSX

From:
Steve Klabnik
Date:
2011-05-25 @ 02:05
1.9.1 should work, and 1.9.2 is what we're working on for a 3.1 release.