Loading ...
Sorry, an error occurred while loading the content.
 

Re: A question on language support

Expand Messages
  • björn
    ... Thanks for the suggestions, but I d rather not have to enable another user etc. Does anybody know how to make ld look in the right place for libraries?
    Message 1 of 27 , Feb 1, 2008
      On 01/02/2008, Bem Jones-Bey <bem@...> wrote:
      >
      > björn wrote:
      > > Compiling a universal binary with all the languages works fine, but
      > > linking fails. I've copied the output from the linking stage. It
      > > seems like some libraries are missing for Intel (I am running PPC
      > > 10.4.11). Any ideas what I can do?
      >
      > It looks like it's picking up your mac ports libs, which aren't
      > universal binaries, so it's failing when trying to link the Intel binary:
      >
      > > /opt/local/lib/libncurses.dylib cputype (18, architecture ppc) does
      > > not match cputype (7) for specified -arch flag: i386 (file not loaded)
      > > /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
      > > /opt/local/lib/libiconv.dylib cputype (18, architecture ppc) does not
      > > match cputype (7) for specified -arch flag: i386 (file not loaded)
      > > /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
      > > /opt/local/lib/perl5/5.8.8/darwin-2level/auto/DynaLoader/DynaLoader.a
      > > archive's cputype (18, architecture ppc) does not match cputype (7)
      > > for specified -arch flag: i386 (can't load from it)
      > > /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
      > > /opt/local/lib/perl5/5.8.8/darwin-2level/CORE/libperl.a archive's
      > > cputype (18, architecture ppc) does not match cputype (7) for
      > > specified -arch flag: i386 (can't load from it)
      >
      > I guess I missed a step in the description of what I did to make the
      > build. The first thing I did was to create a new user on my system that
      > doesn't have all the customized versions of things that my normal user
      > does, to make sure that I was compiling and linking with the system
      > versions of the libraries, so that it would work on all systems. I did
      > add /opt/local/bin to the path so that I could use git, but other than
      > that, I just stuck with a vanilla user.
      >
      > The other thing you could do is make sure that you set the proper
      > variables to make sure that the build finds the system stuff first (like
      > I ended up having to do with Python), but I figured that building with a
      > new, clean user would be the easiest. (And fast user switching makes it
      > really easy. =)

      Thanks for the suggestions, but I'd rather not have to enable another
      user etc. Does anybody know how to make ld look in the right place
      for libraries? That is, can I make it not use the MacPorts libraries
      first? I don't understand why it is looking there to begin with. My
      LDFLAGS is empty and the only environment variable that even points
      anywhere near /opt is PATH. Does PATH have any influence on which
      libraries ld will link to?!? (By the way I tried "export
      LDFLAGS=-F/System/Library/Frameworks" before make, but it made no
      difference...the MacPorts libraries are still being used.)

      /Björn

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • björn
      ... I ve managed to figure out that it is the configure script that points the linker to the MacPorts libraries (in /opt/...). Removing /opt/local/bin and
      Message 2 of 27 , Feb 1, 2008
        On 01/02/2008, björn <bjorn.winckler@...> wrote:
        > On 01/02/2008, Bem Jones-Bey <bem@...> wrote:
        > >
        > > björn wrote:
        > > > Compiling a universal binary with all the languages works fine, but
        > > > linking fails. I've copied the output from the linking stage. It
        > > > seems like some libraries are missing for Intel (I am running PPC
        > > > 10.4.11). Any ideas what I can do?
        > >
        > > It looks like it's picking up your mac ports libs, which aren't
        > > universal binaries, so it's failing when trying to link the Intel binary:
        > >
        > > > /opt/local/lib/libncurses.dylib cputype (18, architecture ppc) does
        > > > not match cputype (7) for specified -arch flag: i386 (file not loaded)
        > > > /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
        > > > /opt/local/lib/libiconv.dylib cputype (18, architecture ppc) does not
        > > > match cputype (7) for specified -arch flag: i386 (file not loaded)
        > > > /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
        > > > /opt/local/lib/perl5/5.8.8/darwin-2level/auto/DynaLoader/DynaLoader.a
        > > > archive's cputype (18, architecture ppc) does not match cputype (7)
        > > > for specified -arch flag: i386 (can't load from it)
        > > > /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
        > > > /opt/local/lib/perl5/5.8.8/darwin-2level/CORE/libperl.a archive's
        > > > cputype (18, architecture ppc) does not match cputype (7) for
        > > > specified -arch flag: i386 (can't load from it)
        > >
        > > I guess I missed a step in the description of what I did to make the
        > > build. The first thing I did was to create a new user on my system that
        > > doesn't have all the customized versions of things that my normal user
        > > does, to make sure that I was compiling and linking with the system
        > > versions of the libraries, so that it would work on all systems. I did
        > > add /opt/local/bin to the path so that I could use git, but other than
        > > that, I just stuck with a vanilla user.
        > >
        > > The other thing you could do is make sure that you set the proper
        > > variables to make sure that the build finds the system stuff first (like
        > > I ended up having to do with Python), but I figured that building with a
        > > new, clean user would be the easiest. (And fast user switching makes it
        > > really easy. =)
        >
        > Thanks for the suggestions, but I'd rather not have to enable another
        > user etc. Does anybody know how to make ld look in the right place
        > for libraries? That is, can I make it not use the MacPorts libraries
        > first? I don't understand why it is looking there to begin with. My
        > LDFLAGS is empty and the only environment variable that even points
        > anywhere near /opt is PATH. Does PATH have any influence on which
        > libraries ld will link to?!? (By the way I tried "export
        > LDFLAGS=-F/System/Library/Frameworks" before make, but it made no
        > difference...the MacPorts libraries are still being used.)
        >
        > /Björn
        >

        I've managed to figure out that it is the configure script that points
        the linker to the MacPorts libraries (in /opt/...). Removing
        '/opt/local/bin' and then running configure takes care of that
        problem. But, now I get other (similar) warnings...any ideas on what
        to do? (This time I did ./configure --enable-gui=macvim
        --with-mac-arch=both --enable-perlinterp.)

        Here are the relevant errors from linking:

        env LD_RUN_PATH=/System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE
        gcc -F/System/Library/Frameworks -L/System/Library/Frameworks
        -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -o Vim
        objects/buffer.o objects/charset.o objects/diff.o objects/digraph.o
        objects/edit.o objects/eval.o objects/ex_cmds.o objects/ex_cmds2.o
        objects/ex_docmd.o objects/ex_eval.o objects/ex_getln.o
        objects/fileio.o objects/fold.o objects/getchar.o objects/hardcopy.o
        objects/hashtab.o objects/if_cscope.o objects/if_xcmdsrv.o
        objects/main.o objects/mark.o objects/memfile.o objects/memline.o
        objects/menu.o objects/message.o objects/misc1.o objects/misc2.o
        objects/move.o objects/mbyte.o objects/normal.o objects/ops.o
        objects/option.o objects/os_unix.o objects/pathdef.o
        objects/popupmnu.o objects/quickfix.o objects/regexp.o
        objects/screen.o objects/search.o objects/spell.o objects/syntax.o
        objects/tag.o objects/term.o objects/ui.o objects/undo.o
        objects/window.o objects/gui.o objects/pty.o objects/gui_macvim.o
        objects/MMBackend.o objects/MacVim.o objects/if_perl.o
        objects/if_perlsfio.o objects/os_macosx.o objects/os_mac_conv.o
        objects/netbeans.o objects/version.o -framework Cocoa -framework
        Carbon -lncurses -liconv -L/usr/local/lib
        /System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a
        -L/System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE -lperl
        -ldl -lm -lc
        /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning -L: directory
        name (/usr/local/lib) does not exist
        /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning -L: directory
        name (/usr/local/lib) does not exist
        /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: for architecture i386
        /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
        /System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a
        archive's cputype (18, architecture ppc) does not match cputype (7)
        for specified -arch flag: i386 (can't load from it)
        /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
        /System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE/libperl.dylib
        cputype (18, architecture ppc) does not match cputype (7) for
        specified -arch flag: i386 (file not loaded)
        /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:
        _Perl_Gthr_key_ptr

        ...lots of other missing _Perl* symbols follow...

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_mac" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • björn
        ... That should have said: Removing /opt/local/bin from $PATH and then running configure takes care of the problem. Sorry, Björn
        Message 3 of 27 , Feb 1, 2008
          On 01/02/2008, björn <bjorn.winckler@...> wrote:
          > Removing
          > '/opt/local/bin' and then running configure takes care of that
          > problem.

          That should have said: "Removing '/opt/local/bin' from $PATH and then
          running configure takes care of the problem.

          Sorry,
          Björn

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_mac" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Bem Jones-Bey
          ... I just managed to get a successful build with my normal user account. I used the following shell script to do it (invoked from the root directory of my git
          Message 4 of 27 , Feb 2, 2008
            On Feb 1, 2008, at 11:35, björn wrote:

            > Thanks for the suggestions, but I'd rather not have to enable another
            > user etc. Does anybody know how to make ld look in the right place
            > for libraries? That is, can I make it not use the MacPorts libraries
            > first? I don't understand why it is looking there to begin with. My
            > LDFLAGS is empty and the only environment variable that even points
            > anywhere near /opt is PATH. Does PATH have any influence on which
            > libraries ld will link to?!? (By the way I tried "export
            > LDFLAGS=-F/System/Library/Frameworks" before make, but it made no
            > difference...the MacPorts libraries are still being used.)

            I just managed to get a successful build with my normal user account.
            I used the following shell script to do it (invoked from the root
            directory of my git checkout). Björn, if this script doesn't work for
            you, can you send me the output of 'set' in your environment? There
            may be some other lib path hiding somewhere that's causing problems.

            #!/bin/sh

            export DYLD_LIBRARY_PATH=
            export LIBRARY_PATH=
            export CPATH=
            export PATH=/bin:/usr/bin:$PATH
            export LDFLAGS=-F/System/Library/Frameworks
            cd src && \
            ./configure --enable-gui=macvim --with-features=huge --with-mac-
            arch=both \
            --enable-perlinterp --enable-pythoninterp --enable-rubyinterp \
            --enable-tclinterp \
            --with-python-config-dir=/System/Library/Frameworks/
            Python.framework/Versions/2.3/lib/python2.3/config \
            && \
            make && \
            cd MacVim &&\
            xcodebuild

            -- Bem Jones-Bey (bem@...)



            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_mac" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • björn
            ... Bem, Thanks for your help, but unfortunately I still get the same error when linking: /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: for architecture i386
            Message 5 of 27 , Feb 3, 2008
              On 02/02/2008, Bem Jones-Bey <bem@...> wrote:
              >
              > On Feb 1, 2008, at 11:35, björn wrote:
              >
              > > Thanks for the suggestions, but I'd rather not have to enable another
              > > user etc. Does anybody know how to make ld look in the right place
              > > for libraries? That is, can I make it not use the MacPorts libraries
              > > first? I don't understand why it is looking there to begin with. My
              > > LDFLAGS is empty and the only environment variable that even points
              > > anywhere near /opt is PATH. Does PATH have any influence on which
              > > libraries ld will link to?!? (By the way I tried "export
              > > LDFLAGS=-F/System/Library/Frameworks" before make, but it made no
              > > difference...the MacPorts libraries are still being used.)
              >
              > I just managed to get a successful build with my normal user account.
              > I used the following shell script to do it (invoked from the root
              > directory of my git checkout). Björn, if this script doesn't work for
              > you, can you send me the output of 'set' in your environment? There
              > may be some other lib path hiding somewhere that's causing problems.
              >
              > #!/bin/sh
              >
              > export DYLD_LIBRARY_PATH=
              > export LIBRARY_PATH=
              > export CPATH=
              > export PATH=/bin:/usr/bin:$PATH
              > export LDFLAGS=-F/System/Library/Frameworks
              > cd src && \
              > ./configure --enable-gui=macvim --with-features=huge --with-mac-
              > arch=both \
              > --enable-perlinterp --enable-pythoninterp --enable-rubyinterp \
              > --enable-tclinterp \
              > --with-python-config-dir=/System/Library/Frameworks/
              > Python.framework/Versions/2.3/lib/python2.3/config \
              > && \
              > make && \
              > cd MacVim &&\
              > xcodebuild

              Bem,

              Thanks for your help, but unfortunately I still get the same error when linking:

              /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: for architecture i386
              /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
              /System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a
              archive's cputype (18, architecture ppc) does not match cputype (7)
              for specified -arch flag: i386 (can't load from it)
              /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: warning
              /System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE/libperl.dylib
              cputype (18, architecture ppc) does not match cputype (7) for
              specified -arch flag: i386 (file not loaded)
              /usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: Undefined symbols:
              _Perl_Gthr_key_ptr
              ...etc...

              I very much doubt it has anything to do with my environment
              variables...it looks more like I don't have a universal version of the
              Perl libraries for some reason. In any case, my output from set is:

              BASH=/bin/bash
              BASH_VERSINFO=([0]="2" [1]="05b" [2]="0" [3]="1" [4]="release"
              [5]="powerpc-apple-darwin8.0")
              BASH_VERSION='2.05b.0(1)-release'
              CFZombieLevel=3
              COLUMNS=80
              DIRSTACK=()
              DISPLAY=:0.0
              EUID=501
              GROUPS=()
              HISTFILESIZE=500
              HISTSIZE=500
              HOSTTYPE=powerpc
              IFS=$' \t\n'
              LINES=24
              MACHTYPE=powerpc-apple-darwin8.0
              MAILCHECK=60
              MANPATH=/usr/local/man
              NSZombieEnabled=YES
              OPTERR=1
              OPTIND=1
              OSTYPE=darwin8.0
              PATH=/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin
              PERL5LIB=/usr/local/lib/svn-perl
              PIPESTATUS=([0]="127")
              PPID=302
              PS1='\h:\w \u\$ '
              PS2='> '
              PS4='+ '
              SECURITYSESSIONID=4036f0
              SHELL=/bin/bash
              SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
              SHLVL=1
              TERM=xterm-color
              TERM_PROGRAM=Apple_Terminal
              TERM_PROGRAM_VERSION=133
              UID=501
              _=symbols:
              __CF_USER_TEXT_ENCODING=0x1F5:0:0


              /Björn

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_mac" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • björn
              ... Yes, mine only contains the ppc binary. I though maybe there d be a universal version somewhere under /Developer but I couldn t find anything at all
              Message 6 of 27 , Feb 3, 2008
                On 03/02/2008, Ben Schmidt <mail_ben_schmidt@...> wrote:
                >
                > > I very much doubt it has anything to do with my environment
                > > variables...it looks more like I don't have a universal version of the
                > > Perl libraries for some reason. In any case, my output from set is:
                >
                > I agree with that deduction. I am on Intel 10.4.9 and get
                >
                > $ lipo -info
                > /System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a
                > Architectures in the fat file:
                > /System/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DynaLoader/DynaLoader.a
                > are: i386 ppc
                >
                > I presume if you do the same, the i386 will be missing.

                Yes, mine only contains the ppc binary. I though maybe there'd be a
                universal version somewhere under /Developer but I couldn't find
                anything at all relating to Perl there.


                > Now, one wonders why. I presume you've never run any script that thins out
                > binaries to save disk space or anything like that. Maybe universal binaries are an
                > option to install with the developer tools? Maybe check that CD/DVD installer
                > doesn't have an option to install a universal version, or a universal SDK (which
                > just might include universal Perl unexpectedly...). It must be on your original
                > install disks somewhere as a universal binary, as it is evidently installed as
                > universal on i386 systems, so it should just be a case of digging it up.

                Nope, I just installed Xcode yesterday (I did a reinstall of Tiger)
                from the latest version of Xcode (downloaded from the Apple dev site).
                The only options I deselected were Java development and the docs, I
                installed everything else.

                By the way, I did not install MacPorts yet (nor Fink for that matter)
                to see if I could build Vim with a "clean" install of OS X and the dev
                tools.

                > Maybe this page would help
                >
                > http://search.cpan.org/~nwclark/perl-5.8.8/README.macosx
                >
                > or the page referenced from there
                >
                > http://www.charlessoft.com/

                That page seems to be all about building your own Perl, which maybe I
                will be forced to do. :-(

                >
                > Hopefully this same problem won't exist for all your script interpreters...perhaps
                > do a ./configure for Vim with perlinterp, pythoninterp, rubyinterp, etc. all
                > individually and see if they are all going to break or not...

                I checked today...Python and Tcl support works, Ruby complains about
                missing header files (I have the Ruby libs it seems, not the header
                files though), and Perl is obviously missing universal versions of the
                libs.

                So I guess I have to find the relevant Ruby headers (and hope the libs
                are universal), and build my own universal version of Perl. Well, at
                least I know what the problem is now...I just wished there was an
                easier solution than building my own version of Perl (and possibly
                Ruby). :'(


                Thanks for all the help,
                Björn

                --~--~---------~--~----~------------~-------~--~----~
                You received this message from the "vim_mac" maillist.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Bem Jones-Bey
                ... Yeah, you re right. I missed that in the output in your earlier mail. Hopefully Ben s suggestions help. I just checked with a friend of mine that has a PPC
                Message 7 of 27 , Feb 3, 2008
                  On Feb 3, 2008, at 4:17, björn wrote:

                  > I very much doubt it has anything to do with my environment
                  > variables...it looks more like I don't have a universal version of the
                  > Perl libraries for some reason. In any case, my output from set is:

                  Yeah, you're right. I missed that in the output in your earlier mail.
                  Hopefully Ben's suggestions help. I just checked with a friend of
                  mine that has a PPC mac, and has the devtools installed, but his Perl
                  Dynaloader.a is also a ppc bin. And, his system versions of the
                  python lib (/System/Library/Frameworks/Python.framework/Versions/2.3/
                  Python) and ruby lib (/usr/lib/libruby.1.dylib) are also ppc only.

                  The reason that you can compile in Python into a universal bin and
                  not anything else is that Python is a framework, and is thus shipped
                  with the 10.4u SDK, so you link against (/Developer/SDKs/
                  MacOSX10.4u.sdk/System/Library/Frameworks/Python.framework/Versions/
                  2.3/Python).

                  One thing that my friend mentioned, which makes sense, is that when
                  the PPC version of 10.4 came out, Apple hadn't shipped the Intel Macs
                  yet, so nothing came as a universal bin. So that's probably why your
                  PPC mac doesn't have universal libs for the system libs.

                  -- Bem Jones-Bey (bem@...)



                  --~--~---------~--~----~------------~-------~--~----~
                  You received this message from the "vim_mac" maillist.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • björn
                  ... I see, I thought it a bit strange that Python would work and not Perl... ... Yes, that is true. But annoying. I compiled Perl 5.8.8 manually as a
                  Message 8 of 27 , Feb 3, 2008
                    On 03/02/2008, Bem Jones-Bey <bem@...> wrote:
                    >
                    > On Feb 3, 2008, at 4:17, björn wrote:
                    >
                    > > I very much doubt it has anything to do with my environment
                    > > variables...it looks more like I don't have a universal version of the
                    > > Perl libraries for some reason. In any case, my output from set is:
                    >
                    > Yeah, you're right. I missed that in the output in your earlier mail.
                    > Hopefully Ben's suggestions help. I just checked with a friend of
                    > mine that has a PPC mac, and has the devtools installed, but his Perl
                    > Dynaloader.a is also a ppc bin. And, his system versions of the
                    > python lib (/System/Library/Frameworks/Python.framework/Versions/2.3/
                    > Python) and ruby lib (/usr/lib/libruby.1.dylib) are also ppc only.
                    >
                    > The reason that you can compile in Python into a universal bin and
                    > not anything else is that Python is a framework, and is thus shipped
                    > with the 10.4u SDK, so you link against (/Developer/SDKs/
                    > MacOSX10.4u.sdk/System/Library/Frameworks/Python.framework/Versions/
                    > 2.3/Python).

                    I see, I thought it a bit strange that Python would work and not Perl...

                    >
                    > One thing that my friend mentioned, which makes sense, is that when
                    > the PPC version of 10.4 came out, Apple hadn't shipped the Intel Macs
                    > yet, so nothing came as a universal bin. So that's probably why your
                    > PPC mac doesn't have universal libs for the system libs.

                    Yes, that is true. But annoying.

                    I compiled Perl 5.8.8 manually as a universal binary, but
                    unfortunately the configure script doesn't accept it. The following
                    is the output from ./configure --enable-gui=macvim
                    --with-mac-arch=both --enable-perlinterp:

                    checking --enable-perlinterp argument... yes
                    checking for perl... /usr/local/bin/perl
                    checking Perl version... OK
                    checking if compile and link flags for Perl are sane... no: PERL DISABLED

                    So it finds Perl (in /usr/local where I put it), but then says the
                    compile and link flags aren't sane...what is that supposed to mean?
                    Any ideas? (I tried looking at the configure script, but I do not
                    understand it at all.)

                    Anyway, I am about to give up on this...it is taking too much time.
                    If I ever can afford an upgrade to an Intel Mac I will start building
                    the snapshots with more languages supported, but for now I think I'll
                    just stick with cscope/python/tcl since those are the only ones that
                    work for me.

                    /Björn

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_mac" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Ben Schmidt
                    ... Why doesn t one of us with an Intel machine just tar/zip up our universal /System/Library/Perl along with /usr/bin/perl* and send it to you? You can backup
                    Message 9 of 27 , Feb 3, 2008
                      > Anyway, I am about to give up on this...it is taking too much time.
                      > If I ever can afford an upgrade to an Intel Mac I will start building
                      > the snapshots with more languages supported, but for now I think I'll
                      > just stick with cscope/python/tcl since those are the only ones that
                      > work for me.

                      Why doesn't one of us with an Intel machine just tar/zip up our universal
                      /System/Library/Perl along with /usr/bin/perl* and send it to you? You can backup
                      what you currently have, just in case, then drop the new stuff in, and it'd
                      probably 'just work'. It's not like it's Apple proprietory or anything.

                      And I think the same would work for ruby, if we give you /usr/bin/ruby plus
                      /usr/lib/libruby* plus /usr/lib/ruby. It seems to include headers, and
                      deinstalling my MacPorts ruby MacVim still builds OK.

                      So...I've tar.bz2'ed all the above it and it weighs in at 14.7 MB. Interested in
                      giving it a try, Bjorn?

                      Ben.



                      Send instant messages to your online friends http://au.messenger.yahoo.com


                      --~--~---------~--~----~------------~-------~--~----~
                      You received this message from the "vim_mac" maillist.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • björn
                      ... Thanks Ben. I m not sure it will work to send me such a large attachement in an email...but unless you another way of making it available to me I guess we
                      Message 10 of 27 , Feb 4, 2008
                        On 04/02/2008, Ben Schmidt <mail_ben_schmidt@...> wrote:
                        >
                        > > Anyway, I am about to give up on this...it is taking too much time.
                        > > If I ever can afford an upgrade to an Intel Mac I will start building
                        > > the snapshots with more languages supported, but for now I think I'll
                        > > just stick with cscope/python/tcl since those are the only ones that
                        > > work for me.
                        >
                        > Why doesn't one of us with an Intel machine just tar/zip up our universal
                        > /System/Library/Perl along with /usr/bin/perl* and send it to you? You can backup
                        > what you currently have, just in case, then drop the new stuff in, and it'd
                        > probably 'just work'. It's not like it's Apple proprietory or anything.
                        >
                        > And I think the same would work for ruby, if we give you /usr/bin/ruby plus
                        > /usr/lib/libruby* plus /usr/lib/ruby. It seems to include headers, and
                        > deinstalling my MacPorts ruby MacVim still builds OK.
                        >
                        > So...I've tar.bz2'ed all the above it and it weighs in at 14.7 MB. Interested in
                        > giving it a try, Bjorn?

                        Thanks Ben. I'm not sure it will work to send me such a large
                        attachement in an email...but unless you another way of making it
                        available to me I guess we could try?

                        /Björn

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_mac" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      • Matt Tolton
                        ... Gmail supports up to 20 MB attachments, as far as I know. --~--~---------~--~----~------------~-------~--~----~ You received this message from the
                        Message 11 of 27 , Feb 4, 2008
                          > Thanks Ben. I'm not sure it will work to send me such a large
                          > attachement in an email...but unless you another way of making it
                          > available to me I guess we could try?

                          Gmail supports up to 20 MB attachments, as far as I know.

                          --~--~---------~--~----~------------~-------~--~----~
                          You received this message from the "vim_mac" maillist.
                          For more information, visit http://www.vim.org/maillist.php
                          -~----------~----~----~----~------~----~------~--~---
                        • Ben Schmidt
                          ... Yeah. My outgoing email would choke on it, too, Bjorn. I m putting it at http://www.northbalwynbaptist.org/personal/perl+ruby-universal.tar.bz2 I have slow
                          Message 12 of 27 , Feb 4, 2008
                            >> So...I've tar.bz2'ed all the above it and it weighs in at 14.7 MB. Interested in
                            >> giving it a try, Bjorn?
                            >
                            > Thanks Ben. I'm not sure it will work to send me such a large
                            > attachement in an email...but unless you another way of making it
                            > available to me I guess we could try?

                            Yeah. My outgoing email would choke on it, too, Bjorn. I'm putting it at

                            http://www.northbalwynbaptist.org/personal/perl+ruby-universal.tar.bz2

                            I have slow uploads from here, too, so it'll chug along for a while but should be
                            well and truly fully uploaded by Feb 5 1:00 AM GMT. Its md5 checksum should be

                            schmidt:personal $ openssl md5 perl+ruby-universal.tar.bz2
                            MD5(perl+ruby-universal.tar.bz2)= 1a9d970941db9d461bb2672f0caed07a

                            Off to have breakfast and go to work!

                            Cheers,

                            Ben.



                            Send instant messages to your online friends http://au.messenger.yahoo.com


                            --~--~---------~--~----~------------~-------~--~----~
                            You received this message from the "vim_mac" maillist.
                            For more information, visit http://www.vim.org/maillist.php
                            -~----------~----~----~----~------~----~------~--~---
                          • Ben Schmidt
                            ... Hmmph. Something in that file name must trigger some access rule on the server...moved to http://www.northbalwynbaptist.org/personal/pl+rb-univ.tar.bz2
                            Message 13 of 27 , Feb 4, 2008
                              > http://www.northbalwynbaptist.org/personal/perl+ruby-universal.tar.bz2

                              Hmmph. Something in that file name must trigger some access rule on the
                              server...moved to

                              http://www.northbalwynbaptist.org/personal/pl+rb-univ.tar.bz2

                              Checksum the same as previously posted, of course.

                              Ben.



                              Send instant messages to your online friends http://au.messenger.yahoo.com


                              --~--~---------~--~----~------------~-------~--~----~
                              You received this message from the "vim_mac" maillist.
                              For more information, visit http://www.vim.org/maillist.php
                              -~----------~----~----~----~------~----~------~--~---
                            • björn
                              ... I just got it...checksum matches and all...so you can safely remove the download now. I will let you know how/if it works. Thanks, Björn
                              Message 14 of 27 , Feb 5, 2008
                                On 05/02/2008, Ben Schmidt <mail_ben_schmidt@...> wrote:
                                >
                                > > http://www.northbalwynbaptist.org/personal/perl+ruby-universal.tar.bz2
                                >
                                > Hmmph. Something in that file name must trigger some access rule on the
                                > server...moved to
                                >
                                > http://www.northbalwynbaptist.org/personal/pl+rb-univ.tar.bz2
                                >
                                > Checksum the same as previously posted, of course.

                                I just got it...checksum matches and all...so you can safely remove
                                the download now. I will let you know how/if it works.

                                Thanks,
                                Björn

                                --~--~---------~--~----~------------~-------~--~----~
                                You received this message from the "vim_mac" maillist.
                                For more information, visit http://www.vim.org/maillist.php
                                -~----------~----~----~----~------~----~------~--~---
                              Your message has been successfully submitted and would be delivered to recipients shortly.