Re: py26-wxpython trouble (even without pgAdmin3)
On 2010-06-16, at 12:07 AM, Jim Busser wrote: sudo port -d install gtk2 +no_x11 +quartz # the above seemed happy sudo port -d install wxWidgets-python +carbon The above ran into problems, as posted. I therefore did uninstall / clean and tried instead sudo port -d install wxWidgets-python +gtk with results below, so maybe I should start over and choose just one (not both) among variants gtk2 +no_x11 ***or*** +quartz Below is what trying to install wxWidgets-python +gtk failed on: *** -Wall -Wundef -Wno-ctor-dtor-privacy -O2 -fno-strict-aliasing -pipe -O2 -arch x86_64 -fno-common ../src/unix/utilsx11.cpp ../src/unix/utilsx11.cpp:40:22: warning: gdk/gdkx.h: No such file or directory ../src/unix/utilsx11.cpp: In function 'bool wxQueryWMspecSupport(Display*, Window, Atom)': ../src/unix/utilsx11.cpp:269: error: 'gdk_x11_xatom_to_atom' was not declared in this scope ../src/unix/utilsx11.cpp:270: error: 'gdk_net_wm_supports' was not declared in this scope make: *** [monodll_utilsx11.o] Error 1 shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_wxWidgets-python/work/wxPython-src-2.8.10.1/build /usr/bin/make returned error 2 Error: Target org.macports.build returned: shell command failed DEBUG: Backtrace: shell command failed while executing command_exec build (procedure portbuild::build_main line 8) invoked from within $procedure $targetname Warning: the following items did not execute (for wxWidgets-python): org.macports.activate org.macports.build org.macports.destroot org.macports.install Log for wxWidgets-python is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_wxWidgets-python/main.log Error: Status 1 encountered during processing. To report a bug, see http://guide.macports.org/#project.tickets ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
On 2010-6-17 02:24 , Adam Mercer wrote: Hi There are several tickets open regarding build issues that can essentially be stemmed to the problem that the NumPy and SciPy, at the moment, do not support universal variants. The first of which #19397 [1] provides a solution to the universal build problem by using a wrapper script for the compiler. As far as i can tell tickets #22165, #22360, #22731, #23244, and #24942 [2-6] are all more or less due to NumPy not building universally. I never build universally myself so cannot reproduce these but it seems like a lot of people do so this issue needs to be fixed. I don't know why anyone would need a universal scipy or numpy. Do they have any dependents that only build for a particular arch? It might be best to just mark all the dependents as non-universal too. Another problem is that the default compiler for NumPy and SciPy is gcc43, whereas ATLAS is built gcc44 as it doesn't build correctly with gcc43, ticket #25206 [7] just switches over to using gcc44 as the default compiler so this will not be a solution for the universal build issue. The solution proposed in #19397 also switches the default compiler to gcc44 so this may be the correct approach. What do people this about bumping the default compiler to gcc44 for scientific ports (AFAICT there are no open tickets regarding gcc44 build issues)? It's high time this happened. There has been no movement on these tickets, so maintainer timeout is going to be invoked. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Installing old versions of ports
Is there an easy way to install old versions of ports? Googling turns up variations of this '07-ish method http://journal.bitshaker.com/articles/2007/10/20/install-old-versions-of-ports-using-macports/ just hoping in the years since, something easier might have been added Regards, Steve ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
Le 17 juin 2010 à 17:48, Joshua Root a écrit : I don't know why anyone would need a universal scipy or numpy. Do they have any dependents that only build for a particular arch? It might be best to just mark all the dependents as non-universal too. Well, that's not a question especially tied to scipy or numpy. Question is: with the rapid obsolescence of ppc* and i386 machines, what's the point in compiling universal apps ? If the response is: compile on a fast machine, execute also on a slow one, then I think it's worth also for scipy/numpy. Yet, I am skeptical, because Atlas configuration process use aggressive optimization based on processor discovery: if you compile, let's say, on a Core 2 duo machine, even in 32-bit mode, I bet the optimizer will embed SSE3/SSE4 instructions, that would not execute on old 32-bit processors. I wonder if someone has tried to execute a universal Atlas build on a i5 machine on a first generation MacBook with a Core Duo processor. If I am not mistaken, it might well crash. It's high time this happened. There has been no movement on these tickets, so maintainer timeout is going to be invoked. So, what are we going to do practically? Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
selfupdate fails
I just tried to selfupdate and it failed. Further down you can see: configure: error: C compiler cannot create executable! I wonder what's going on here! I never saw stg like this. --- . . . sent 20068 bytes received 462257 bytes 107183.33 bytes/sec total size is 54551356 speedup is 113.10 DEBUG: MacPorts sources location: /opt/local/var/macports/sources/rsync.macports.org/release/base --- Updating MacPorts base sources using rsync receiving file list ... done ./ deleting config.log sent 42 bytes received 6676 bytes 2687.20 bytes/sec total size is 2874599 speedup is 427.90 MacPorts base version 1.8.2 installed, DEBUG: Rebuilding and reinstalling MacPorts if needed MacPorts base version 1.9.0 downloaded. --- MacPorts base is outdated, installing new version 1.9.0 DEBUG: Permissions OK Installing new MacPorts release in /opt/local as root:admin; permissions 0755; Tcl-Package in /Library/Tcl checking build system type... i386-apple-darwin10.3.0 checking host system type... i386-apple-darwin10.3.0 checking target system type... i386-apple-darwin10.3.0 checking MacPorts version... 1.9.0 checking for sw_vers... /usr/bin/sw_vers checking for defaults... /usr/bin/defaults checking for xcode-select... /usr/bin/xcode-select checking Mac OS X version... 10.6.3 checking Xcode location... /Developer checking Xcode version... 3.2.2 checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/opt/local/var/macports/sources/rsync.macports.org/release/base': configure: error: C compiler cannot create executables See `config.log' for more details. DEBUG: Error installing new MacPorts base: shell command cd /opt/local/var/macports/sources/rsync.macports.org/release/base ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline make make install returned error 77 while executing macports::selfupdate [array get global_options] Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: shell command cd /opt/local/var/macports/sources/rsync.macports.org/release/base ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline make make install returned error 77 markos-imac:~ marko$ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Installing old versions of ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 17, 2010, at 12:33 , Steven Rogers wrote: Is there an easy way to install old versions of ports? Googling turns up variations of this '07-ish method http://trac.macports.org/wiki/howto/InstallingOlderPort is the official way. - -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) iEYEARECAAYFAkwaaKgACgkQIn7hlCsL25VCWgCg11H/xasTNmv9Tre2I0GoT1Rh KGAAnik67TJpyonwLuai/s2xF+P2N18u =uGqd -END PGP SIGNATURE- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
On Thu, Jun 17, 2010 at 9:34 AM, vincent habchi vi...@macports.org wrote: Well, that's not a question especially tied to scipy or numpy. Question is: with the rapid obsolescence of ppc* and i386 machines, what's the point in compiling universal apps ? If the response is: compile on a fast machine, execute also on a slow one, then I think it's worth also for scipy/numpy. Some ports only work 32-bit. So, I have to install them, and their dependencies, as 32-bit. But some of those dependencies are shared with other ports I use, which I have installed 64-bit. So those shared dependencies have to be universal. At least that's my understanding of a point to universal programs. Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Comparing installed versus new versions of ports
I'd like to know a good way to compare what's installed and out-of-date with what's available. If I say port installed outdated, I get a list of what's installed, that's out of date, with the installed version. But it doesn't show me the new version information. Is there a way to get this in Macports? -- Political and economic blog of a strict constitutionalist http://StrictConstitution.BlogSpot.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Comparing installed versus new versions of ports
On Jun 17, 2010, at 11:32 AM, Michael_google gmail_Gersten wrote: I'd like to know a good way to compare what's installed and out-of-date with what's available. If I say port installed outdated, I get a list of what's installed, that's out of date, with the installed version. But it doesn't show me the new version information. Is there a way to get this in Macports? Use `port list outdated`. From the man page: list If no argument is given, display a list of the latest version of all available ports. If portname(s) are given as arguments, display a list of the latest version of each port. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
On 2010-6-18 04:30 , Scott Webster wrote: On Thu, Jun 17, 2010 at 9:34 AM, vincent habchi vi...@macports.org wrote: Well, that's not a question especially tied to scipy or numpy. Question is: with the rapid obsolescence of ppc* and i386 machines, what's the point in compiling universal apps ? If the response is: compile on a fast machine, execute also on a slow one, then I think it's worth also for scipy/numpy. Some ports only work 32-bit. So, I have to install them, and their dependencies, as 32-bit. But some of those dependencies are shared with other ports I use, which I have installed 64-bit. So those shared dependencies have to be universal. At least that's my understanding of a point to universal programs. Right. Hence my question about dependents. Deploying to a machine that is different to the build machine has never really been supported. People packaging binaries build with MacPorts were still interested in that even back when universal meant i386/ppc, of course. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Comparing installed versus new versions of ports
On 2010-6-18 04:34 , Perry Lee wrote: On Jun 17, 2010, at 11:32 AM, Michael_google gmail_Gersten wrote: I'd like to know a good way to compare what's installed and out-of-date with what's available. If I say port installed outdated, I get a list of what's installed, that's out of date, with the installed version. But it doesn't show me the new version information. Is there a way to get this in Macports? Use `port list outdated`. From the man page: list If no argument is given, display a list of the latest version of all available ports. If portname(s) are given as arguments, display a list of the latest version of each port. What's wrong with 'port outdated'? - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On Jun 17, 2010, at 13:07, Marko Käning wrote: I just tried to selfupdate and it failed. Further down you can see: configure: error: C compiler cannot create executable! checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/opt/local/var/macports/sources/rsync.macports.org/release/base': configure: error: C compiler cannot create executables See `config.log' for more details. Well, can your C compiler create executables? Is Xcode properly installed? Check the config.log for more details! ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Comparing installed versus new versions of ports
On Jun 17, 2010, at 13:34, Perry Lee wrote: On Jun 17, 2010, at 11:32 AM, Michael_google gmail_Gersten wrote: I'd like to know a good way to compare what's installed and out-of-date with what's available. If I say port installed outdated, I get a list of what's installed, that's out of date, with the installed version. But it doesn't show me the new version information. Is there a way to get this in Macports? Use `port list outdated`. Do NOT use port list outdated; it does not do what you think it does; see: http://trac.macports.org/wiki/FAQ#portlist Use port outdated. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
New user wants to write c code in Xcode
Hello to All Rather annoying error came to my attention when I noticed my gdb complains even building a simple hello World c file with the following message in Xcode console: - /Developer/usr/bin/gdb: line 88: sed: command not found ERROR: No architecture specified with -arch argument. The Debugger has exited with status 1.The Debugger has exited with status 1. trying to trace back the problem I concluded that maybe my previous gdb install job done through Macports could be the issue... I tried to upgrade the gdb it failed. Then I tried to do a self update on the Macports based I got the follwing error: - MacPorts base version 1.8.2 installed, MacPorts base version 1.9.0 downloaded. --- MacPorts base is outdated, installing new version 1.9.0 Installing new MacPorts release in /opt/local as root:admin; permissions 0755; Tcl-Package in /Library/Tcl Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: shell command cd /opt/local/var/macports/sources/ rsync.macports.org/release/base ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline make make install returned error 1 --- can some one please let me know if I should uninstall macports in general or if not how could I go about : 1. updating my gcc 2. if the problem I am experiencing in Xcode has anything to do with the previous gcc/gdb install? I would really appreciate any pointers cheers arvand ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Adding configure options when installing a port
On Jun 16, 2010, at 19:31, Stephen Langer wrote: Therefore it's a serious mistake for a packaging system to assume that it's ok to enable openmp in libraries. A quick solution would be to provide both openmp and no-openmp variants, which would make users choose between fast stand-alone ImageMagick programs and libraries that can be linked by threaded apps. We don't need two variants; we only need one variant, openmp, which the user can either enable or disable. It just remains a question as to whether the variant should be enabled by default or not. What I'm hearing is that we should disable it by default. A better solution might be for the openmp and non-openmp versions of the libraries to have different names, so that both could be installed on the same system. Ugh. That sounds nasty. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: New user wants to write c code in Xcode
MacPorts base version 1.8.2 installed, MacPorts base version 1.9.0 downloaded. --- MacPorts base is outdated, installing new version 1.9.0 Installing new MacPorts release in /opt/local as root:admin; permissions 0755; Tcl-Package in /Library/Tcl Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: shell command cd /opt/local/var/macports/sources/rsync.macports.org/release/base ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline make make install returned error 1 This is interesting, it looks exactly like the error I get when I do a selfupdate, see thread selfupdate fails!!!___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Comparing installed versus new versions of ports
On Jun 17, 2010, at 11:38 AM, Joshua Root wrote: On 2010-6-18 04:34 , Perry Lee wrote: On Jun 17, 2010, at 11:32 AM, Michael_google gmail_Gersten wrote: I'd like to know a good way to compare what's installed and out-of-date with what's available. If I say port installed outdated, I get a list of what's installed, that's out of date, with the installed version. But it doesn't show me the new version information. Is there a way to get this in Macports? Use `port list outdated`. From the man page: list If no argument is given, display a list of the latest version of all available ports. If portname(s) are given as arguments, display a list of the latest version of each port. What's wrong with 'port outdated'? Er... nothing - just that I forgot `port outdated` shows the latest version as well. :P ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
Hi Ryan,
Well, can your C compiler create executables? Is Xcode properly installed?
Check the config.log for more details!
up to now i never had problems with my macports and Xcode installation…
config.log says this:
---
configure:3002: checking for gcc
configure:3018: found /opt/local/bin/no_default_gcc/gcc
configure:3029: result: gcc
configure:3258: checking for C compiler version
configure:3267: gcc --version 5
gcc --version
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3278: $? = 1
configure:3267: gcc -v 5
gcc -v
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3278: $? = 1
configure:3267: gcc -V 5
gcc -V
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3278: $? = 1
configure:3267: gcc -qversion 5
gcc -qversion
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3278: $? = 1
configure:3298: checking whether the C compiler works
configure:3320: gccconftest.c 5
gcc conftest.c
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
configure:3324: $? = 1
configure:3362: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME MacPorts
| #define PACKAGE_TARNAME macports
| #define PACKAGE_VERSION 1.9.0
| #define PACKAGE_STRING MacPorts 1.9.0
| #define PACKAGE_BUGREPORT macports-...@lists.macosforge.org
| #define PACKAGE_URL
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3367: error: in
`/opt/local/var/macports/sources/rsync.macports.org/release/base':
configure:3371: error: C compiler cannot create executables
See `config.log' for more details.
---
UsingTheRightCompiler rings a bell! :) You hinted that out to me when I
introduced the makeicns port.
But I didn't expect to see a message like this when I do an upgrade to 1.9.0…
I wonder how to proceed from here.
Greets,
Marko
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: New user wants to write c code in Xcode
On 2010-6-18 04:51 , Marko Käning wrote: MacPorts base version 1.8.2 installed, MacPorts base version 1.9.0 downloaded. --- MacPorts base is outdated, installing new version 1.9.0 Installing new MacPorts release in /opt/local as root:admin; permissions 0755; Tcl-Package in /Library/Tcl Error: /opt/local/bin/port: port selfupdate failed: Error installing new MacPorts base: shell command cd /opt/local/var/macports/sources/rsync.macports.org/release/base http://rsync.macports.org/release/base ./configure --prefix=/opt/local --with-tclpackage=/Library/Tcl --with-install-user=root --with-install-group=admin --with-directory-mode=0755 --enable-readline make make install returned error 1 This is interesting, it looks exactly like the error I get when I do a selfupdate, see thread selfupdate fails!!! Well yes, it would; none of the actual output is shown, just the command line that is used for selfupdate and the error saying selfupdate failed. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Adding configure options when installing a port
On Jun 17, 2010, at 2:44 PM, Ryan Schmidt wrote: On Jun 16, 2010, at 19:31, Stephen Langer wrote: Therefore it's a serious mistake for a packaging system to assume that it's ok to enable openmp in libraries. A quick solution would be to provide both openmp and no-openmp variants, which would make users choose between fast stand-alone ImageMagick programs and libraries that can be linked by threaded apps. We don't need two variants; we only need one variant, openmp, which the user can either enable or disable. That's what I meant. I guess I was using the word variant in a nontechnical sense. It just remains a question as to whether the variant should be enabled by default or not. What I'm hearing is that we should disable it by default. That would break the least amount of code. A better solution might be for the openmp and non-openmp versions of the libraries to have different names, so that both could be installed on the same system. Ugh. That sounds nasty. I agree. Can we get ImageMagick to allow openMP to be enabled or disabled at run time? That would also solve the problem. Such a switch doesn't exist at the moment, as far as I can tell. -- Steve -- -- stephen.lan...@nist.govTel: (301) 975-5423 -- -- http://math.nist.gov/mcsd/Staff/SLanger/ Fax: (301) 975-3553 -- -- NIST, 100 Bureau Drive, Stop 8910, Gaithersburg, Md 20899-8910 -- -- I don't think this will work. That's why it's science. -- -- Naomi Langer (age 6), 17 Feb 2003 -- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Adding configure options when installing a port
On Jun 17, 2010, at 13:59, Stephen Langer wrote: On Jun 17, 2010, at 2:44 PM, Ryan Schmidt wrote: On Jun 16, 2010, at 19:31, Stephen Langer wrote: Therefore it's a serious mistake for a packaging system to assume that it's ok to enable openmp in libraries. A quick solution would be to provide both openmp and no-openmp variants, which would make users choose between fast stand-alone ImageMagick programs and libraries that can be linked by threaded apps. We don't need two variants; we only need one variant, openmp, which the user can either enable or disable. That's what I meant. I guess I was using the word variant in a nontechnical sense. It just remains a question as to whether the variant should be enabled by default or not. What I'm hearing is that we should disable it by default. That would break the least amount of code. Ok, I'll do that. A better solution might be for the openmp and non-openmp versions of the libraries to have different names, so that both could be installed on the same system. Ugh. That sounds nasty. I agree. Can we get ImageMagick to allow openMP to be enabled or disabled at run time? That would also solve the problem. Such a switch doesn't exist at the moment, as far as I can tell. Then you should suggest that to the developers of ImageMagick. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Adding configure options when installing a port
On Thu, Jun 17, 2010 at 11:44 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 16, 2010, at 19:31, Stephen Langer wrote: Therefore it's a serious mistake for a packaging system to assume that it's ok to enable openmp in libraries. A quick solution would be to provide both openmp and no-openmp variants, which would make users choose between fast stand-alone ImageMagick programs and libraries that can be linked by threaded apps. We don't need two variants; we only need one variant, openmp, which the user can either enable or disable. It just remains a question as to whether the variant should be enabled by default or not. What I'm hearing is that we should disable it by default. I'm not entirely sure I agree with disabling by default. Unless I was reading this list, I would never have known about this issue, and would just go with the default. Disabling openmp would slow down everything (well, not quite everything I guess) I do with ImageMagick by a factor of 2. Same would happen with other ports that can use openmp if it was disabled there... I guess I'm just saying that there is a trade-off between universal compatibility and speed here. I don't have a good handle on how big of an issue the compatibility thing is. If it's quite isolated then I think having the twice (or more) as fast option as default is reasonable. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On Jun 17, 2010, at 2:58 PM, Marko Käning wrote: Well, can your C compiler create executables? Is Xcode properly installed? Check the config.log for more details! up to now i never had problems with my macports and Xcode installation… config.log says this: --- configure:3002: checking for gcc configure:3018: found /opt/local/bin/no_default_gcc/gcc you don't want it to find this compile, you want to use the one installed by Xcode. You probably have 'CC' set so AC_PROG_CC is finding this instead of the 'normal' Xcode installed compiler. When normally installing ports, Macports sanitizes the environment so this isn't an issue, but I think that this doesn't happen for building macports (I could be wrong). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Adding configure options when installing a port
On Jun 17, 2010, at 14:05, Scott Webster wrote: On Thu, Jun 17, 2010 at 11:44 AM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 16, 2010, at 19:31, Stephen Langer wrote: Therefore it's a serious mistake for a packaging system to assume that it's ok to enable openmp in libraries. A quick solution would be to provide both openmp and no-openmp variants, which would make users choose between fast stand-alone ImageMagick programs and libraries that can be linked by threaded apps. We don't need two variants; we only need one variant, openmp, which the user can either enable or disable. It just remains a question as to whether the variant should be enabled by default or not. What I'm hearing is that we should disable it by default. I'm not entirely sure I agree with disabling by default. Unless I was reading this list, I would never have known about this issue, and would just go with the default. Disabling openmp would slow down everything (well, not quite everything I guess) I do with ImageMagick by a factor of 2. Same would happen with other ports that can use openmp if it was disabled there... I guess I'm just saying that there is a trade-off between universal compatibility and speed here. I don't have a good handle on how big of an issue the compatibility thing is. If it's quite isolated then I think having the twice (or more) as fast option as default is reasonable. Users are expected to read the output of port variants to decide if they might want to use any of those variants... ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
This is what happens if I call CC from bash: --- markos-imac:~ marko$ sudo bash bash-3.2# CC i686-apple-darwin10-gcc-4.2.1: no input files --- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
On Thu, Jun 17, 2010 at 10:48, Joshua Root j...@macports.org wrote: I don't know why anyone would need a universal scipy or numpy. Do they have any dependents that only build for a particular arch? It might be best to just mark all the dependents as non-universal too. I agree, but I think one problem is that NumPy uses the same compiler flags as were used to build Python (at least that used to be the case), so if Python was built universally so was NumPy - not sure if this is still the case... It's high time this happened. There has been no movement on these tickets, so maintainer timeout is going to be invoked. Thanks for doing this, you're right it's past time this was done. Cheers Adam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On Jun 17, 2010, at 13:58, Marko Käning wrote:
Well, can your C compiler create executables? Is Xcode properly installed?
Check the config.log for more details!
up to now i never had problems with my macports and Xcode installation…
config.log says this:
---
configure:3002: checking for gcc
configure:3018: found /opt/local/bin/no_default_gcc/gcc
configure:3029: result: gcc
configure:3258: checking for C compiler version
configure:3267: gcc --version 5
gcc --version
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
[snip]
UsingTheRightCompiler rings a bell! :) You hinted that out to me when I
introduced the makeicns port.
But I didn't expect to see a message like this when I do an upgrade to 1.9.0…
I wonder how to proceed from here.
You made the changes described in UsingTheRightCompiler to discover when ports
are not using the configure.cc etc. variables. You have now discovered that
MacPorts itself does not use configure.cc when selfupdating. See:
http://trac.macports.org/ticket/23095
That ticket says this was supposed to have been fixed If it's not, the
ticket should be re-opened.
Until it's fixed, you will need to undo the changes described in
UsingTheRightCompiler in order to proceed. (I generally just edit the binpath
and change /opt/local/bin/no_default_gcc by one character, e.g. change it to
/opt/local/bin/no_default_gccx (a path that doesn't exist) so that when I later
want to re-enable it again I just have to change one character to do so.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: New user wants to write c code in Xcode
On Jun 17, 2010, at 13:43, arvand tiv wrote: /Developer/usr/bin/gdb: line 88: sed: command not found Does /usr/bin/sed exist and work? If not, put it back; it's an integral part of Mac OS X. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Adding configure options when installing a port
On Thu, Jun 17, 2010 at 12:08 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 17, 2010, at 14:05, Scott Webster wrote: I'm not entirely sure I agree with disabling by default. Unless I was reading this list, I would never have known about this issue, and would just go with the default. Disabling openmp would slow down everything (well, not quite everything I guess) I do with ImageMagick by a factor of 2. Same would happen with other ports that can use openmp if it was disabled there... I guess I'm just saying that there is a trade-off between universal compatibility and speed here. I don't have a good handle on how big of an issue the compatibility thing is. If it's quite isolated then I think having the twice (or more) as fast option as default is reasonable. Users are expected to read the output of port variants to decide if they might want to use any of those variants... Sure... but: a) Lots of people probably don't do that, perhaps particularly for common ports like ImageMagick, or if it is installed as a dependency. b) Lots of people would not understand that they likely want openmp enabled. c) Couldn't this apply almost as well to the people who want openmp disabled too? In Stephen's case his software is not distributed via macports. Is there software in macports that breaks with openmp enabled here? If so, it would be nice for macports to recognize this and tell them to use the no-openmp variant, but #126 :( Anyway, this is just the way I see it. Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On 2010-6-18 05:05 , Daniel J. Luke wrote: On Jun 17, 2010, at 2:58 PM, Marko Käning wrote: Well, can your C compiler create executables? Is Xcode properly installed? Check the config.log for more details! up to now i never had problems with my macports and Xcode installation… config.log says this: --- configure:3002: checking for gcc configure:3018: found /opt/local/bin/no_default_gcc/gcc you don't want it to find this compile, you want to use the one installed by Xcode. You probably have 'CC' set so AC_PROG_CC is finding this instead of the 'normal' Xcode installed compiler. When normally installing ports, Macports sanitizes the environment so this isn't an issue, but I think that this doesn't happen for building macports (I could be wrong). We do clean out the environment at startup. Marko must have CC in extra_env or something, in which case it's just doing what he asked it to. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On 2010-6-18 05:09 , Marko Käning wrote: This is what happens if I call CC from bash: --- markos-imac:~ marko$ sudo bash bash-3.2# CC i686-apple-darwin10-gcc-4.2.1: no input files --- You're just running /usr/bin/cc here because you're on a case-insensitive filesystem. The CC environment variable is probably what you're after. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
On 2010-6-18 05:12 , Adam Mercer wrote: On Thu, Jun 17, 2010 at 10:48, Joshua Root j...@macports.org wrote: I don't know why anyone would need a universal scipy or numpy. Do they have any dependents that only build for a particular arch? It might be best to just mark all the dependents as non-universal too. I agree, but I think one problem is that NumPy uses the same compiler flags as were used to build Python (at least that used to be the case), so if Python was built universally so was NumPy - not sure if this is still the case... It shouldn't be after the changes from #24802. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On Jun 17, 2010, at 14:14, Ryan Schmidt wrote: You have now discovered that MacPorts itself does not use configure.cc when selfupdating. See: http://trac.macports.org/ticket/23095 That ticket says this was supposed to have been fixed If it's not, the ticket should be re-opened. I'm assuming that this is in fact fixed, so long as MacPorts 1.9.0+ is the one doing the selfupdating; since the MacPorts doing the selfupdating in your case was 1.8.2 you still encountered the issue. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On 2010-6-18 05:14 , Ryan Schmidt wrote:
On Jun 17, 2010, at 13:58, Marko Käning wrote:
Well, can your C compiler create executables? Is Xcode properly installed?
Check the config.log for more details!
up to now i never had problems with my macports and Xcode installation…
config.log says this:
---
configure:3002: checking for gcc
configure:3018: found /opt/local/bin/no_default_gcc/gcc
configure:3029: result: gcc
configure:3258: checking for C compiler version
configure:3267: gcc --version 5
gcc --version
gcc: Error: You should be using ${configure.cc}
See http://trac.macports.org/wiki/UsingTheRightCompiler
[snip]
UsingTheRightCompiler rings a bell! :) You hinted that out to me when I
introduced the makeicns port.
But I didn't expect to see a message like this when I do an upgrade to 1.9.0…
I wonder how to proceed from here.
You made the changes described in UsingTheRightCompiler to discover when
ports are not using the configure.cc etc. variables. You have now discovered
that MacPorts itself does not use configure.cc when selfupdating. See:
http://trac.macports.org/ticket/23095
That ticket says this was supposed to have been fixed If it's not, the
ticket should be re-opened.
Until it's fixed, you will need to undo the changes described in
UsingTheRightCompiler in order to proceed. (I generally just edit the binpath
and change /opt/local/bin/no_default_gcc by one character, e.g. change it to
/opt/local/bin/no_default_gccx (a path that doesn't exist) so that when I
later want to re-enable it again I just have to change one character to do so.
The base configure script removes $prefix from its PATH. When it's
running from within MacPorts, 'gcc' *is* the right compiler for it to
use, so #23095 is a complete non-issue unless you've messed with
extra_env (unsupported) or actually changed what /usr/bin/gcc points to
(also unsupported).
- Josh
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
Le 17 juin 2010 à 20:30, Scott Webster a écrit : On Thu, Jun 17, 2010 at 9:34 AM, vincent habchi vi...@macports.org wrote: Well, that's not a question especially tied to scipy or numpy. Question is: with the rapid obsolescence of ppc* and i386 machines, what's the point in compiling universal apps ? If the response is: compile on a fast machine, execute also on a slow one, then I think it's worth also for scipy/numpy. Some ports only work 32-bit. So, I have to install them, and their dependencies, as 32-bit. But some of those dependencies are shared Right. I think we ought to identify these apps and figure out why they are 32-bit only and if they could be upgraded. AFAIK, 32-bit only was tied to the GUI using Carbon instead of Cocoa. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
On Thu, Jun 17, 2010 at 02:12:08PM -0500, Adam Mercer said: On Thu, Jun 17, 2010 at 10:48, Joshua Root j...@macports.org wrote: I don't know why anyone would need a universal scipy or numpy. Do they have any dependents that only build for a particular arch? It might be best to just mark all the dependents as non-universal too. I agree, but I think one problem is that NumPy uses the same compiler flags as were used to build Python (at least that used to be the case), so if Python was built universally so was NumPy - not sure if this is still the case... You might be interested in ticket #24802: http://trac.macports.org/ticket/24802 With that, -arch shouldn't be kept around for module builds. Bryan It's high time this happened. There has been no movement on these tickets, so maintainer timeout is going to be invoked. Thanks for doing this, you're right it's past time this was done. Cheers Adam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Adding configure options when installing a port
On Jun 17, 2010, at 3:17 PM, Scott Webster wrote: On Thu, Jun 17, 2010 at 12:08 PM, Ryan Schmidt ryandes...@macports.org wrote: On Jun 17, 2010, at 14:05, Scott Webster wrote: I'm not entirely sure I agree with disabling by default. Unless I was reading this list, I would never have known about this issue, and would just go with the default. Disabling openmp would slow down everything (well, not quite everything I guess) I do with ImageMagick by a factor of 2. Same would happen with other ports that can use openmp if it was disabled there... I guess I'm just saying that there is a trade-off between universal compatibility and speed here. I don't have a good handle on how big of an issue the compatibility thing is. If it's quite isolated then I think having the twice (or more) as fast option as default is reasonable. Users are expected to read the output of port variants to decide if they might want to use any of those variants... Sure... but: a) Lots of people probably don't do that, perhaps particularly for common ports like ImageMagick, or if it is installed as a dependency. b) Lots of people would not understand that they likely want openmp enabled. c) Couldn't this apply almost as well to the people who want openmp disabled too? In Stephen's case his software is not distributed via macports. Is there software in macports that breaks with openmp enabled here? If so, it would be nice for macports to recognize this and tell them to use the no-openmp variant, but #126 :( Anyway, this is just the way I see it. I don't know if there are other packages in macports that would break. I would like to be able to distribute our program from macports, but that's not going to happen soon. In the meantime, telling our users to install the no-openmp variant of imagemagick would be ok with us. I'll see if I can get the ImageMagick folks to comment on turning openmp on and off at runtime. -- Steve -- -- stephen.lan...@nist.govTel: (301) 975-5423 -- -- http://math.nist.gov/mcsd/Staff/SLanger/ Fax: (301) 975-3553 -- -- NIST, 100 Bureau Drive, Stop 8910, Gaithersburg, Md 20899-8910 -- -- I don't think this will work. That's why it's science. -- -- Naomi Langer (age 6), 17 Feb 2003 -- ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
On Thu, Jun 17, 2010 at 14:24, Joshua Root j...@macports.org wrote: I agree, but I think one problem is that NumPy uses the same compiler flags as were used to build Python (at least that used to be the case), so if Python was built universally so was NumPy - not sure if this is still the case... It shouldn't be after the changes from #24802. Great, I've been out of the loop for a couple of weeks so I'm trying to get back up to speed with everything. Cheers Adam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On Jun 17, 2010, at 14:29, Joshua Root wrote: On 2010-6-18 05:14 , Ryan Schmidt wrote: You made the changes described in UsingTheRightCompiler to discover when ports are not using the configure.cc etc. variables. You have now discovered that MacPorts itself does not use configure.cc when selfupdating. See: http://trac.macports.org/ticket/23095 That ticket says this was supposed to have been fixed If it's not, the ticket should be re-opened. Until it's fixed, you will need to undo the changes described in UsingTheRightCompiler in order to proceed. (I generally just edit the binpath and change /opt/local/bin/no_default_gcc by one character, e.g. change it to /opt/local/bin/no_default_gccx (a path that doesn't exist) so that when I later want to re-enable it again I just have to change one character to do so. The base configure script removes $prefix from its PATH. When it's running from within MacPorts, 'gcc' *is* the right compiler for it to use, so #23095 is a complete non-issue unless you've messed with extra_env (unsupported) or actually changed what /usr/bin/gcc points to (also unsupported). Well it doesn't seem to remove /opt/local/bin/no_default_gcc from the path (nor would I expect it to), ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On 2010-6-18 05:45 , Ryan Schmidt wrote: On Jun 17, 2010, at 14:29, Joshua Root wrote: On 2010-6-18 05:14 , Ryan Schmidt wrote: You made the changes described in UsingTheRightCompiler to discover when ports are not using the configure.cc etc. variables. You have now discovered that MacPorts itself does not use configure.cc when selfupdating. See: http://trac.macports.org/ticket/23095 That ticket says this was supposed to have been fixed If it's not, the ticket should be re-opened. Until it's fixed, you will need to undo the changes described in UsingTheRightCompiler in order to proceed. (I generally just edit the binpath and change /opt/local/bin/no_default_gcc by one character, e.g. change it to /opt/local/bin/no_default_gccx (a path that doesn't exist) so that when I later want to re-enable it again I just have to change one character to do so. The base configure script removes $prefix from its PATH. When it's running from within MacPorts, 'gcc' *is* the right compiler for it to use, so #23095 is a complete non-issue unless you've messed with extra_env (unsupported) or actually changed what /usr/bin/gcc points to (also unsupported). Well it doesn't seem to remove /opt/local/bin/no_default_gcc from the path (nor would I expect it to), Exactly. Doing precisely what you asked it to. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
You're just running /usr/bin/cc here because you're on a case-insensitive filesystem. The CC environment variable is probably what you're after. yep, you are right: Last login: Thu Jun 17 21:06:47 on ttys001 markos-imac:~ marko$ CC i686-apple-darwin10-gcc-4.2.1: no input files markos-imac:~ marko$ set | grep CC _=CC I didn't know that MacOSX's file system is case insensitive, actually. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
But well, the question is now: How do I go on to get a working macports setup again. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On Jun 17, 2010, at 14:50, Joshua Root wrote: On 2010-6-18 05:45 , Ryan Schmidt wrote: On Jun 17, 2010, at 14:29, Joshua Root wrote: On 2010-6-18 05:14 , Ryan Schmidt wrote: You made the changes described in UsingTheRightCompiler to discover when ports are not using the configure.cc etc. variables. You have now discovered that MacPorts itself does not use configure.cc when selfupdating. See: http://trac.macports.org/ticket/23095 That ticket says this was supposed to have been fixed If it's not, the ticket should be re-opened. Until it's fixed, you will need to undo the changes described in UsingTheRightCompiler in order to proceed. (I generally just edit the binpath and change /opt/local/bin/no_default_gcc by one character, e.g. change it to /opt/local/bin/no_default_gccx (a path that doesn't exist) so that when I later want to re-enable it again I just have to change one character to do so. The base configure script removes $prefix from its PATH. When it's running from within MacPorts, 'gcc' *is* the right compiler for it to use, so #23095 is a complete non-issue unless you've messed with extra_env (unsupported) or actually changed what /usr/bin/gcc points to (also unsupported). Well it doesn't seem to remove /opt/local/bin/no_default_gcc from the path (nor would I expect it to), Exactly. Doing precisely what you asked it to. Yes exactly. So #23095 is completely the relevant ticket, since it causes selfupdate to not use gcc anymore but to use the specific appropriate compiler. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On Jun 17, 2010, at 14:55, Marko Käning wrote: But well, the question is now: How do I go on to get a working macports setup again. Read the last paragraph here: http://lists.macosforge.org/pipermail/macports-users/2010-June/020623.html ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On 2010-6-18 06:04 , Ryan Schmidt wrote: On Jun 17, 2010, at 14:50, Joshua Root wrote: On 2010-6-18 05:45 , Ryan Schmidt wrote: On Jun 17, 2010, at 14:29, Joshua Root wrote: On 2010-6-18 05:14 , Ryan Schmidt wrote: You made the changes described in UsingTheRightCompiler to discover when ports are not using the configure.cc etc. variables. You have now discovered that MacPorts itself does not use configure.cc when selfupdating. See: http://trac.macports.org/ticket/23095 That ticket says this was supposed to have been fixed If it's not, the ticket should be re-opened. Until it's fixed, you will need to undo the changes described in UsingTheRightCompiler in order to proceed. (I generally just edit the binpath and change /opt/local/bin/no_default_gcc by one character, e.g. change it to /opt/local/bin/no_default_gccx (a path that doesn't exist) so that when I later want to re-enable it again I just have to change one character to do so. The base configure script removes $prefix from its PATH. When it's running from within MacPorts, 'gcc' *is* the right compiler for it to use, so #23095 is a complete non-issue unless you've messed with extra_env (unsupported) or actually changed what /usr/bin/gcc points to (also unsupported). Well it doesn't seem to remove /opt/local/bin/no_default_gcc from the path (nor would I expect it to), Exactly. Doing precisely what you asked it to. Yes exactly. So #23095 is completely the relevant ticket, since it causes selfupdate to not use gcc anymore but to use the specific appropriate compiler. My point is that 'gcc' would be fine had you not intentionally sabotaged it using binpath. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On Jun 17, 2010, at 15:06, Joshua Root wrote: On 2010-6-18 06:04 , Ryan Schmidt wrote: Yes exactly. So #23095 is completely the relevant ticket, since it causes selfupdate to not use gcc anymore but to use the specific appropriate compiler. My point is that 'gcc' would be fine had you not intentionally sabotaged it using binpath. Absolutely, since the point of the modifications described in UsingTheRightCompiler is to sabotage gcc so that you can identify software that is using gcc instead of the CC environment variable. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
Read the last paragraph here: http://lists.macosforge.org/pipermail/macports-users/2010-June/020623.html Oh, well, yes, I did that and it worked. Sorry, there were so many posts coming in that I got confused about how to proceed. :) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
Absolutely, since the point of the modifications described in UsingTheRightCompiler is to sabotage gcc so that you can identify software that is using gcc instead of the CC environment variable. Ha, well, that's the reason for the whole confusion: I forgot to disable this sabotage after I had successfully installed makeicns. So, well, what does this mean for macports itself then? Looks like there is still an issue here, since it would not install with your sabotage... ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
On Jun 17, 2010, at 14:32, vincent habchi wrote: I think we ought to identify these apps and figure out why they are 32-bit only and if they could be upgraded. AFAIK, 32-bit only was tied to the GUI using Carbon instead of Cocoa. Yes, a lot of the ports that are 32-bit-only are because of Carbon. wxWidgets comes to mind. The developers are working on the problem; who knows how long it will take. We also have a lot of ports for old software (some of which uses Carbon and is therefore 32-bit-only) which has been abandoned upstream and will never see another update. Wine won't be 64-bit for awhile. http://wiki.winehq.org/Wine64 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On 2010-6-18 06:14 , Marko Käning wrote: Absolutely, since the point of the modifications described in UsingTheRightCompiler is to sabotage gcc so that you can identify software that is using gcc instead of the CC environment variable. Ha, well, that's the reason for the whole confusion: I forgot to disable this sabotage after I had successfully installed makeicns. So, well, what does this mean for macports itself then? Looks like there is still an issue here, since it would not install with your sabotage... The only issue was with the configuration you were using. The sabotage caused collateral damage. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: selfupdate fails
On Jun 17, 2010, at 15:14, Marko Käning wrote: So, well, what does this mean for macports itself then? Looks like there is still an issue here, since it would not install with your sabotage... Read: http://lists.macosforge.org/pipermail/macports-users/2010-June/020629.html ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
port setrequested doesn't work
Hmmm, perhaps I have to switch over to sqlite before I try this one:
markos-imac:~ marko$ sudo port -d setrequested curl
Setting requested flag for curl to 1
registry is not open
while executing
registry::entry open $portname [lindex $i 1] [lindex $i 2] [lindex $i 3]
[lindex $i 5]
(foreach body line 2)
invoked from within
foreach i $ilist {
set regref [registry::entry open $portname [lindex $i 1]
[lindex $i 2] [lindex $i 3] [lindex $i 5]]
...
(uplevel body line 5)
invoked from within
uplevel 1 $block
(procedure foreachport line 18)
invoked from within
foreachport $portlist {
set composite_version [composite_version $portversion [array get
variations]]
if {![catch {set ilist [registry...
(procedure action_setrequested line 8)
invoked from within
$action_proc $action $portlist [array get global_options]
(procedure process_cmd line 87)
invoked from within
process_cmd $remaining_args
invoked from within
if { [llength $remaining_args] 0 } {
# If there are remaining arguments, process those as a command
set exit_status [process_cmd $remaining...
(file /opt/local/bin/port line 4391)
markos-imac:~ marko$
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
Ryan, Yes, a lot of the ports that are 32-bit-only are because of Carbon. wxWidgets comes to mind. The developers are working on the problem; who knows how long it will take. Yes, I know that. I am afraid the wx-cocoa part is lacking help from experienced Cocoa users. I begin to have a fairly good experience in Cocoa, but I am simply deterred by C++: that language is so awful to me that I swore to never write a line of C++ again, especially after having tasted Obj-C. We also have a lot of ports for old software (some of which uses Carbon and is therefore 32-bit-only) which has been abandoned upstream and will never see another update. Couldn't we just get rid of them? Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: New user wants to write c code in Xcode
On Jun 17, 2010, at 15:42, arvand tiv wrote: On Thu, Jun 17, 2010 at 12:15 PM, Ryan Schmidt wrote: On Jun 17, 2010, at 13:43, arvand tiv wrote: /Developer/usr/bin/gdb: line 88: sed: command not found Does /usr/bin/sed exist and work? If not, put it back; it's an integral part of Mac OS X. your help saved me! I simply went a head and copied the binary file in my usr/bin from the local/bin and it magically worked out! I am not sure what happend to the original sed but I am happy now... local/bin -- did you mean /usr/local/bin or /opt/local/bin? I wouldn't recommend copying sed from either of those locations since they're probably not the same version of sed that was originally shipped with your Mac. Instead you should copy /usr/bin/sed from another computer running the same version of Mac OS X that you are, or from your Mac OS X install disc. If you have anything in /usr/local you should move or delete it because it can interfere with MacPorts. Instead, use MacPorts to install any software you need. Don't forget to use Reply All (not Reply) when replying so your message gets to the list too and not just to me. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
RE: firefox-x11 matplotlib
Date: Sat, 10 Apr 2010 15:42:45 +0200 Subject: Re: firefox-x11 matplotlib From: vim.u...@googlemail.com To: macports-users@lists.macosforge.org broken... - gumby(s002)| sudo port -v install firefox-x11-devel +internal_dependencies Password: --- Computing dependencies for firefox-x11-devel. --- Fetching firefox-x11-devel --- firefox-3.6.3.source.tar.bz2 doesn't seem to exist in /opt/local/var/macports/distfiles/firefox-x11-devel --- Attempting to fetch firefox-3.6.3.source.tar.bz2 from http://www.mirrorservice.org/sites/releases.mozilla.org/pub/mozilla.org/firefox/releases/3.6.3/source/ % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 46.3M 100 46.3M0 0 134k 0 0:05:52 0:05:52 --:--:-- 130k --- Verifying checksum(s) for firefox-x11-devel --- Checksumming firefox-3.6.3.source.tar.bz2 --- Extracting firefox-x11-devel --- Extracting firefox-3.6.3.source.tar.bz2 --- Applying patches to firefox-x11-devel --- Applying /opt/local/var/macports/sources/rsync.macports.org/release/ports/www/firefox-x11-devel/files/patch-dylib_file.diff patching file config/config.mk Hunk #1 succeeded at 682 (offset -22 lines). --- Applying /opt/local/var/macports/sources/rsync.macports.org/release/ports/www/firefox-x11-devel/files/527612.patch patching file browser/installer/Makefile.in Hunk #1 succeeded at 120 (offset 4 lines). --- Applying /opt/local/var/macports/sources/rsync.macports.org/release/ports/www/firefox-x11-devel/files/549746.patch patching file browser/installer/package-manifest.in --- Configuring firefox-x11-devel Error: You cannot install firefox-x11-devel for the architecture(s) i386 because Error: its dependency heimdal only contains the architecture(s) x86_64. Error: Error: Try rebuilding heimdal (and all its dependencies) with Error: the +universal variant by running Error: Error: sudo port upgrade --enforce-variants heimdal +universal Error: Error: Target org.macports.configure returned: incompatible architectures in dependencies Warning: the following items did not execute (for firefox-x11-devel): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. Before reporting a bug, first run the command again with the -d flag to get complete output. gumby(s002)| sudo port upgrade --enforce-variants heimdal +universal Password: Sorry, try again. Password: --- Computing dependencies for heimdal --- Fetching heimdal --- Verifying checksum(s) for heimdal --- Extracting heimdal --- Applying patches to heimdal --- Configuring heimdal --- Building heimdal --- Staging heimdal into destroot Note: heimdal installs files outside the common directory structure. --- Deactivating heimdal @1.2.1_0 --- Computing dependencies for heimdal --- Installing heimdal @1.2.1_0+universal --- Activating heimdal @1.2.1_0+universal --- Cleaning heimdal gumby(s002)| sudo port -v install firefox-x11-devel +internal_dependencies Password: --- Computing dependencies for firefox-x11-devel. --- Configuring firefox-x11-devel Error: You cannot install firefox-x11-devel for the architecture(s) i386 because Error: its dependency libcanberra only contains the architecture(s) x86_64. Error: Error: Try rebuilding libcanberra (and all its dependencies) with Error: the +universal variant by running Error: Error: sudo port upgrade --enforce-variants libcanberra +universal Error: Error: Target org.macports.configure returned: incompatible architectures in dependencies Warning: the following items did not execute (for firefox-x11-devel): org.macports.activate org.macports.configure org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. Before reporting a bug, first run the command again with the -d flag to get complete output. gumby(s002)| sudo port upgrade --enforce-variants libcanberra +universal --- Computing dependencies for pkgconfig --- Fetching pkgconfig --- Verifying checksum(s) for pkgconfig --- Extracting pkgconfig --- Configuring pkgconfig --- Building pkgconfig --- Staging pkgconfig into destroot --- Deactivating pkgconfig @0.23_1 --- Computing dependencies for pkgconfig --- Installing pkgconfig @0.23_1+universal --- Activating pkgconfig @0.23_1+universal --- Cleaning pkgconfig --- Computing dependencies for gzip --- Fetching gzip --- Verifying checksum(s) for gzip --- Extracting gzip --- Applying patches to gzip --- Configuring gzip --- Building gzip --- Staging gzip into destroot --- Deactivating gzip @1.4_0 --- Computing dependencies for gzip --- Installing gzip @1.4_0+universal --- Activating gzip @1.4_0+universal --- Cleaning gzip --- Computing
arm-elf-gcc3 fetch then build problem
Hi, Summary: Mainly a link problem with _libiconv and _libiconv_close and _libiconv_open. Also URLs are broken for fetch. Hopefully I haven't missed something really stupid, or already covered. Apologies in advance if so. Long version: = Can anyone reproduce this problem? I have built/installed arm-elf-binutils and arm-elf-gcc successfully. sudo port install arm-elf-gcc3 Got: sudo port install arm-elf-gcc3 --- Computing dependencies for arm-elf-gcc3 --- Fetching arm-elf-gcc3 Error: No defined site for tag: gcc, using master_sites --- Attempting to fetch gcc-3.4.6.tar.bz2 from gnu:gcc/gcc-3.4.6/ --- Attempting to fetch gcc-3.4.6.tar.bz2 from ftp://sources.redhat.com/pub/newlib/:newlib Error: Target org.macports.fetch returned: fetch failed Log for arm-elf-gcc3 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_arm-elf-gcc3/main.log Error: Status 1 encountered during processing. Ok, so something wrong with the URLs perhaps... No problem, get gcc-3.4.6.tar.bz2 from somewhere (probably http://ftp.gnu.org/gnu/gcc/gcc-3.4.6/) and put it in ... /opt/local/car/macports/dist/gcc Try again: sudo port install arm-elf-gcc3 Get's much further but... Error: Target org.macports.build returned: shell command failed Log for arm-elf-gcc3 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_arm-elf-gcc3/main.log Inside the log: :info:build cc -no-cpp-precomp -pipe -O2 -arch x86_64 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H -I. -I. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_arm-elf-gcc3/work/gcc-3.4.6/gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_arm-elf-gcc3/work/gcc-3.4.6/gcc/. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_arm-elf-gcc3/work/gcc-3.4.6/gcc/../include -I../intl -c insn-recog.c \ :info:build -o insn-recog.o :info:build cc -no-cpp-precomp -pipe -O2 -arch x86_64 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long-DHAVE_CONFIG_H -o Tcollect2 \ :info:build collect2.o tlink.o intl.o version.o ../libiberty/libiberty.a -L/usr/lib ../intl/libintl.a -L/opt/local/lib -liconv :info:build Undefined symbols: :info:build _libiconv_open, referenced from: :info:build __nl_init_domain_conv in libintl.a(loadmsgcat.o) :info:build __nl_init_domain_conv in libintl.a(loadmsgcat.o) :info:build _libiconv_close, referenced from: :info:build __nl_free_domain_conv in libintl.a(loadmsgcat.o) :info:build _libiconv, referenced from: :info:build __nl_find_msg in libintl.a(dcigettext.o) :info:build (maybe you meant: _libiconv_set_relocation_prefix) :info:build ld: symbol(s) not found :info:build collect2: ld returned 1 exit status :info:build make[1]: *** [collect2] Error 1 :info:build make[1]: *** Waiting for unfinished jobs :info:build make: *** [all-gcc] Error 2 :info:build shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_arm-elf-gcc3/work/build /usr/bin/make -j4 all AR_FOR_TARGET=arm-elf-ar AS_FOR_TARGET=arm-elf-as LD_FOR_TARGET=arm-elf-ld NM_FOR_TARGET=arm-elf-nm RANLIB_FOR_TARGET=arm-elf-ranlib returned error 2 Anyone got any ideas how to fix this? My system: Mac OS X 10.6.3 (Snow Leopard), x86. MacPorts 1.9.0. i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659) Regards, Rob ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: arm-elf-gcc3 fetch then build problem
On Jun 17, 2010, at 16:34, Rob Probin wrote: Summary: Mainly a link problem with _libiconv and _libiconv_close and _libiconv_open. Also URLs are broken for fetch. Please file an issue in the issue tracker for each of these problems. sudo port install arm-elf-gcc3 --- Computing dependencies for arm-elf-gcc3 --- Fetching arm-elf-gcc3 Error: No defined site for tag: gcc, using master_sites --- Attempting to fetch gcc-3.4.6.tar.bz2 from gnu:gcc/gcc-3.4.6/ --- Attempting to fetch gcc-3.4.6.tar.bz2 from ftp://sources.redhat.com/pub/newlib/:newlib Error: Target org.macports.fetch returned: fetch failed Log for arm-elf-gcc3 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_arm-elf-gcc3/main.log Error: Status 1 encountered during processing. Yeah, that looks strange. :info:build collect2.o tlink.o intl.o version.o ../libiberty/libiberty.a -L/usr/lib ../intl/libintl.a -L/opt/local/lib -liconv :info:build Undefined symbols: :info:build _libiconv_open, referenced from: :info:build __nl_init_domain_conv in libintl.a(loadmsgcat.o) :info:build __nl_init_domain_conv in libintl.a(loadmsgcat.o) :info:build _libiconv_close, referenced from: :info:build __nl_free_domain_conv in libintl.a(loadmsgcat.o) :info:build _libiconv, referenced from: :info:build __nl_find_msg in libintl.a(dcigettext.o) I'm unclear why a libintl.a is being used here; I would have expected libintl.dylib to have been used via -lintl. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: firefox-x11 matplotlib
On Jun 17, 2010, at 16:33, Instruct ICC wrote: Also, I found out something interesting last night while trying to build all the components separately from multiple Terminals. MacPorts is smart enough to lock files, so any Terminal would block until the file was unlocked or perform the next step even if another Terminal had started the install. Not entirely: http://trac.macports.org/ticket/19935 My machine was starved for processes. It would be cool if a new strategy was implemented by MacPorts to spawn multiple threads of building all the dependencies to run in parallel instead of serially. The existing locking mechanism would sort it out. I bet build/install times would be shorter. Even single core machines would benefit. I don't know how you'd sync the logging of what steps are happening though -- Maybe just preface each log like so: [Thread 1: ]--- Computing dependencies for firefox-x11 [Thread 1: ]--- Dependencies to be installed: xulrunner gconf dbus-glib dbus policykit libcanberra libnotify [Thread 1: ]--- Spawning threads: xulrunner gconf dbus-glib dbus policykit libcanberra libnotify [Thread 2: ]--- Computing dependencies for xulrunner [Thread 3: ]--- Computing dependencies for gconf [Thread 4: ]--- Computing dependencies for dbus-glib [Thread 5: ]--- Computing dependencies for dbus [Thread 6: ]--- Computing dependencies for policykit [Thread 7: ]--- Computing dependencies for libcanberra [Thread 8: ]--- Computing dependencies for libnotify [Thread 1: ]--- Building dbus etc. I can see that there might be a benefit. In fact I personally do start multiple installations in parallel myself quite often (manually). I doubt we'll be making such a major change to how MacPorts works, however. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: firefox-x11 matplotlib
On Jun 17, 2010, at 5:33 PM, Instruct ICC wrote: I wanted to port forward Safari (ssh -X|Y), but learned that I need an X11 app, so I was trying firefox-x11. You might be able to get the behavior you want by using ssh as a SOCKS proxy (http://www.mikeash.com/ssh_socks.html). I've used it with Safari before (and it works quite well). -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Port list leaves does not work
On Thu, Jun 17, 2010 at 7:39 PM, Michael_google gmail_Gersten keybou...@gmail.com wrote: I just upgraded to the new port. I cannot get the leaves to work correctly. Maybe you need to convert your registry to sqlite format as described here: http://lists.macosforge.org/pipermail/macports-announce/2010-June/08.html ? Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Port list leaves does not work
On Thu, Jun 17, 2010 at 7:45 PM, Scott Webster sewebs...@gmail.com wrote: On Thu, Jun 17, 2010 at 7:39 PM, Michael_google gmail_Gersten keybou...@gmail.com wrote: I just upgraded to the new port. I cannot get the leaves to work correctly. Maybe you need to convert your registry to sqlite format as described here: http://lists.macosforge.org/pipermail/macports-announce/2010-June/08.html I didn't realize that was needed for the leaves. -- Political and economic blog of a strict constitutionalist http://StrictConstitution.BlogSpot.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Port list leaves does not work
On 2010-6-18 13:48 , Michael_google gmail_Gersten wrote: On Thu, Jun 17, 2010 at 7:45 PM, Scott Webster sewebs...@gmail.com wrote: On Thu, Jun 17, 2010 at 7:39 PM, Michael_google gmail_Gersten keybou...@gmail.com wrote: I just upgraded to the new port. I cannot get the leaves to work correctly. Maybe you need to convert your registry to sqlite format as described here: http://lists.macosforge.org/pipermail/macports-announce/2010-June/08.html I didn't realize that was needed for the leaves. It isn't. (But you really ought to anyway, it's way faster.) By the new port do you mean 1.9.1? - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: py26-wxpython trouble (even without pgAdmin3)
On 2010-06-17, at 4:32 PM, Jim Busser wrote: sudo port -d install gtk2 +no_x11 ok, found http://trac.macports.org/ticket/24312 ... recalculating... -- Jim ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
