Universal binary Installs?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Why is there a separate install for PPC and Intel  
2. Why isn't the Universal binary used? Leopard is the same API either way 
3.

What is the expected output? What do you see instead?

  OSX-installer-Universal-Leopard.dmg

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by andre.bo...@gmail.com on 5 Dec 2008 at 8:16

[GoogleCodeExporter]

Well, it's probably because I'm not very smart at this :)  Is the installer 
installing with universal architecture right 
now?  

I used to remember how to query the architecture for a compiled before, but 
can't seem to remember

Original comment by timchar...@gmail.com on 5 Dec 2008 at 8:25

• Changed state: Accepted

[GoogleCodeExporter]

http://developer.apple.com/opensource/buildingopensourceuniversal.html

Well, you have the option if you are building the OSX packages to set it up so 
that
the PPC and Intel versions are together in one installer. It will then detect 
the OS/
Hardware and install appropriate to the user's machine.

The link above walks you through the process. I will list it again:

http://developer.apple.com/opensource/buildingopensourceuniversal.html

Original comment by andre.bo...@gmail.com on 6 Dec 2008 at 4:30

[GoogleCodeExporter]

Here's a patch to build a "universal" binary.

Original comment by pphaneuf on 28 Apr 2009 at 4:12

Attachments:

• build-as-universal.diff

[GoogleCodeExporter]

I found out the flags for 64-bit: "-arch ppc64" and "-arch x86_64", for PPC and
Intel, respectively. You can just add everything and have quite universal 
binaries. :-)

Original comment by pphaneuf on 28 Apr 2009 at 4:28

[GoogleCodeExporter]

Here is a build.sh file that will correctly build universal binaries that 
include
ppc, ppc64, i386, and x86_64 architectures in it.  Note the CFLAGS and the 
LDFLAGS
are what accomplish this.

Other notes about my changes:

1. I removed the copylibs.sh call because dylibs on OS X have their full path
embedded in them and you cannot simply copy them to a new directory and expect 
them
to work.  In addition, the packages you have been distributing do not link to 
these
libraries (verified using "otool -L {executable filename}") so there is 
absolutely no
point to having them.  Building with the default system libraries appears to 
work
perfectly fine and that's what you were actually linking against anyway (again,
verified using otool against the shipping dmg).

2. I abstracted out the default prefix to a variable.  This was so I could 
easily
test my changes without changing my default git install by having the test 
version go
to a different directory.  While this doesn't completely do the trick because
/usr/local/git is hardcoded in UserScripts/symlink_git_hardlinks.rb, it's a 
good idea.

3. Also, same with calling sudo.  I made it a variable so that way I could 
simply
install to a local directory and not have to worry about typing in my password. 
 If
someone wants to mess with it they can simply undefine it (or set it to 
nothing) and
sudo won't be called.

Strictly speaking, items 2 & 3 are not directly related to this issue, however, 
I
didn't feel like backing out those changes when uploading my build.sh.

If you have any questions about the CFLAGS or LDFLAGS, please let me know. 
Otherwise, I look forward to seeing fully universal binaries shipping very 
soon! :-)

Original comment by clubjuggler on 2 Jun 2009 at 4:55

Attachments:

• build.sh

[GoogleCodeExporter]

Hi clubjuggler

It looks like you are completely right!  Still... I'm a little bit confused.  
When I
did this installer, my point was to make it so we could install git on a machine
without developer tools.  Until I copied the libs with it, it didn't work (I'm 
quite
certain of it, I tried several times).  But... otools says they aren't used, and
you're right, the path dependencies are not being used.  Hmmmmm.

Do you know by chance if all these libs are available without having installed 
xcode
before hand? 

    /usr/lib/libcurl.4.dylib (compatibility version 5.0.0, current version 5.0.0)
    /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
    /usr/lib/libssl.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)

If not... I'm pretty sure they'll need to be bundled with the git installer in 
order
for it to work without the developer tools.

