Re: Which compiler was used for pre-built libiodbc?

> On Jul 26, 2016, at 23:04, Ryan Schmidt wrote: > > > On Jul 26, 2016, at 7:23 PM, Richard L. Hamilton wrote: > >> Which compiler was used for pre-built libiodbc? It failed on both my El >> Capitan boxes, until the pre-built was available, and that installe

Re: Which compiler was used for pre-built libiodbc?

On Jul 26, 2016, at 7:23 PM, Richard L. Hamilton wrote: > Which compiler was used for pre-built libiodbc? It failed on both my El > Capitan boxes, until the pre-built was available, and that installed of > course. It's also failing on the Snow Leopard, and I doubt there's

Re: Which compiler was used for pre-built libiodbc?

> On Jul 26, 2016, at 7:23 PM, Richard L. Hamilton wrote: > > Which compiler was used for pre-built libiodbc? It failed on both my El > Capitan boxes, until the pre-built was available, and that installed of > course. It's also failing on the Snow Leopard, and I doubt th

kerberos5 compiler error on Snow Leopard

fo:build utf8_conv.c:457: internal compiler error: Abort trap :info:build Please submit a full bug report, :info:build with preprocessed source if appropriate. :info:build See http://developer.apple.com/bugreporter> for instructions. :info:build fatal error: lipo: can't open input file: /opt/local/va

Re: How to reliable detect a MacPorts-ported compiler?

the problem I am trying to solve. > > the confusion here is that it seems to be that you would be better served in > detecting FSF GCC (generally) rather than a macports build of FSF GCC > (specifically). I would have used something like this: #if defined(__APPLE__) && \ (d

Re: How to reliable detect a MacPorts-ported compiler?

On Wed, Sep 9, 2015 at 10:02 AM, Daniel J. Luke wrote: >> On Sep 9, 2015, at 12:35 AM, Jeffrey Walton wrote: >> >>> Again, I have to ask why you want to do this. >> >> My apologies, I was not trying to be rude. I specifically avoided >> addressing any of these questions because of the bikesheddin

Re: How to reliable detect a MacPorts-ported compiler?

> On Sep 9, 2015, at 12:35 AM, Jeffrey Walton wrote: > >> Again, I have to ask why you want to do this. > > My apologies, I was not trying to be rude. I specifically avoided > addressing any of these questions because of the bikeshedding > involved. > >> What problem are you seeing with FSF GCC

Re: How to reliable detect a MacPorts-ported compiler?

> Again, I have to ask why you want to do this. My apologies, I was not trying to be rude. I specifically avoided addressing any of these questions because of the bikeshedding involved. > What problem are you seeing with FSF GCC compiled with MacPorts that you do > not see with FSF GCC compiled

Re: How to reliable detect a MacPorts-ported compiler?

Does MacPorts offer anything in the preprocessor we can key on? We are not deliberately changing anything about the compiler (aside from fixing bugs, and aside from adding our string to the version string, for which they provide a configure flag so they clearly intend for that to happen), so no, I

Re: How to reliable detect a MacPorts-ported compiler?

>> Thanks again Ryan. >> >> Is there a #define so we can detect it in the source code? > > Not that I'm aware of. OK, thanks. That's kind of a problem. The problem occurs when a user includes the library. We (the library) can get into a good state at build time by shell'ing out and detecting MacP

Re: How to reliable detect a MacPorts-ported compiler?

On Sep 8, 2015, at 7:57 PM, Jeffrey Walton wrote: >>> What strings or bits is MacPorts providing? >> >> If you want to know if gcc is FSF GCC compiled by MacPOrts, you could >> inspect the version string: >> >> $ gcc-mp-6 --version >> gcc-mp-6 (MacPorts gcc6 6-20150830_0+universal) 6.0.0 20150

Re: How to reliable detect a MacPorts-ported compiler?

>> What strings or bits is MacPorts providing? > > If you want to know if gcc is FSF GCC compiled by MacPOrts, you could inspect > the version string: > > $ gcc-mp-6 --version > gcc-mp-6 (MacPorts gcc6 6-20150830_0+universal) 6.0.0 20150830 (experimental) > Copyright (C) 2015 Free Software Foundat

Re: How to reliable detect a MacPorts-ported compiler?

