"port echo requested" dupes
Hi all, If I issue a “port echo requested” there are always tonnes of dupes in there… and I have to uninstall specific versions. How can I easily purge all old copies of ports so that they don’t show up here? -- Best regards, Samuel Halliday ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
VirtualBox on Mavericks
Has anybody had any joy with virtual box? :-( https://trac.macports.org/ticket/41392 -- Best regards, Samuel Halliday ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
After building the universal gcc48 and compiling for the i386 target, I was
disappointed to see that the library didn't work on an older MacBook I had
lying around :-(
I think I'll abandon support for anything other than 64 bit OS X.
--
Sam
On 25 Aug 2013, at 18:22, Sam Halliday wrote:
> Ok, thanks.
>
> In that case I'll abandon the idea of supporting PPC. It sounds like there
> would be too much tweaking of mac ports above and beyond the SO instructions
> for obtaining a PPC SDK.
>
> Btw, I don't really care about LIPO. I would be happy with four binaries of
> my project.
>
> Kind regards,
> Sam Halliday
>
> --
> Sent from my iPhone
>
> On 25 Aug 2013, at 16:33, Jeremy Huddleston Sequoia
> wrote:
>
>>
>> On Aug 25, 2013, at 4:21, Samuel Halliday wrote:
>>
>>> Thanks all,
>>>
>>> In order to build a ppc gfortran app, I need the Xcode 3 PPC compiler (I
>>> think that's what a lot of these comments have been about). There is a SO
>>> thread about how to do this:
>>>
>>> http://stackoverflow.com/questions/5333490
>>>
>>> But once I have my universal gcc48 (not apple-gcc*), it would appear that
>>> the -arch flags must be passed one at a time. BTW, it seems the default
>>> gcc48 can build 32 bit fortran apps (even though it's a x86_64 build) but
>>> can't link them (hence the need for "gcc48 +universal").
>>>
>>> Before I embark on the insane mission of obtaining xcode3 ppc compilers,
>>> can somebody confirm for me if the "gcc48 +universal" (with universal
>>> including ppc) will be able to compile ppc binaries using "-arch ppc"?
>>
>> No, it won't. +universal in the gcc ports means i386/x86_64 or ppc/ppc64:
>>
>> platform powerpc {
>> configure.universal_archs ppc ppc64
>> }
>> platform i386 {
>> configure.universal_archs i386 x86_64
>> }
>>
>> If you want to fix that, you'll need to bring the Apple gcc driver driver
>> into the gccXX ports and update those ports to build once for ppc and then
>> again for i386 ... see the apple-gcc42 port for how this is done as well as
>> the driver driver source code.
>>
>>> * one could edit
>>> https://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/Portfile to
>>> include the fortran language, but I'd rather not get into customising
>>> portfiles. Besides, I thought apple used LLVM nowadays.
>>
>> You're not going to solve this without either:
>> 1) Moving to Snow Leopard or earlier (so you can have a MacPorts ppc
>> runtime, so you can have a gfortran compiler that produces ppc code)
>> 2) Making a darwin-ppc cross compiler (again, not in MacPorts, but our
>> assembler (cctools) and linker (ld64) should work for you)
>> 3) Adding fortran support to apple-gcc42 (and using the 10.5 or 10.4u SDK)
>> 4) Adding support for generating ppc code with the gccXX ports when running
>> on intel
>>
>> You're going to need to change around Portfiles or do a lot by hand to solve
>> this problem.
>>
>> Alternatively, you could have a SL or Leopard machine do the ppc bits and a
>> ML machine do the i386/x86_64 bits. Then just lipo them all together into
>> the final executable. This is essentially how I build the host support
>> library that is shipped with quartz-wm.
>>
>> --Jeremy
>>
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
Thanks all, In order to build a ppc gfortran app, I need the Xcode 3 PPC compiler (I think that's what a lot of these comments have been about). There is a SO thread about how to do this: http://stackoverflow.com/questions/5333490 But once I have my universal gcc48 (not apple-gcc*), it would appear that the -arch flags must be passed one at a time. BTW, it seems the default gcc48 can build 32 bit fortran apps (even though it's a x86_64 build) but can't link them (hence the need for "gcc48 +universal"). Before I embark on the insane mission of obtaining xcode3 ppc compilers, can somebody confirm for me if the "gcc48 +universal" (with universal including ppc) will be able to compile ppc binaries using "-arch ppc"? * one could edit https://trac.macports.org/browser/trunk/dports/lang/apple-gcc42/Portfile to include the fortran language, but I'd rather not get into customising portfiles. Besides, I thought apple used LLVM nowadays. -- Sam On 25 Aug 2013, at 03:17, Jeremy Huddleston Sequoia wrote: > > On Aug 24, 2013, at 8:00, Ryan Schmidt wrote: > >> >> On Aug 24, 2013, at 07:29, Samuel Halliday wrote: >> >>> I'm using the macports distro of gcc in order to get fortran support. >>> >>> Could somebody please show me how to build universal binaries that work on >>> the four targets: PPC/Intel 32/64? >>> >>> I presume I'll need to get this fixed: >>> >>> $ file /opt/local/lib/libgcc/libgfortran.3.dylib >>> /opt/local/lib/libgcc/libgfortran.3.dylib: Mach-O 64-bit x86_64 dynamically >>> linked shared library >> >> Edit /opt/local/etc/macports/macports.conf and set universal_archs to x86_64 >> i386 ppc64 ppc. Then reinstall libgcc with the universal variant. And maybe >> the gcc port you're using too. If you already had any ports installed using >> the universal variant they'll have to be rebuilt using the new set of >> architectures. Not sure if MacPorts will do that for you automatically or >> not. >> >> I would expect that modern versions of OS X cannot build for PowerPC >> anymore, so you'll need to be running as sufficiently old version of OS X. >> Lion and later are too new. Snow Leopard is probably old enough. Leopard is >> definitely old enough. Tiger is too old to build 64-bit in some cases. > > If you're on SL, you'll need to use the 10.5 SDK if you actually want ppc64 > support. You probably don't want or need ppc64 support (and ppc64 is likely > horrifically broken in MacPorts), so I suggest using Snow Leopard with > universal_archs to x86_64 i386 ppc. > > On Aug 24, 2013, at 15:07, Samuel Halliday wrote: > >> On 24 Aug 2013, at 16:24, Ryan Schmidt wrote: >>>> what command line arguments do I use to get universal builds in my own >>>> projects? >>> >>> add all the -arch flags (e.g. "-arch x86_64 -arch i386 -arch ppc64 -arch >>> ppc") >> >> I'm guessing these instructions are for the apple gcc? Because doing this >> with the gcc / gfortran that I've been installing with macports gives >> >> gcc-mp-4.8: error: unrecognized command line option '-arch' > > Did you build it with the +universal variant? > > Also, I think FSF just aliases -arch to -mXXX. It does not seem to support > multiple -arch options right: > > ~ $ gcc-mp-4.8 -arch x86_64 -c test.c > ~ $ file test.o > test.o: Mach-O 64-bit x86_64 object > > ~ $ gcc-mp-4.8 -arch x86_64 -arch i386 -c test.c > ~ $ file test.o > test.o: Mach-O i386 object > > ~ $ gcc-mp-4.8 -arch i386 -arch x86_64 -c test.c > /var/folders/1b/f1bzh5152y9bvygzl07fn87mgn/T//cc7eJXt5.s:5:bad register > name `%rbp' > /var/folders/1b/f1bzh5152y9bvygzl07fn87mgn/T//cc7eJXt5.s:7:bad register > name `%rsp' > /var/folders/1b/f1bzh5152y9bvygzl07fn87mgn/T//cc7eJXt5.s:10:bad register > name `%rbp' > >> and trying to compile C code on Mountain Lion with the apple gcc gives >> >> llvm-gcc-4.2: error trying to exec >> '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: >> No such file or directory >> llvm-gcc-4.2: error trying to exec >> '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: >> No such file or directory > > Yeah. You need to be on Snow Leopard if you want to compile for ppc. > >> So I'm concluding it is impossible to build universal fortran apps since the >> apple gcc doesn't come with gfortran. > > That depends on what you mean by "u
Re: gcc and universal binaries
On 24 Aug 2013, at 16:24, Ryan Schmidt wrote: >> what command line arguments do I use to get universal builds in my own >> projects? > > add all the -arch flags (e.g. "-arch x86_64 -arch i386 -arch ppc64 -arch > ppc") I'm guessing these instructions are for the apple gcc? Because doing this with the gcc / gfortran that I've been installing with macports gives gcc-mp-4.8: error: unrecognized command line option '-arch' and trying to compile C code on Mountain Lion with the apple gcc gives llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory So I'm concluding it is impossible to build universal fortran apps since the apple gcc doesn't come with gfortran. My only hope would be to build separate binaries for each architecture by: 1. access to old OS X machines (+ macports) 2. cross compile I don't have access to old machines (and it would be incredibly inconvenient in any case), and I'm guessing macports doesn't supply cross compilers for older OS X architectures. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc and universal binaries
Thanks Ryan, Assuming my Mountain Lion can actually build PPC binaries, your solution would appear to want to build universal bins for everything on my system. Can I specify that I just want the gfortran and its deps to be built universally? Also, what command line arguments do I use to get universal builds in my own projects? -- Sam On 24 Aug 2013, at 16:00, Ryan Schmidt wrote: > > On Aug 24, 2013, at 07:29, Samuel Halliday wrote: > >> I'm using the macports distro of gcc in order to get fortran support. >> >> Could somebody please show me how to build universal binaries that work on >> the four targets: PPC/Intel 32/64? >> >> I presume I'll need to get this fixed: >> >> $ file /opt/local/lib/libgcc/libgfortran.3.dylib >> /opt/local/lib/libgcc/libgfortran.3.dylib: Mach-O 64-bit x86_64 dynamically >> linked shared library > > Edit /opt/local/etc/macports/macports.conf and set universal_archs to x86_64 > i386 ppc64 ppc. Then reinstall libgcc with the universal variant. And maybe > the gcc port you're using too. If you already had any ports installed using > the universal variant they'll have to be rebuilt using the new set of > architectures. Not sure if MacPorts will do that for you automatically or not. > > I would expect that modern versions of OS X cannot build for PowerPC anymore, > so you'll need to be running as sufficiently old version of OS X. Lion and > later are too new. Snow Leopard is probably old enough. Leopard is definitely > old enough. Tiger is too old to build 64-bit in some cases. > ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Fortran cross-compilers
Ignore: it "started to work" because I'd removed the fortran language from the build. Doh! -- Sam On 24 Aug 2013, at 14:12, Samuel Halliday wrote: > OK, really weird... this just started to compile! :-) > > Is there any status on the builds for MinGW 32/64 bit? (And please include > fortran) > > -- > Sam > > On 24 Aug 2013, at 13:22, Samuel Halliday wrote: > >> Hi all, >> >> Has anybody had any more thoughts on the cross-compiler situation with the >> Fortran target? >> >> I am able to build the cross compilers using default settings. However, I'm >> unable to build the cross compilers when I add fortran to the list of >> languages due to the following error >> >> sudo port -ns install x86_64-elf-gcc build.jobs=1 >> >> -> >> >> checking whether symbol versioning is supported... configure: error: Link >> tests are not allowed after GCC_NO_EXECUTABLES. >> >> >> Any help to get the fortran cross-compiler building would be greatly >> appreciated. >> >> >> >>> I'm trying to cross-compile a mixture of C and Fortran code for >>> http://github.com/fommil/netlib-java >>> >>> However, it looks like the Linux cross compilers^ do not support fortran >>> and the MinGW Windows cross-compilers are very out of date. I've created >>> tickets to deal with each of these issues: >>> >>> * https://trac.macports.org/ticket/40174 >>> * https://trac.macports.org/ticket/40176 >>> * https://trac.macports.org/ticket/40177 >>> >>> Is there a workaround that allows me to enable fortran for the linux >>> compilers, and does anybody know how to build mingw for both 32 and 64 bit >>> Windows targets? >>> >>> >>> ^ Note that the ARM cross-compiler seems to be built in a very different >>> way than the i386 and x86_64 Linux cross-compilers. >> > ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Fortran cross-compilers
OK, really weird... this just started to compile! :-) Is there any status on the builds for MinGW 32/64 bit? (And please include fortran) -- Sam On 24 Aug 2013, at 13:22, Samuel Halliday wrote: > Hi all, > > Has anybody had any more thoughts on the cross-compiler situation with the > Fortran target? > > I am able to build the cross compilers using default settings. However, I'm > unable to build the cross compilers when I add fortran to the list of > languages due to the following error > > sudo port -ns install x86_64-elf-gcc build.jobs=1 > > -> > > checking whether symbol versioning is supported... configure: error: Link > tests are not allowed after GCC_NO_EXECUTABLES. > > > Any help to get the fortran cross-compiler building would be greatly > appreciated. > > > >> I'm trying to cross-compile a mixture of C and Fortran code for >> http://github.com/fommil/netlib-java >> >> However, it looks like the Linux cross compilers^ do not support fortran and >> the MinGW Windows cross-compilers are very out of date. I've created tickets >> to deal with each of these issues: >> >> * https://trac.macports.org/ticket/40174 >> * https://trac.macports.org/ticket/40176 >> * https://trac.macports.org/ticket/40177 >> >> Is there a workaround that allows me to enable fortran for the linux >> compilers, and does anybody know how to build mingw for both 32 and 64 bit >> Windows targets? >> >> >> ^ Note that the ARM cross-compiler seems to be built in a very different way >> than the i386 and x86_64 Linux cross-compilers. > ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
gcc and universal binaries
Hi all, I'm using the macports distro of gcc in order to get fortran support. Could somebody please show me how to build universal binaries that work on the four targets: PPC/Intel 32/64? I presume I'll need to get this fixed: $ file /opt/local/lib/libgcc/libgfortran.3.dylib /opt/local/lib/libgcc/libgfortran.3.dylib: Mach-O 64-bit x86_64 dynamically linked shared library -- Sam ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Fortran cross-compilers
Hi all, Has anybody had any more thoughts on the cross-compiler situation with the Fortran target? I am able to build the cross compilers using default settings. However, I'm unable to build the cross compilers when I add fortran to the list of languages due to the following error sudo port -ns install x86_64-elf-gcc build.jobs=1 -> checking whether symbol versioning is supported... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. Any help to get the fortran cross-compiler building would be greatly appreciated. > I'm trying to cross-compile a mixture of C and Fortran code for > http://github.com/fommil/netlib-java > > However, it looks like the Linux cross compilers^ do not support fortran and > the MinGW Windows cross-compilers are very out of date. I've created tickets > to deal with each of these issues: > > * https://trac.macports.org/ticket/40174 > * https://trac.macports.org/ticket/40176 > * https://trac.macports.org/ticket/40177 > > Is there a workaround that allows me to enable fortran for the linux > compilers, and does anybody know how to build mingw for both 32 and 64 bit > Windows targets? > > > ^ Note that the ARM cross-compiler seems to be built in a very different way > than the i386 and x86_64 Linux cross-compilers. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why can't I select the Mountain Lion Python 2.7?
Nevermind, fixed this by updating my PATH export PATH=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/:$PATH -- Sam On 9 Aug 2012, at 09:09, Samuel Halliday wrote: > Thanks, > > I figured that might be the case. Apple even seem to be shipping three > different versions of Python this time around - and nobody wants to use them! > > Fundamentally, my problem is that I want to install a python library with > "easy_install" and that is connected to the system Python. Furthermore, I > frequently come up against scripts that start > > #!/usr/bin/python > > instead of, what we all know should be used, > > #!/usr/bin/env python > > Other than changing the scripts, or manually sudo changing /usr/bin/python, > is there a solution to that problem? > > And, can somebody please advise on how to install "easy_install"? > > > PS: I'm increasingly becoming more opposed to mailing lists - they require so > much setup. Is this community also active on > http://stackoverflow.com/questions/tagged/macports ? I find Stack Overflow to > be a much more natural place for these sorts of Q&As, with mailing lists > being reserved for discussions (Google Groups is easily the most superior > choice). > > -- > Sam > > On 9 Aug 2012, at 00:09, Brandon Allbery wrote: > >> On Wed, Aug 8, 2012 at 7:01 PM, Sam Halliday wrote: >> Furthermore, is it possible to install "subversion-python27bindings" against >> the system Python 2.7? >> >> No it is not, no this is not a bug, no it will not be "fixed". This is also >> why there's no mechanism to select the system python (although it wouldn't >> be that difficult to add one, it's usually a bad idea). >> https://trac.macports.org/wiki/FAQ#ownlibs (and most of the questions around >> it) >> >> Homebrew was the most recent attempt by someone to pretend that avoiding the >> system-installed stuff is "just being stupid" or whatever. It, like >> everyone else, has switched to installing and managing its own ecosystem. >> >> -- >> brandon s allbery allber...@gmail.com >> wandering unix systems administrator (available) (412) 475-9364 vm/sms >> > smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
llvm-2.9 and llvm-3.1
Hi all, Is there a reason why llvm-gcc42 depends on llvm-2.9 instead of llvm-3.1 (which is a dependency of ld64 anyway)? If it were possible to upgrade to llvm-3.1 (or downgrade ld64) it would significantly speed up my dependency build tree :-) $ port rdeps llvm-gcc42 The following ports are dependencies of llvm-gcc42 @2.9_2: llvm-2.9 libffi perl5 perl5.12 gdbm gettext libiconv gperf ncurses expat llvm_select gmp mpfr xz ld64 libunwind-headers dyld-headers cctools-headers llvm-3.1 -- Sam smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why can't I select the Mountain Lion Python 2.7?
Thanks, I figured that might be the case. Apple even seem to be shipping three different versions of Python this time around - and nobody wants to use them! Fundamentally, my problem is that I want to install a python library with "easy_install" and that is connected to the system Python. Furthermore, I frequently come up against scripts that start #!/usr/bin/python instead of, what we all know should be used, #!/usr/bin/env python Other than changing the scripts, or manually sudo changing /usr/bin/python, is there a solution to that problem? And, can somebody please advise on how to install "easy_install"? PS: I'm increasingly becoming more opposed to mailing lists - they require so much setup. Is this community also active on http://stackoverflow.com/questions/tagged/macports ? I find Stack Overflow to be a much more natural place for these sorts of Q&As, with mailing lists being reserved for discussions (Google Groups is easily the most superior choice). -- Sam On 9 Aug 2012, at 00:09, Brandon Allbery wrote: > On Wed, Aug 8, 2012 at 7:01 PM, Sam Halliday wrote: > Furthermore, is it possible to install "subversion-python27bindings" against > the system Python 2.7? > > No it is not, no this is not a bug, no it will not be "fixed". This is also > why there's no mechanism to select the system python (although it wouldn't be > that difficult to add one, it's usually a bad idea). > https://trac.macports.org/wiki/FAQ#ownlibs (and most of the questions around > it) > > Homebrew was the most recent attempt by someone to pretend that avoiding the > system-installed stuff is "just being stupid" or whatever. It, like everyone > else, has switched to installing and managing its own ecosystem. > > -- > brandon s allbery allber...@gmail.com > wandering unix systems administrator (available) (412) 475-9364 vm/sms > smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