Original comment by timchar...@gmail.com on 12 Jun 2009 at 4:14

[GoogleCodeExporter]

By the way, I've moved the build stuff over to github.  I've quit hoping the 
google
would move over to git :S

http://github.com/timcharper/git_osx_installer

Original comment by timchar...@gmail.com on 12 Jun 2009 at 4:25

[GoogleCodeExporter]

I've built the binaries from the build file you upload.  They turned out super 
huge
(50MB).  Is there a way to reduce the size?  Or would I need to build 4 separate
installers?  (ie - is the size quadrupled in size because the number of 
architectures
is quadrupled?)

Original comment by timchar...@gmail.com on 12 Jun 2009 at 4:46

[GoogleCodeExporter]

OK, I rebuilt them using just the -i386 flag and it weighed in at 14MB.  That's
better, so I'm guessing universal binaries are just fat.  I think having the 
download
size so big would be kind of prohibitive, don't you?

I've got to find a way to make the Mac OS X Packager package files 
automatically so I
could script this to build and deploy ppc, ppc64, i386 and x86_64 packages.

I noticed you added the flags "-isysroot /Developer/SDKs/MacOSX10.5.sdk".  What 
do
these do?

Original comment by timchar...@gmail.com on 12 Jun 2009 at 4:51

[GoogleCodeExporter]

I just checked on a system that was just re-installed, all the libraries you 
listed
are present.

Universal binaries are, quite simply, multiple binaries glued together. In the 
old
days, they were called "fat binaries", which is well representative of their 
size. :-)

I see that your package unpacks to 13.8MB in /usr/local/git, my ppc/i386 version
takes 20MB, and compressing that makes it 8.6MB, less than 3MB larger. That 
seems
reasonable.

Just i386 and ppc sounds reasonable to me, I don't think there's a significant
advantage to 64-bit binaries for git.

Original comment by pphaneuf on 12 Jun 2009 at 5:42

[GoogleCodeExporter]

Hi @timcharper, yes the disadvantage to fat binaries is that all the 
architectures
are basically put together, just as @pphaneuf says.  Most likely simply having a
ppc/i386 version would do for most everyone.  You could also have an i386/x86_64
version if people want 64 bit (that way it would work on any intel machine).

As for the question about the "-isysroot /Developer/SDKs/MacOSX10.5.sdk" flags, 
that
specifically links to the 10.5 sdk.  You could also change it to be "-isysroot
/Developer/SDKs/MacOSX10.4u.sdk" to target the 10.4 universal sdk (but I had 
problems
with that).  The reason for using it is that it guarantees which SDK the 
binaries are
linked against (and will let you compile for 10.4 even though you're on a 10.5
machine).  Without that, you're simply compiling against whatever the installed
system binaries are which could be either 10.5 (if you're on leopard) or 10.4 
(if
you're on tiger).  The upshot of that, however, is that things compiled against 
the
10.5 sdk, obviously, won't work on 10.4, so it's a tradeoff to what you want, 
really.
 If you can get it to work with the 10.4 sdk, I'd suggest doing that since it would
let more people be able to use the binaries.  (Sorry, but I don't remember 
right now
what the error was that I got trying to link against the 10.4 sdk.)

Original comment by clubjuggler on 12 Jun 2009 at 3:23

[GoogleCodeExporter]

Now that the build process is much more automated, we're getting to the point 
where we can build all 
architectures.

We'd simply have to modify the build script to pump them all out. It could be 
done fairly easily. Anyone want to 
tackle it?

Original comment by timchar...@gmail.com on 17 Sep 2009 at 7:31

[GoogleCodeExporter]

(sorry - perhaps a new issue should be created to clarify things)

Original comment by timchar...@gmail.com on 17 Sep 2009 at 7:33

• Changed state: WontFix

[GoogleCodeExporter]

Continued here: http://code.google.com/p/git-osx-installer/issues/detail?id=40

Original comment by timchar...@gmail.com on 17 Sep 2009 at 7:34