>>> Well, that's clang, not gcc. >> >> Right, but the APPLE_CC tells me its an Apple port. > > Right: it tells you it is an Apple fork of that compiler. > > MacPorts does not fork things. We package the original thing. For our purposes (iden

Re: How to reliable detect a MacPorts-ported compiler?

ERSION__ "4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)" >>> #define __apple_build_version__ 5030040 >> >> Well, that's clang, not gcc. > > Right, but the APPLE_CC tells me its an Apple port. Right: it tells you

Re: How to reliable detect a MacPorts-ported compiler?

On Sun, Sep 6, 2015 at 8:46 PM, Jeffrey Walton wrote: > We have some users reporting issues under MacPort-ported compilers > (specifically, Issue 37664, https://trac.macports.org/ticket/37664 > > ). > Did you test the system linker as mentioned in the last comment on that ticket, which made it c

Re: How to reliable detect a MacPorts-ported compiler?

>> For Apple, we can detect Apple ported gear with: >> >> $ clang++ -dM -E - < /dev/null | grep -i apple >> #define __APPLE_CC__ 6000 >> #define __APPLE__ 1 >> #define __VERSION__ "4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)" >> #define __apple_build_version__ 5030040 > > Well, that's cla

Re: How to reliable detect a MacPorts-ported compiler?

c.macports.org/ticket/37664). >>> >>> How do I reliably detect a MacPorts-ported compiler? >> >> Wouldn't it be more correct to detect gcc on OS X as apparently this >> feature is not supported no matter where the compiler comes from? >> > Thanks.

Re: How to reliable detect a MacPorts-ported compiler?

On Mon, Sep 7, 2015 at 5:04 PM, Rainer Müller wrote: > On 2015-09-07 02:46, Jeffrey Walton wrote: >> We have some users reporting issues under MacPort-ported compilers >> (specifically, Issue 37664, https://trac.macports.org/ticket/37664). >> >> How do I reliably detect

Re: How to reliable detect a MacPorts-ported compiler?

On 2015-09-07 02:46, Jeffrey Walton wrote: > We have some users reporting issues under MacPort-ported compilers > (specifically, Issue 37664, https://trac.macports.org/ticket/37664). > > How do I reliably detect a MacPorts-ported compiler? Wouldn't it be more correct to dete

How to reliable detect a MacPorts-ported compiler?

Hi Everyone, We have some users reporting issues under MacPort-ported compilers (specifically, Issue 37664, https://trac.macports.org/ticket/37664). How do I reliably detect a MacPorts-ported compiler? Thanks in advance. ___ macports-users mailing

Re: [MacPorts] #45954: libgcc @4.9.2_0: stage 1 configure fails with "cc1: internal compiler error: in init_reg_sets, at reginfo.c:178" (was: libgcc build failure under 10.5.9)

Keeping it on the list. On Nov 21, 2014, at 5:46 PM, Eneko Gotzon wrote: > On Fri, Nov 21, 2014 at 9:06 PM, Lawrence Velázquez > wrote: > >> Brandon pointed out in IRC that this is not a real configuration… > > Snow Leopard cannot run on a PPC machine; the last supported OS on PPC was > Leo

Re: [MacPorts] #45954: libgcc @4.9.2_0: stage 1 configure fails with "cc1: internal compiler error: in init_reg_sets, at reginfo.c:178" (was: libgcc build failure under 10.5.9)

On Nov 21, 2014, at 2:53 PM, Lawrence Velázquez wrote: > Is anyone on Snow Leopard PPC encountering this issue? Brandon pointed out in IRC that this is not a real configuration, which outs me as never having owned a PowerPC Mac. So the actual question is: Is anyone who compiles libgcc for Powe

Re: [MacPorts] #45954: libgcc @4.9.2_0: stage 1 configure fails with "cc1: internal compiler error: in init_reg_sets, at reginfo.c:178" (was: libgcc build failure under 10.5.9)

On Nov 21, 2014, at 2:25 PM, MacPorts wrote: > #45954: libgcc @4.9.2_0: stage 1 configure fails with "cc1: internal compiler > error: in init_reg_sets, at reginfo.c:178" > -+- > Reporter: mschamschula@… | Owner:

Re: fortran compiler for f2py

Clemens Lang writes: > Hi, > >> Run "port select" to read the help message about the select mechanism. I >> would think it's also documented elsewhere in more detail, though not, >> apparently, via "port help select". > > It is, in 2.3.1, but not in trunk. See > > http://trac.macports.org/brow

Re: fortran compiler for f2py

On Aug 13, 2014, at 4:12 PM, Clemens Lang wrote: > > Hi, > >> Run "port select" to read the help message about the select mechanism. I >> would think it's also documented elsewhere in more detail, though not, >> apparently, via "port help select". > > It is, in 2.3.1, but not in trunk. Oh ok g

Re: fortran compiler for f2py

Hi, > Run "port select" to read the help message about the select mechanism. I > would think it's also documented elsewhere in more detail, though not, > apparently, via "port help select". It is, in 2.3.1, but not in trunk. See http://trac.macports.org/browser/branches/release_2_3/base/src/po

Re: fortran compiler for f2py

On Aug 13, 2014, at 12:44 PM, Mark Brethen wrote: > > It sounds like I need to run gcc_select to link the standard executables. How > is this used? Run "port select" to read the help message about the select mechanism. I would think it's also documented elsewhere in more detail, though not, ap

fortran compiler for f2py

I'm trying to compile a fortran file in python using f2py however its not finding the gcc 4.8 fortran compiler 'gfortran-mp-4.8' in /opt/local/bin. Here's the ipython console output: build_src: building npy-pkg config files running build_ext customize UnixCCompiler cus

Re: building a (gcc) cross-compiler

On Apr 06, 2014, at 23:48, Eric Gallager wrote: > You can try looking at the cross-gcc PortGroup: > https://trac.macports.org/browser/trunk/dports/_resources/port1.0/group/crossgcc-1.0.tcl Thanks - but could you give me some pointers what to do with this information? > As far as your specific

Re: building a (gcc) cross-compiler

available in trunk, but it looks like that will not be happening...) On Sun, Apr 6, 2014 at 1:19 PM, "René J.V. Bertin" wrote: > Hello, > > I'd be very interested in having a cross-compiler for x86_64-elf-linux-gnu > on OS X. Since there's no such cross-com

building a (gcc) cross-compiler

Hello, I'd be very interested in having a cross-compiler for x86_64-elf-linux-gnu on OS X. Since there's no such cross-compiler in MacPorts, I'm trying to build one myself, following these instructions: http://wiki.osdev.org/GCC_Cross-Compiler#The_Build This gave me a working b

Re: compiler

after. No; ports are supposed to ignore the compiler (or other utilities) you’ve selected. “port select” is only for your own benefit, outside of MacPorts. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/ma

Re: compiler

I was looking at the ticket for Boost 1.54, #39809, since Boost 1.55 also fails to compile on 10.5.8. Jeremy suggests that ppc users, comment 24, should use that selection to get Boost to compile. Thought that I might give it a try. Could I install gcc48 and use port select to select gcc48 with the

Re: compiler

On Dec 6, 2013, at 09:33, M. Daniel Becque wrote: > Is port gcc48 the correct port to install if I want to use > configure.compiler=macports-gcc-4.8 on the command line? Yes, but we don’t support overriding configure.compiler at the command line. (We may use it as a troubleshooting step from t

compiler

Is port gcc48 the correct port to install if I want to use configure.compiler=macports-gcc-4.8 on the command line? Dan ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users

Re: Error: Unable to open port: can't set "compiler.blacklist": couldn't determine build number of compiler "gcc-4.2"

bin/gcc should be a small stub program that calls the real compiler. If that’s not what you have, then you should restore it from your backups or perhaps reinstalling the Xcode command line tools would put it back the way it should be. ___ macports-us

Re: Error: Unable to open port: can't set "compiler.blacklist": couldn't determine build number of compiler "gcc-4.2"

ct gcc” to select any gcc you want. However if you’re saying that /usr/bin/gcc was a symlink to MacPorts gcc 4.7, then that’s a problem. On Mavericks /usr/bin/gcc should be a small stub program that calls the real compiler. If that’s not what you have, then you should restore it from your back

Re: Error: Unable to open port: can't set "compiler.blacklist": couldn't determine build number of compiler "gcc-4.2"

Thanks, that fixed the issue. It was symlinked to gcc, which was symlinked to gcc 4.7.Gimp is now building (well fetching archives atm). Thanks again. Michael. -- On 4/11/2013 9:49 am, Ryan Schmidt wrote: On Nov 3, 2013, at 19:47, Brickle Macho wrote: Not sure how it got there. I a

Re: Error: Unable to open port: can't set "compiler.blacklist": couldn't determine build number of compiler "gcc-4.2"

On Nov 3, 2013, at 19:47, Brickle Macho wrote: > Not sure how it got there. I am at the limit of my Mac Ports knowledge. Do > I need to uninstall something? Here is the output from the command: > > > $gcc-4.2 -v > Using built-in specs. > COLLECT_GCC=gcc-4.2 > COLLECT_LTO_WRAPPER=/op

Re: Error: Unable to open port: can't set "compiler.blacklist": couldn't determine build number of compiler "gcc-4.2"

/2013 9:31 am, Ryan Schmidt wrote: On Nov 3, 2013, at 19:27, Brickle Macho wrote: Trying to install gimp on Mavericks, getting the following error: Error: Unable to open port: can't set "compiler.blacklist": couldn't determine build number of compiler "gcc-4.2"

Re: Error: Unable to open port: can't set "compiler.blacklist": couldn't determine build number of compiler "gcc-4.2"

On Nov 3, 2013, at 19:27, Brickle Macho wrote: > Trying to install gimp on Mavericks, getting the following error: > > Error: Unable to open port: can't set "compiler.blacklist": couldn't > determine build number of compiler "gcc-4.2" On Mavericks (o

Error: Unable to open port: can't set "compiler.blacklist": couldn't determine build number of compiler "gcc-4.2"

Trying to install gimp on Mavericks, getting the following error: Error: Unable to open port: can't set "compiler.blacklist": couldn't determine build number of compiler "gcc-4.2" Any help appreciated. Michael. -- _

Re: select a gcc compiler

On Mon, Oct 21, 2013 at 8:39 PM, chamm wrote: > Chris-MacBook-Pro:~ Chris$ echo $PATH > > /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin:/Users/Chris/scripts > This is your problem; the shell will always take it from the earliest directory in $PATH that has it. (Also, why

Re: select a gcc compiler

Here is the output: Chris-MacBook-Pro:~ Chris$ sudo port select --set gcc mp-gcc45 Password: Selecting 'mp-gcc45' for 'gcc' succeeded. 'mp-gcc45' is now active. Chris-MacBook-Pro:~ Chris$ type gcc gcc is hashed (/usr/bin/gcc) Chris-MacBook-Pro:~ Chris$ echo $PATH /usr/bin:/bin:/usr/sbin:/sbin:/usr

Re: select a gcc compiler

On Oct 21, 2013, at 15:00, chamm wrote: > I did try both a new terminal window and using hash -r, but still the > default apple compiler is used. Please show the output of: type gcc echo $PATH ___ macports-users mailing list macports

Re: ROOT Compiler Settings?

Hi, Do you get the same problem if you don't use the macports clang compiler, but instead use whatever the default is for your system ? Could you make the source you are compiling available, so i can give it a try myself ? Chris > On 18 Oct 2013, at 07:57 pm, Jean-François Caro

ROOT Compiler Settings?

l+tmva+xml The +clang32 variant makes it compile using the MacPorts-supplied clang-3.2 port. root has a functionality called ACLiC where it automatically compiles, loads and links programs that use the ROOT libraries using the same compiler that was used to compile ROOT. When trying to comp

Re: Compiler selection

On Aug 14, 2013, at 2:21 PM, Dan Aldrich wrote: > Attempting to build gnuradio. I get the warning: > > WARNING: GNU Radio's VOLK component (which handles vector optimized > instructions and routines) compiles best when using GCC. The selected > compiler is CLANG, which wi

Re: Compiler selection

On Wed, Aug 14, 2013 at 2:21 PM, Dan Aldrich wrote: > Attempting to build gnuradio. I get the warning: > > WARNING: GNU Radio's VOLK component (which handles vector optimized > instructions and routines) compiles best when using GCC. The selected > compiler is CLANG, wh

Compiler selection

Attempting to build gnuradio. I get the warning: WARNING: GNU Radio's VOLK component (which handles vector optimized instructions and routines) compiles best when using GCC. The selected compiler is CLANG, which will result in a fully functioning GNU Radio install but the VOLK component

Re: Using -std=c++11 with the macports gcc-4.7 compiler

On Thu, Jan 17, 2013 at 12:56:26PM -0800, Jeremy Huddleston Sequoia wrote: > Interesting. I'll take a look, but if it's anything more than "apply > these patches to gcc" I can't really touch it due to gcc being GPL3. I've done some testing with a very simple C++ file and Makefile (see the attachme

Re: Using -std=c++11 with the macports gcc-4.7 compiler

Jeremy, I was puzzled by this line: > > Interesting. I'll take a look, but if it's anything more than "apply these > patches to gcc" I can't really touch it due to gcc being GPL3. Maybe I just need to read the GPL3 better. -Sterling ___ macports-us

Re: Using -std=c++11 with the macports gcc-4.7 compiler

On Jan 17, 2013, at 12:40, Clemens Lang wrote: > On Thu, Jan 17, 2013 at 12:25:57PM -0800, Jeremy Huddleston Sequoia wrote: >> In this case, there are two host C++ runtimes: the old libstdc++ (from >> gcc-4.2.1) and the new libc++ (llvm.org). clang lets you choose which >> one you build against.

Re: Using -std=c++11 with the macports gcc-4.7 compiler

On Thu, Jan 17, 2013 at 12:25:57PM -0800, Jeremy Huddleston Sequoia wrote: > In this case, there are two host C++ runtimes: the old libstdc++ (from > gcc-4.2.1) and the new libc++ (llvm.org). clang lets you choose which > one you build against. OK. Thanks for the explanation. There's some informat

Re: Using -std=c++11 with the macports gcc-4.7 compiler

On Jan 17, 2013, at 12:12, Clemens Lang wrote: > On Thu, Jan 17, 2013 at 11:55:56AM -0800, Jeremy Huddleston Sequoia wrote: > >> No. I'm saying that if a library uses libc++ and exports C++ objects, >> then its client needs to use libc++ as well. Similarly, if a library >> uses libstdc++ and ex

Re: Using -std=c++11 with the macports gcc-4.7 compiler

On Thu, Jan 17, 2013 at 11:55:56AM -0800, Jeremy Huddleston Sequoia wrote: > Not at all. > No. I'm saying that if a library uses libc++ and exports C++ objects, > then its client needs to use libc++ as well. Similarly, if a library > uses libstdc++ and exports C++ objects, then its client needs to

Re: Using -std=c++11 with the macports gcc-4.7 compiler

exports C++ objects, then its client needs to use libstdc++ as well. > On Wed, Jan 16, 2013 at 11:44:17PM -0600, Ryan Schmidt wrote: >> There's a lot of information available at install time that's not >> recorded anywhere that might be useful later. Compiler used, Xcode >

Re: Using -std=c++11 with the macports gcc-4.7 compiler

ry at any cost? On Wed, Jan 16, 2013 at 11:44:17PM -0600, Ryan Schmidt wrote: > There's a lot of information available at install time that's not > recorded anywhere that might be useful later. Compiler used, Xcode > version, OS X version and build number, number of CPUs, amount o

Re: Using -std=c++11 with the macports gcc-4.7 compiler

er in most cases, and the few where it did were bugs that > were (or should be) fixed in other ways. > > There's a lot of information available at install time that's not recorded > anywhere that might be useful later. Compiler used, Xcode version, OS X > version and

Re: Using -std=c++11 with the macports gcc-4.7 compiler

7;s a lot of information available at install time that's not recorded anywhere that might be useful later. Compiler used, Xcode version, OS X version and build number, number of CPUs, amount of memory, number of build jobs... We could record information like this, and provide a command

Re: Using -std=c++11 with the macports gcc-4.7 compiler

plain the need for having multiple versions of a >> library / program with different optimization levels for numerical >> computation. > > Ok, so you're analyzing the effects of different optimizations or something … > yeah… in that case, you can't really work around it

Re: Using -std=c++11 with the macports gcc-4.7 compiler

roviding a bogus mpif{77,90} wrapper). If your project has both >> C++ and Fortran dependencies, then the only way to compile the Fortran >> is to install gcc4X. Well, that usually means your configure script >> will also pick up gcc4X's C/C++ compiler. >> >> The

Re: Using -std=c++11 with the macports gcc-4.7 compiler

, I meant to explain the need for having multiple versions of a > library / program with different optimization levels for numerical > computation. Ok, so you're analyzing the effects of different optimizations or something … yeah… in that case, you can't really work around it by u

Re: Using -std=c++11 with the macports gcc-4.7 compiler

t a vanilla install of gcc47 on Mountain Lion, I get: >>> >>> >>> >>> Yeah, all of the MacPorts gcc compilers should be using >>> /opt/local/lib/libstdc++.dylib instead of /usr/libstdc++.dylib. This >>> should "just work" … if you

Re: Using -std=c++11 with the macports gcc-4.7 compiler

to compile the Fortran > is to install gcc4X. Well, that usually means your configure script > will also pick up gcc4X's C/C++ compiler. > > The second most common reason I've seen is the one you mention: errors > in the C++ compiler. If Apple decides to update their Xcode cla

Re: Using -std=c++11 with the macports gcc-4.7 compiler

local/lib/libstdc++.dylib instead of /usr/libstdc++.dylib. This should >> "just work" … if you're seeing something differnet, it would be helpful to >> see how ld is being called by the compiler. Run: >> >> g++-mp-4.7 -std=c++11 test11.cxx -v -Wl,-v >>

Re: Using -std=c++11 with the macports gcc-4.7 compiler

>> variables and just a vanilla install of gcc47 on Mountain Lion, I get: > > > > Yeah, all of the MacPorts gcc compilers should be using > /opt/local/lib/libstdc++.dylib instead of /usr/libstdc++.dylib. This should > "just work" … if you're seeing something

Re: Using -std=c++11 with the macports gcc-4.7 compiler

On Mon, Jan 14, 2013 at 8:32 AM, David Barto wrote: > fails because the /usr/lib/libstdc++.so is found first. What can I do to > find the proper /opt/local/lib/libstdc++.so? > > I've not modified the search paths in any way, I'm just trying to compile a > c++ program using the newer standard featu

Re: Using -std=c++11 with the macports gcc-4.7 compiler

fails because the /usr/lib/libstdc++.so is found first. What can I do to find the proper /opt/local/lib/libstdc++.so? I've not modified the search paths in any way, I'm just trying to compile a c++ program using the newer standard features. David David Barto dba...@visionpro.com

Re: Which compiler to use with boost thread

version 1.0.0, current version 169.3.0) "/usr/lib/libstdc++.6.dylib" means it was compiled with a system compiler (clang or llvm-gcc-4.2) so you should use one of those when compiling other code using boost. For comparison, pdftk was compiled with gcc45 as evidenced by "

Which compiler to use with boost thread

Hi, /tmp$ port info boost boost @1.50.0 (devel) Variants: debug, [+]no_single, [+]no_static, openmpi, python25, python26, python27, python31, python32, regex_match_extra, universal Description: Boost provides free portable peer-reviewed C++ libraries. The emphasis is on porta

Re: How to set C++ compiler outside Macports?

t; few months back, its use was experimental. > > The compiler MacPorts uses by default is chosen based on the Xcode version. > > Xcode 2.x: gcc-4.0 > Xcode 3.x: gcc-4.2 > Xcode 4.0 and 4.1: llvm-gcc-4.2 > Xcode 4.2 and up: clang Thanks again, Ryan. I have passed that informat

Re: How to set C++ compiler outside Macports?

On Sun, Jul 29, 2012 at 8:35 AM, Ian Wadham wrote: > On 29/07/2012, at 3:43 PM, Jeremy Huddleston Sequoia wrote: >> On Jul 28, 2012, at 21:35, Ian Wadham wrote: >>> In my Mac OS X environment, /usr/bin/c++ is a symbolic link to >>> llvm-g++-4.2, but I need it to

Re: How to set C++ compiler outside Macports?

On Jul 29, 2012, at 01:35, Ian Wadham wrote: > On 29/07/2012, at 3:43 PM, Jeremy Huddleston Sequoia wrote: >> On Jul 28, 2012, at 21:35, Ian Wadham wrote: >>> In my Mac OS X environment, /usr/bin/c++ is a symbolic link to >>> llvm-g++-4.2, but I need it to be to th

Re: How to set C++ compiler outside Macports?

On 29/07/2012, at 3:43 PM, Jeremy Huddleston Sequoia wrote: > On Jul 28, 2012, at 21:35, Ian Wadham wrote: >> In my Mac OS X environment, /usr/bin/c++ is a symbolic link to >> llvm-g++-4.2, but I need it to be to the same compiler as Macports >> used to build kdelibs4. T

Re: How to set C++ compiler outside Macports?

4605?replyto=1#comment > > The question now is "What is the best thing to do about it?". The > Macports logs tell me that kdelibs4 has been compiled with clang. > > KDE embeds this knowledge in some CMake macros it generates. > > In a Linux installation, that is fi

How to set C++ compiler outside Macports?

thing to do about it?". The Macports logs tell me that kdelibs4 has been compiled with clang. KDE embeds this knowledge in some CMake macros it generates. In a Linux installation, that is fine because you will use the same compiler both for building KDE and for doing your own development. Th

Re: Cleanup of compiler variants in py-numpy and py-scipy

On Mon, Jul 9, 2012 at 6:07 PM, Adam Mercer wrote: > Currently py-numpy and py-scipy have the following compiler variants: > gcc43, gcc44, gcc45, gcc46, and gcc47. Whereas the atlas port only > provides variants using gcc45, gcc46, and gcc47. Therefore I propose > removing the gcc4

Re: expat 2.1.0 fails - compiler test is trying to make a Universal binary?

On Jun 27, 2012, at 20:23, Greg Earle wrote: > The only 'issue' I seem to have left is "sudo port list installed" giving > me doubled/repeat output for a bunch of ports; e.g. > > -- > [18:14] macossex:/tmp % sudo port list installed | sort | diff -rC 1 > MacPorts_installed_ports.post-update.sor

Re: expat 2.1.0 fails - compiler test is trying to make a Universal binary?

Port echo versus port list Greg Earle wrote: >On Jun 27, 2012, at 5:44 PM, Ryan Schmidt wrote: > >> On Jun 27, 2012, at 10:33, Brandon Allbery wrote: >> >>> On Wed, Jun 27, 2012 at 10:27 AM, Greg Earle wrote: Looks to me from the 'configure' logs (see below) that it's trying >to build

Re: expat 2.1.0 fails - compiler test is trying to make a Universal binary?

On Jun 27, 2012, at 5:44 PM, Ryan Schmidt wrote: > On Jun 27, 2012, at 10:33, Brandon Allbery wrote: > >> On Wed, Jun 27, 2012 at 10:27 AM, Greg Earle wrote: >>> Looks to me from the 'configure' logs (see below) that it's trying to build >>> it as a Universal binary, when there is no PPC support

Re: expat 2.1.0 fails - compiler test is trying to make a Universal binary?

On Jun 27, 2012, at 10:33, Brandon Allbery wrote: > On Wed, Jun 27, 2012 at 10:27 AM, Greg Earle wrote: >> Looks to me from the 'configure' logs (see below) that it's trying to build >> it as a Universal binary, when there is no PPC support on my system. > > It's trying to build universal becaus

Re: expat 2.1.0 fails - compiler test is trying to make a Universal binary?

On Wed, Jun 27, 2012 at 10:27 AM, Greg Earle wrote: > Looks to me from the 'configure' logs (see below) that it's trying to build > it as a Universal binary, when there is no PPC support on my system. > It's trying to build universal because there's no 64-bit Wine, so it needs i386 support. (Win

expat 2.1.0 fails - compiler test is trying to make a Universal binary?

hile running configure, to aid debugging if configure makes a mistake. It was created by expat configure 2.1.0, which was generated by GNU Autoconf 2.68. Invocation command line was $ ./configure --prefix=/opt/local --disable-dependency-tracking [...] configure:2897: checking for gcc configu

Re: CMake and Fortran compiler

On Dec 9, 2011, at 19:33, Mojca Miklavec wrote: > But if I understand it right - when using llvm-gcc/g++ there is > probably no chance to find a fortran compiler unless the user > installed some "broken third party" variant? Is it OK to have llvm-gcc > set as default compil

Re: CMake and Fortran compiler

On Dec 9, 2011, at 17:33, Mojca Miklavec wrote: > When running ccmake I get the following error: > > CMake Error at > /opt/local/share/cmake-2.8/Modules/CMakeDetermineFortranCompiler.cmake:31 > (MESSAGE): > Could not find compiler set in environment variable FC: So set

Re: CMake and Fortran compiler

flew > with the +x11 variant. Thank you. In the meantime installation with gcc44 (since the only gfortran I have comes from there) and with default options otherwise suceeded. But if I understand it right - when using llvm-gcc/g++ there is probably no chance to find a fortran compiler

Re: CMake and Fortran compiler

ifferent one than mine. (But nevertheless ... > when I wrote the email I didn't see the posts sent after I attached my > logs.) > >> My bet is like another user you are using an external (and broken) gfortran >> compiler. > > My bet is I'm not. Because &qu

Re: CMake and Fortran compiler

;> >> See my attachment in http://trac.macports.org/ticket/32477. > > and if you read further down you will find the problem. ... which is probably a different one than mine. (But nevertheless ... when I wrote the email I didn't see the posts sent after I attached my logs.) >

Re: CMake and Fortran compiler

ill find the problem. My bet is like another user you are using an external (and broken) gfortran compiler. Try building with one of the gcc variants, to pick up a working one. > > But nevertheless ... my main question was about fortran. While the > ticket with root can be solved independ

Re: CMake and Fortran compiler

On Sat, Dec 10, 2011 at 00:45, Chris Jones wrote: > On 9 Dec 2011, at 11:33pm, Mojca Miklavec wrote: > >> Hello, >> >> I'm trying to compile Root with CMake (the Root package is MacPorts is >> broken, but even if it wasn't, there might be reasons why I would want >> to use a standalone version). >

Re: CMake and Fortran compiler

you ? I know there are a few issues, but all have workarounds or solutions. To say its broken is incorrect. Chris > > When running ccmake I get the following error: > > CMake Error at > /opt/local/share/cmake-2.8/Modules/CMakeDetermineFortranCompiler.cmake:31 > (MESSAGE): &g

CMake and Fortran compiler

.8/Modules/CMakeDetermineFortranCompiler.cmake:31 (MESSAGE): Could not find compiler set in environment variable FC: CMAKE_Fortran_COMPILER-NOTFOUND. Call Stack (most recent call first): cmake/modules/CheckCompiler.cmake:11 (enable_language) CMakeLists.txt:24 (include) CMake Error: Error required inte

Re: Unsupported compiler error when building MacVim

gcc. I suspect things are about to get >> > "interesting" in OSX developer land. Things have been getting interesting since the release of Lion. Please see: https://trac.macports.org/wiki/PortfileRecipes#compiler >> > I personally am holding off the Xcode upgra

Re: Unsupported compiler error when building MacVim

On Thu, Oct 13, 2011 at 18:33, Tim Johnson wrote: > * Brandon Allbery [111013 14:24]: > > The ghc mailing list has been fighting this for a bit; it seems Xcode 4.2 > no > > longer ships a non-llvm gcc. I suspect things are about to get > > "interesting" in OSX developer land. > > > > I personal

Re: Unsupported compiler error when building MacVim

dependencies > > > :info:build Unsupported compiler 'GCC 4.2' selected for architecture > > 'x86_64' > > > > > > P.S. Xcode 4.2 > > > > The ghc mailing list has been fighting this for a bit; it seems Xcode 4.2 no > longer ship

Re: Unsupported compiler error when building MacVim

On Thu, Oct 13, 2011 at 16:28, Tim Johnson wrote: > > :info:build === BUILD NATIVE TARGET PSMTabBarControlFramework OF PROJECT > PSMTabBarControl WITH THE DEFAULT CONFIGURATION (Release) === > > :info:build Check dependencies > > :info:build Unsupported compiler &

Re: Unsupported compiler error when building MacVim

* Tim Johnson [111013 11:32]: > I'm attempting to install MacVim on a Mac Mini (os = Lion) The build > process is failing. From the log is some of the (hopefully) relevant > error messages: > ## > :info:build Comp

Unsupported compiler error when building MacVim

I'm attempting to install MacVim on a Mac Mini (os = Lion) The build process is failing. From the log is some of the (hopefully) relevant error messages: ## :info:build Compiler: /Developer/usr/bin/gcc-4.2 :info:build R

Re: problem building mingw cross compiler

> I have now found the following ticket: > http://trac.macports.org/ticket/30349 > > Changing the compiler with > > if {${configure.compiler} == "llvm-gcc-4.2"} { >configure.compiler gcc-4.2 > } > > indeed works fine and basic cross-compilation se

  1   2   >