Re: New Mac OS Forge administrator
Ryan, > I'm pleased finally to be able to tell you that I have been hired to be your > new Mac OS Forge administrator. I have been involved in improving MacPorts > for years as a committer and as a manager, and now as a Mac OS Forge > administrator I will work on ensuring our infrastructure runs smoothly too. That’s great news. Your dedication to the project as well as your expertise is unparalleled. It’s a great move, and I’m very happy you’ve been chosen. I’m sure you will shine in your new responsibilities! All the best! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: OpenSceneGraph Broken
I have created a ticket, and posted the log file there: https://trac.macports.org/ticket/48410 OSG uses a now deprecated piece of the API. That’s why it fails. I’ll see if I can post a kludge to make it work. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On 20 Jan 2015, at 03:49, Craig Treleaven ctrelea...@macports.org wrote: Upgrade: http://eshop.macsales.com/shop/SSD/OWC I, for example, have a MacBook Air 6,2 with the PCIe SSD. No upgrade available. :( Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Using xz by default for compression
On 20 Jan 2015, at 12:21, Mojca Miklavec mo...@macports.org wrote: A slight disadvantage of xz is that many users still don't know how to decompress such files, but this argument doesn't apply here since port would do everything automatically for the user. I fully support Mojca’s proposal! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
Salut Akim ! Hi Ryan! I'm talking about removing the copy kept in that directory at the end of the process. I suppose this is a leftover from the time when Internet bandwidth was unreliable and expensive, and it was well worth keeping a local copy than to trust a flaky remote server or a rickety connexion. Personally, I’m in the same case as Akim. What I do is that I regularly backup the contents of the directory on some external USB drive (in fact, I even do it twice, one manually and one automatically through Time Machine) and then if ever I get struck in a mire, I restore it. But I admit it is not very useful nowadays. It should be optional, at least when the version installed is the default one, i.e. the binary can be re-downloaded verbatim from the server (not a bespoken version with various variants set). Similarly, is there a way to disable the storing of the source files in …/distfiles? Cheers! (À bientôt Akim!) Vincent PS: Maybe it would be nice to be able to specify alternate directories for archives, so that one could precisely backup (or move) the directory on some external disk, and then restore from it, if need be. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
Clemens: I disagree. I often use deactivation and activation, and I'd have to re-download the archive every time I did that, it would be a major hassle for me. I agree. Of course, your mileage may vary. That’s why I think it’d mayhap be worth investigating the possibility of having more than one directory to retrieve the archives from. This way, you could easily swap the files out of the SSD to an external drive, that you’d connect in case you’d need one of the files backed up there. No, but there is going to be `port reclaim` in 2.4, that deletes files you no longer need. Give it a try if you're running trunk, it could easily free up a gigabyte or two. Will do that tonight. Great news! Thanks. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
Oops, not ‘bespoken’, ‘bespoke’. ‘it was well worth keeping a local copy RATHER than to trust a flaky remote server or a rickety connexion.’ Who said I needed a proofreader? :) V. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: /opt/local/macports/software
On 19 Jan 2015, at 20:13, Craig Treleaven ctrelea...@macports.org wrote:
If one has a too-small SSD, it seems more-than-a-little strange to complain
that building/installing a bunch of software packages consumes it. Get a
bigger drive. Or smaller expectations.
Personally, when I bought my MacBook Air two years ago, I had a few spare bucks
and had the choice between {a bigger SSD} or {a faster CPU and 8 GB RAM}.
I chose the latter, and stuck with a 128 MB SSD.
Vincent
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
Re: error installing qgis
Hi there! First of all, thanks Brandon for investigating into this. […] But now I am embarrassed to ask, how the heck do I start qgis? There is no qgis in /opt/local/bin Normally, you should find it in /Applications/MacPorts/QGis Best wishes for 2015! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Samba 4 port
On 16 Dec 2014, at 16:37, Craig Treleaven ctrelea...@macports.org wrote: https://trac.macports.org/ticket/38834 See also: Thanks so much Craig. Is there any reason why the port hasn’t been committed? I got a bit lost in all the comments. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Samba 4 port
Hi there, the samba 4 port is completely outdated (it’s a pre-4.0.0 version, dating back more than two years ago, while the current one is 4.1.0). Is there any chance to have an updated version soon? Thanks, Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: installing octave +gcc48 installs gcc47?
$ sudo port install octave +atlas +gui +gcc48 --- Computing dependencies for gcc47 --- Fetching archive for gcc47 Do you have atlas already installed or not? V. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: installing octave +gcc48 installs gcc47?
Le 8 nov. 2014 à 18:40, Frank Schima m...@macports.org a écrit : It could be a dependency built with gcc47 and it is getting updated. Yeah, I concur. That was precisely why I was asking if atlas was installed. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Case-sensitive file system
Le 6 nov. 2014 à 21:20, Dave Horsfall d...@horsfall.org a écrit : There was a discussion here on the Mac's case-sensitive-but-not-quite file system, and I was convinced to leave it the way it is (it breaks something in MacPorts or something). Well, I've just been convinced otherwise… I’ve been running MacPorts on a case-sensitive HFS+ disk for years now, and it works like a charm. Don’t let you gull by the grapevine! Dave Horsfall DTM (VK2KFU) Bliss is a MacBook with a FreeBSD server. » 73s de F5RCS! ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
Le 18 mars 2014 à 07:06, Watson Ladd watsonbl...@gmail.com a écrit : Dear all, When I attempt to compile a C program using -march=native I receive a bunch of errors about nonexistent instructions in temporary assembler files. This does not happen without that command. Does anyone have any bright ideas for how to fix this? Has anyone else had this problem and been able to fix it? You can’t compile with -march=native using gcc. All gcc compilers rely on Apple provided old ‘as’, which is frozen at the last GPL v2 revision (Apple decided to chuck all v3 GPL’d code). This version is so hoary that it does not support neither AVX nor newer extensions. As a result, if you use -march=native with a reasonably modern hardware, GCC will pass AVX instructions to Apple ‘as’ which rejects them as unknown. If you want to use the -march=native switch, use Clang instead (LLVM-AS handles new extensions correctly). Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
Salut René, Le 18 mars 2014 à 10:44, René J.V. Bertin rjvber...@gmail.com a écrit : On Tuesday March 18 2014 09:43:57 Vincent Habchi wrote: If you want to use the -march=native switch, use Clang instead (LLVM-AS handles new extensions correctly). Or use -march=native -no-avx , or simply -march=core2 if you insist on having AVX. -march=core2 precisely avoids AVX (AVX was introduced on the next ‘tock’, Nehalem). You can still get SSE4.2 with -msse4.2 with the old Apple ‘as’ though. Note that when your code isn't optimised for using SIMD instructions you'll likely see very little benefit from using the full instruction set. In fact, in the testing I did I got better floating point performance using gcc 4.7 with -march=core2 than with clang 3.3 with -march=native . I *think* clang still doesn't have a (good) auto-vectorisation engine, while gcc's has become quite impressive IMHO. That’s not what the latest Phoronix tests seemed to point out (but with clang 3.4). http://www.phoronix.com/scan.php?page=articleitem=llvm34_gcc49_compilersnum=1 Bonne journée ! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: gcc-mp-4.8 -march=native fails
Le 18 mars 2014 à 12:28, Chris Jones jon...@hep.phy.cam.ac.uk a écrit : ... and for fortran support, it is fine to mix gfortran from any gcc compiler, with clang, as there are no issues with mixing c++ runtimes (as obviously fortran doesn't need this). That’s fortunate, because otherwise we’d have a hard time with Atlas… ;) V. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
wxWidgets30 libraries oddities
Hi there, When I build wxWidgets30, I get these, e.g. in libwx_osx_cocoau_html: Air nm /opt/local/lib/libwx_osx_cocoau_html-2.9.dylib | c++filt | grep SetHTMLWindowTitle 0004284a T wxHtmlWindow::SetHTMLWindowTitle(wxString const) 00063250 T wxHtmlListBox::SetHTMLWindowTitle(wxString const) 0004285c T non-virtual thunk to wxHtmlWindow::SetHTMLWindowTitle(wxString const) 00063256 T non-virtual thunk to wxHtmlListBox::SetHTMLWindowTitle(wxString const) Those “non-virtual thunks” then give rise to errors when one tries to link against the missing functions, e.g.: non-virtual thunk to wxHtmlWindow::SetHTMLWindowTitle(wxString const), referenced from: vtable for CACTIVE_Description in active_description.o vtable for CACTIVE_HTMLExtraInfo in active_HTMLExtraInfo.o Since I am totally ignorant of the arcanes of C++, can someone tell me if this a bug or an expected behavior under appropriate conditions? Thanks, Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: [Macports] QT5 For Mac port
On 11 juil. 2013, at 15:51, Michael Dickens michae...@macports.org wrote: I haven't tried the 5.1 series yet, I will have a look while I am on holiday later this month, but I cannot endorse the charge of being THE maintainer of qt5, even if I succeed: I would place the port under the ‘openmaintainer’ regime. MacPorts is a great piece of software, and many of its developers are already remunerated for (at least part of) the work they do (e.g., by the company they work for; by some outside contract -- either of which has an interest in some specific ports). Well, that’s somewhat a surprise to me. I do it for fun and the personal pleasure of being somehow helpful to a large number of people throughout the world. But I can easily imagine that keeping up with qt is such a pain that it is well worth some form of reward. Cheers! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Happy New Year and Congrats on a work well done
Ryan, And to you as well! On behalf of the management thank you to all the port maintainers for keeping your ports awesome, to all those hacking away on base to make to better, and to all the users for your continued support— Thanks also to you for keeping a vigilant eye, pointing out weirdnesses and errors, and being so helpful. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Trouble installing PostgreSQL
Le 10 déc. 2012 à 08:46, Ryan Schmidt ryandes...@macports.org a écrit : sudo sysctl -w kern.sysv.shmmax=1073741824 sudo sysctl -w kern.sysv.shmall=1073741824 What does that do? This increases the contents of shared memory available to userland processes using System V semantics. The last line should *not* be a size in bytes, but a size in pages (= 4,096 bytes). I had to do that too, the default values happens to be slightly undersized, especially when you need to support more than a few clients. But the problem of Behrang (now, that’s a Persian name, isn’t it?) is not related to that. It is caused by using sudo from a nonexistent working directory (i.e. “.”), probably because it was deleted while installing postgresql92. Try doing “cd” first, then all the other commands. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: gfortran with Xcode 4.3.2 unreliable
However, a comprehensive test suite that tests out fine with GCC 4.2, 4.3, 4.4, 4.5, 4.6, and 4.7, along with all flavors of (buggy) intel fortran compilers, and the PGI compilers all fail with this particular gfortran build. I will look through your patch and see if it fixes my problems (this is affecting quite a few users of this program suite). If so, hopefully the port maintainer (or some other dev) can apply this fix, because just fixing it for me is not enough (I have the 10.6 SDK, so I'm not even affected by this). Are you using clang or llvm-gcc to compile gmp? Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gfortran with Xcode 4.3.2 unreliable
On 10 juin 2012, at 09:08, Ryan Schmidt ryandes...@macports.org wrote: This problem with the gmp port has already been fixed in r94119. Was there a new test suite applied after this patch? The conclusion we must use llvm-gcc42 instead of clang seems to bear a relation with something I noticed on Atlas (together with the maintainer), that is (purely mathematical) code fails testing. As if the FP code produced by clang was somehow buggy. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Universal netcdf-fortran
Salut ! I should add that MacPorts should know not to supply -arch flags to compilers that don't support it, so I don't know why C compiler cannot create executables here. The config.log should have more info. I've been searching the documentation to learn what muniversal portgroup was, without much success so far. Can you point me to the right place ? Does this imply some rewritting of the portfile ? Or can it be passed as command-line options ? Muniversal is a portgroup, that is to say it defines additional variables and procedures that every port member of the group undergo while being build. More specifically, muniversal causes ports to be split in two (or more) versions, e.g. i386 and x86_64, that are compiled separately and then gathered together using lipo during the destroot phase. But unfortunately, in the case of netcdf-fortran, it does not work. I’ll see if we can use the wrappers I designed for py-numpy. Bonne soirée, ciao ! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: upgrade atlas
Hi! On 26 mai 2012, at 02:10, M. Daniel Becque mdbec...@gmail.com wrote: Did a selfupdate and Macports upgraded to 2.1.1. Had a bunch of upgrades that went okay but upgrading Atlas and get the following error from the log file. :info:build /usr/bin/make -f Make.top build :info:build make[1]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/atlas/work/atlas-3.9.75/build' :info:build Make.top:1: Make.inc: No such file or directory Without the full debug log, I can only guess, but this usually mean that the Portsystem selected an unknown compiler for whatever reason, or that you don’t have a Fortran compiler installed. Please provide the full log, and open a ticket if you deem it necessary. Cheers! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Atlas compiling causes havoc
On 20 mai 2012, at 08:03, Jasper Frumau jasperfru...@gmail.com wrote: I have been trying to upgrade all outdated ports for three days now. Bumped into several issues. Now I got stuck at Atlas. What’s your configuration? What port command did you execute to upgrade Atlas? V. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Atlas compiling causes havoc
Jasper, MacPorts config is: […] That’s not a configuration problem, it is just a matter of what exactly the port upgrade has done. Try to update manually (port -v install atlas +gcc45). Atlas can take a very long time to build if you don’t choose one of the GCC compilers with x86_64 arch. Any other combination (use of clang, or non x86_64 build) triggers the timing mechanism: Atlas finds out by itself what is the best set of parameters for each kernel by compiling hundreds of combinations and measuring their efficiency. This is a long process (it took around five hours on the Lion Buildbot), but guarantees near optimality on a per machine (CPU, memory…) per compiler basis at the end. If you use clang and build universal, for instance, compiling Atlas might take over ten hours if you have a Core2Duo machine. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Atlas compiling causes havoc
Jasper, I checked py25-numpy: […] You can build pyXX-numpy and pyXX-scipy without relying on Atlas. Just don’t select the +atlas variant. I’d interested in knowing what variant gives the best performance, by the way. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Atlas compiling causes havoc
On 20 mai 2012, at 10:21, Jasper Frumau jasperfru...@gmail.com wrote: Could I force uninstall them and then install them without atlas. How? 'port -f uninstall py25-numpy' then 'port install py25-numpy' (without +atlas). Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Error Upgrading Atlas
I fixed one port issue - iso-code registry issue - and continued upgrading the outdated ports. Now I got stuck at Atlas with these errors: UNKNOWN COMPILER '/opt/local/bin/gcc-mp-4.4' for ICC: you must also supply flags! make[1]: *** [atlas_run] Error 1 make: *** [IRun_comp] Error 2 Assertion failed: (!system(ln)), function ProbeComp, file /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_math_atlas/atlas/work/atlas-3.9.47/build/..//CONFIG/src/config.c, line 125. […] I just upgraded to 3.9.74 in r93299. Please test again. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Error Upgrading Atlas
On 19 mai 2012, at 12:57, Jasper Frumau jasperfru...@gmail.com wrote: I did a selfupdate and tried again. Still the same issue it seems: UNKNOWN COMPILER '/opt/local/bin/gcc-mp-4.4' for ICC: you must also supply flags! make[1]: *** [atlas_run] Error 1 Gcc44 has been removed from the possible compilers with this upgrade. If you get the same message after a selfupdate, then something is wrong in your configuration. V. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Error Upgrading Atlas
On 19 mai 2012, at 13:29, Jasper Frumau jasperfru...@gmail.com wrote: Did another selfupdate and sudo port upgrade outdated. Now a different error: […] Please use the same variants again, perform 'port clean atlas' or specify the force option (-f). Do as asked: port clean atlas and try again. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Error Upgrading Atlas
By the way, Atlas takes a long time to compile with clang (several hours). This is normal. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Error Upgrading Atlas
On 19 mai 2012, at 14:37, Jasper Frumau jasperfru...@gmail.com wrote: it is running after the clean-up. Thanks! Glad it worked – thanks for testing! Good luck! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
New port: postgis2 (PostGIS 2.0)
Hi everybody,
I’ve committed this morning in r92462 a new port corresponding to PostGIS v 2.0
and up.
This port is incompatible with postgis, that is to say PostGIS 1.x. Both
install the same files at the same place.
It is therefore *mandatory* before you upgrade to save your databases,
uninstall postgis 1.5 first by removing it from your PostGreSQL environment
(you should have a script uninstall_postgis in
${prefix}/share/postgresqlXX/contrib/postgis) and then by uninstalling the
port, compile the postgis2 port, and restore your databases using the provided
script. Further instructions on the PostGIS site http://postgis.refractions.net.
Be careful of some side effects: the_geom is now called geom, SRID is limited
to 999,999, etc.
PostGIS 2 requires Geos = 3.3.2 so you must upgrade this library too.
Please try and report any bug you may find.
Thanks,
Vincent
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: New port: postgis2 (PostGIS 2.0)
Hi Puneet,
I’ve committed this morning in r92462 a new port corresponding to PostGIS v
2.0 and up.
This port is incompatible with postgis, that is to say PostGIS 1.x. Both
install the same files at the same place.
Hmmm... That's a deal breaker for me. I don't have two machines to test it
out. Since the two different versions can haooily coexist, why not make it so
instead of requiring uninstalling PostGIS 1.5?
Because PostGIS 2.0 won’t compile with PostGIS 1.5 installed. There are several
include files that PostGIS 1.5/2.0 installs in ${prefix}/include that take
precedence over the ones furnished with the distribution (because
-I${prefix}/include appears before other -I… during compilation). Thus, if you
have PostGIS 1.5 installed, PostGIS 2.0 will mistakenly use the already
installed headers to compile and fail.
Besides, I am not sure that the libraries installed by PostGIS 1.5 and PostGIS
2.0, albeit bearing the same name, have the same API.
Vincent
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
PostGIS 2.0.1 ß port
Chers amis, liebe Freude, cari amici, dear friends, I am about to commit the PostGIS 2.0 port. It is going to be v.2.0.1-svn because 2.0.0 has a bug that prevents successful compilation with clang. I reported it, and it has been corrected in svn. This can be upgraded to 2.0.1 when it is released. Question: ideally PostGIS should be indexed under both databases and gis. Is it permissible to change in the 2.0 Portfile ? Thanks Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: PostgreSQL 91 does not start automatically
Which logs should I look at? Nothing I can see in Pg and Apache2 logs.
You should have a log in ${prefix}/log/postgresql91, no?
Vincent
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: PostgreSQL 91 does not start automatically
as I noted above, there is nothing I can discern in posgresql91.log that
shows any attempt was made to run anything. Nevertheless, when I typed
$ sudo port load postgresql91-server
I got the message that the port was already loaded. Yet, it was not running.
So, I unloaded the port and then loaded it again, and the db started fine.
Did you check the ownership and permissions of your
${prefix}/var/db/postgresql91 directory and subdirectories?
Vincent
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: PostgreSQL 91 does not start automatically
On 25 avr. 2012, at 21:23, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Keep in mind: _both_ postgres and apache are not successfully running at boot. Thanks for reminding me that. Are you sure the partition on which your binaries reside is mounted when the launchd daemon starts? V. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: PostgreSQL 91 does not start automatically
On 25 avr. 2012, at 21:38, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: But since they say already loaded, they've got to be there and something is colliding. System load should reveal all… That’s baffling. Or something kills the processes just after they are launched. Jeremy, are you using an iPhone to answer? :) Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: PostgreSQL 91 does not start automatically
On 25 avr. 2012, at 21:47, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Nope, the build laptop is the only Apple product I've got these days; I'm just spewing my stream of consciousness/babbling. That's was just because the log you typed in your previous message has magically been altered into load, so I thought this was the unmistakable evidence of an iPhone spelling corrector! ;) I'm going to bed (it's late over here in old Europe). Sorry to let you pondering alone on this oddity. Have fun! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: MacPorts 2.1.0-beta1 now available for testing
On 23 avr. 2012, at 17:42, Joshua Root j...@macports.org wrote: Have many people tested this? We've only had one real bug reported so far, and that one was present in 2.0.4. What’s new in this version? Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: MacPorts 2.1.0-beta1 now available for testing
•••—•— On 23 avr. 2012, at 17:56, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: What’s new in this version? https://trac.macports.org/browser/tags/release_2_1_0-beta1/base/ChangeLog Thanks! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: use a different default configure.compiler (was: UsingTheRightCompiler)
Hi everybody, Le 16 avr. 2012 à 09:00, Ryan Schmidt ryandes...@macports.org a écrit : On Apr 15, 2012, at 23:04, Jeff Singleton wrote: I just can't say a lot for Clang. I have mentioned this before. I have taken many suggestions. Tried Tried and Tried some more to like Clang. I just can't do it. Its ugly. It causes more problems between ports that depend on one another, yet some are built with Clang, other built with GCC. I've not heard of any problems related to some ports being built with clang and others built with other compilers; if you have examples of this please let us know. My own experience is that Clang works fine. LLVM based tools are now used extensively, be it by Apple for traditional GCC substitution, or by other companies like, e.g. NVidia for its OpenGL JIT compiler. LLVM is modern, extensible, modular and easily ported to any hardware whereas GCC is hoary, monolithic and totally cryptic, let alone code documentation. The only drawback I still see to the use of Clang is its inferior performance when it comes to floating point brute force. In fact, I carried out some tests with Clang on Atlas latest development version. Good news is that Clang works fine, even with AVX assembly; Bad news is that performance is still worse than GCC, sometimes by more than 40%, at least on Linux. On OS X, no comparison is possible since the provided assembler ‘/usr/bin/as’ is antiquated and does not recognize AVX instructions, and using Clang as an assembler fails because GCC emits non Intel compliant instructions that llvm-mc does not recognize. This might be slightly different on OS X because since LLVM is basically Apple driven there might be additional optimizations enabled for Darwin. But there is still room for additional improvements. Additional tools like a new linker, lld, are underway; It will eventually replace ld64. By the way, is it possible to add GCC 4.7 as a possible compiler? Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Saga GIS
Hi there, On Jan 11, 2012, at 03:14, mysiar wrote: I'm brand new to MAC but has been using Linux for years. I tried to compile SAGA GIS http://www.saga-gis.org on MAC OS X 10.7.2 and failed. I did use wxWidgets-devel @2.9.3_0+sdl I did: ln -s /opt/local/include/wx-2.9/ /opt/local/include/wx My configure options are --prefix=/opt/saga --enable-unicode after make I got error “api_callback.cpp: In function 'CSG_String SG_UI_Get_Application_Path()': api_callback.cpp:611: error: conversion from 'wxCStrData' to non-scalar type 'CSG_String' requested make[3]: *** [api_callback.lo] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 ” My intention is to create a port for this sometime in the future. Since I’m finally going to have some spare time in the next few days, maybe we can try setting up this port together? It would be an interesting addition to QGis too, through its SAGA connector. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Where is gas?
Le 7 janv. 2012 à 03:15, Watson Ladd watsonbl...@gmail.com a écrit : Dear all, I'm on a Mac OS X 10.6.8 machine, and need a more modern assembler. Install the newest clang port and try clang -x assembler Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Atlas problem when cleaning and rebuilding [was: Re: Poppler error]
Hi there, but it is hanging since quite a few minutes at this point: $ sudo port upgrade outdated --- Computing dependencies for atlas --- Fetching archive for atlas --- Attempting to fetch atlas-3.9.47_0+gcc44.darwin_11.x86_64.tbz2 from http://packages.macports.org/atlas --- Fetching atlas --- Verifying checksum(s) for atlas --- Extracting atlas --- Applying patches to atlas --- Configuring atlas --- Building atlas Building Atlas can take a long long time (up to ~ 6/7 hours) depending on your processor type. So don’t be too in a hurry. I’m currently working on the next version (3.9.54) but it fails during the configuration phase. On the other hand, llvm/clang 3.0 arrives, with AVX support, so it might make sense to postpone atlas 3.9.54 until llvm 3.0 release. Il mondo che Atlas porta è un pò complesso ;) Buona giornata ciononostante ! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Atlas problem when cleaning and rebuilding [was: Re: Poppler error]
The problem is that I performed the clean all command trying to get rid of the poppler problem and now, as soon as I try to do port outgrade, it goes to Atlas, and so I have no postpone option allowing me to keep on using macport. So I think I will have to wait the ~ 6/7 hours hoping the other packages are faster; otherwise I will have mac port functioning again in the next millennium… For what hardware are you compiling ? x86_64 or i386 ? V. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Octave .m files opening in Xcode
Le 25 sept. 2011 à 15:38, Wesley Davis woda...@aggies.ncat.edu a écrit : I just installed Octave, Gnuplot and Aquaerm using Macports. I installed all three so that I could see the plots of my Ocave scripts. However, now when run my Ocatave .m scripts I get the Xcode application and not the text editor .m is the standard extension for Objective-C source files. No wonder XCode pops up when you double-click them… Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gcc 4.6 port for OSX Lion
Salut Christophe, I need to install gcc 4.6 on OSX Lion. I found serveral ports that mention gcc in their title, but I'm not sure of which one to choose. You can’t. Well, there is a gcc46 port but it installs a deprecated ß-version. I myself tried to update the port and install gcc 4.6.[01]: It fails because of a ld (1) bug in the 10.7 toolchain – at least, if you want gfortran to be built: It does not seem to plague C, C++ and obj-C front-ends. So, if you are just interested in the C-family languages, I can give you the portfile so you can have a try. Ciao ! Vincent PS: pas d’espaces en anglais avant ! et ?, contrairement au français… :) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gcc 4.6 port for OSX Lion
Le 4 août 2011 à 16:42, Ryan Schmidt a écrit : Yes, although the date of that version is the same day the final 4.6.0 version was released, so it can't be too terribly different. Thanks for pointing out this: I hadn’t even checked. Yet, it is impossible, with this port, to build both fortran and java, it seems. Cheers Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gcc 4.6 port for OSX Lion
Ryan, Yes, the gfortran and java variants are conflicting. Pre-release versions of the gcc ports have always had this restriction, though there is no need for it. I submitted a patch three years ago to fix it but the maintainer declined to apply it: https://trac.macports.org/ticket/16410 Any good reason why? But as you noticed gfortran doesn't work with gcc46 anyway right now: https://trac.macports.org/ticket/30166 Perhaps that is one of the reasons why the the maintainer of the port has not updated it to the final version. (Final-version gcc ports have always included gfortran and java support before, and for gcc46 that seems not to be possible right now.) Ryan, you’re just brilliant! I hadn’t seen this report: in fact, I get the same error on Lion, and opened a radar. But I am not sure it will be duly considered (or maybe duplicate). By the way, Portfile for llvm-devel and dragonegg (based on gcc45) are working. May I submit those? Cheers, Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: atlas G5 upgrade issue?
Hi Ivan, When I went to upgrade atlas, I found it claiming it would be compiling for the G4 architecture (ppc) on a G5 (ppc64) machine, and that it would lead to inferior performance. I do not recall seeing this on previous install/upgrades of atlas. Does atlas have support for the G5 architecture? If it does, what is preventing it from compiling for a G5? Does anyone know of a workaround? I'm on a G5, obviously, with MacPorts 1.9.2, and gcc 4.4.6. I wrote a G5 support (ppc64) for Atlas, but it was difficult to debug. At a certain point in time, somebody pointed out that G5 floating point performance was not so different from G4, and that 64-bit instructions would fill the cache more quickly and maybe result in inferior performance. That's why I quit the ppc64 idea and fused both into a single ppc option. But if somebody is able to settle the G4/G5 dispute with definitive data about FP computing, I'll be happy to try to raise the ppc64 options from the deads. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Still cannot upgrade atlas.
You're on a PPC machine ? Vincent Le 29 avr. 2011 à 05:59, Frank J. R. Hanstick a écrit : Hello, Tried upgrading again last night and still cannot upgrade atlas. Attached is the log file. Is this ever going to get fixed? main.log Frank J. R. Hanstick tro...@comcast.net ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Compile PostGIS 2.0 (SVN)
Hi there, not quoting the thread, I think it may be wise to add a temporary port called PostGIS-devel or something approaching. It is the second thread about PostGIS 2.0, and I expect the number of people going to try to compile the SVN version to increase, given the new capacities (especially raster file handling). Would it be acceptable to create a separate port, and remove it when the final 2.0 version will be out? Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Atlas errors throttling apparently enabled
Titanium PowerBook G4 (PowerPC) running 10.5.8 Did you try compiling Atlas with the computer tied to the mains or not? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python wrong install dir
Le 4 mars 2011 à 10:48, Hauke Fuhrmann a écrit : Hi there, without any Python knowledge I try to run some setup script from some Python project like $sudo python setup.py install What is the output of sudo which python? Gruß, Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
Le 14 févr. 2011 à 20:50, Olaf Foellinger a écrit : Today I've noticed during an upgrade that macports tries to install atlas. That's because it's a standard dependency of py26-numpy. py26-numpy also adds gcc44 this way which is quite a lot for gnucash users. I would recommend to omit atlas from the default dependencies of p25-numpy. What do you think? Should I enter a ticket for this? Numpy, gewissermaßen :), is a computing package: scipy uses numpy. As such, it strives to work as fast as possible (nobody wants to wait ten hours the result of a matrix inversion knowing that it can be done in ten seconds when the algorithm is optimized). ATLAS takes hours to compile on 32-bit machines because it *really tries hard* to find the most efficient algorithm for each BLAS routine. Besides, ATLAS can use the latest GCC version, whereas the Accelerate framework embedded in MacOS is probably compiled with the same compiler as the one furnished with Xcode. It would be worth benchmarking code linked with an up to date ATLAS and the Apple Accelerate framework, and see which wins. IMHO, the problem is not in numpy depending on Atlas, which is correct ; it is in other packages depending on numpy for tasks that may involve very little of it (e.g. using numpy as a convenient means to get array functions). Gimp relies ultimately on numpy for matrix convolutions in image processing, which can take quite a lot of time when the size of the image is large. FWIW Viele Grüße auch aus Paris unter Wolken, Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can't import GDAL into Python (2.5 or 2.6)
Le 20 août 2010 à 10:39, JP Glutting a écrit : I haven't used GDAL from Python before, so I may be failing to understand something here, but I can't use import gdal from either Python 2.5 or Python 2.6. I have GDAL installed (sudo port install gdal +python25 +python26 +sqlite3) and it is listed as active. i had gdal 1.6.2_3 installed before, and I re-installed with the extra options, but I have the same problem either way. When I try improt gdal (or import ogr) or from osgeo import gdal [just in case, for no particular reason], I get an ImportError. That's all you get? I mean, no futher error message? Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can't import GDAL into Python (2.5 or 2.6)
The port is outdated. Current revision is 1.7.2, while currently we provide 1.6.2. I'm not home right now, so I can't do a thing about it, but I'll try to upgrade the port Sunday. Wait for the upgrade, and then try again. vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can't import GDAL into Python (2.5 or 2.6)
Le 20 août 2010 à 11:58, John Hauf a écrit : Hello, I did this: 1. Edit /opt/local/etc/macports/macports.conf: Set portautoclean to no 2. Install sudo port install gdal +python26 +sqlite3 3. Make some softlinks in /opt/local/bin: ln -s python2.6 python, ln -s python2.6-config python-config, ln -s easy_install-2.6 easy_install This is unnecessary. You should install python_select instead and use it. It does a cleaner job. As for gdal, you're right: the current Portfile does not activate the swig glue, so nothing gets installed in site-packages. I'll see what's going on. Meanwhile, I've successfully updated to 1.7.2, which requires only bumping the version and the related checksums. Cheers Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can't import GDAL into Python (2.5 or 2.6)
Le 20 août 2010 à 13:03, JP Glutting a écrit : Which is odd, because I have a gdal.py file (and an osgeo directory) in my /opt/local/lib/python2.6/site-packages directory. But nothing else. I imagine they were supposed to have been installed in /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages Try this: sudo port -v configure gdal (with your options) and look, at the end of the output, for this line: checking where to install Python modules... What path is printed after? In my case, I have: /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages which is correct. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can't import GDAL into Python (2.5 or 2.6)
JP, you will find in attachement a new version of the Portfile and a new patch file that should work. If your installation is standard, the portfile goes in: /opt/local/var/macports/sources/rsync.macports.org/release/ports/gis/gdal and the patch file in: /opt/local/var/macports/sources/rsync.macports.org/release/ports/gis/gdal/files Try them (don't forget to save the old version if something would go wrong). Normally, it should work. Please use only one +python option, either 25 or 26 because they are mutually exclusive. I've added, by the way, a new spatialite option to link against it, but there is a bug in spatialite that prevents it from working, so forget it right now. If it work, I'll open a bug report and suggest the new files to upgrade to 1.7.2 and fix the bug. Cheers! Vincent Portfile Description: Binary data patch-swig_python_GNUmakefile Description: Binary data ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can't import GDAL into Python (2.5 or 2.6)
Hi JP,
That didn't seem to resolve the problem, but i am not sure I installed
everything properly. I am a little out of my depth as far as the ins-and-outs
of Macports packages go. Maybe someone else can give it a try and see if it
works for them (if they have the problem - since no one else seemed to have
this problem here, maybe there is just something messed up with my
configuration).
Sorry it did not work. It is definitely not a problem with your configuration.
With the current GNUMakefile in the swig/python directory of gdal, the python
plugins go in /opt/local/lib/python26/… instead of /opt/local/Library/… so that
is definitely a bug.
Also, was the patch supposed to have a . at the end of it? I took it off,
and it overwrote the existing patch file, but that may have been a mistake.
Strange, as I can see no '.' at the end of my patch file. Anyhow, I'll file a
bug report/enhancement request asking to bump to 1.7.2 and solving this bug.
My own version works, as far as libspatialite is buggy:
PM: python
Python 2.6.5 (r265:79063, Aug 16 2010, 14:14:17)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type help, copyright, credits or license for more information.
from osgeo import gdal
Traceback (most recent call last):
File stdin, line 1, in module
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/osgeo/__init__.py,
line 21, in module
_gdal = swig_import_helper()
File
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/osgeo/__init__.py,
line 17, in swig_import_helper
_mod = imp.load_module('_gdal', fp, pathname, description)
ImportError:
dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/osgeo/_gdal.so,
2): Symbol not found: _locale_charset
Referenced from: /opt/local/lib/libspatialite.1.dylib
Expected in: flat namespace
in /opt/local/lib/libspatialite.1.dylib
I hope we will integrate the patches quickly into the mainstream so that you
can recompile it without to worry about overriding files here and there.
Have a nice week-end meanwhile
Vincent
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Can't import GDAL into Python (2.5 or 2.6)
Le 20 août 2010 à 16:42, Vincent Habchi a écrit : My own version works, as far as libspatialite is buggy: Indeed, with the bug in spatialite corrected, it works: PM: gdal2tiles.py --help Usage: gdal2tiles.py [options] input_file(s) [output] Options: --version show program's version number and exit -h, --helpshow this help message and exit -p PROFILE, --profile=PROFILE Tile cutting profile (mercator,geodetic,raster) - default 'mercator' (Google Maps compatible) -r RESAMPLING, --resampling=RESAMPLING Resampling method (average,near,bilinear,cubic,cubicsp line,lanczos,antialias) - default 'average' -s SRS, --s_srs=SRS The spatial reference system used for the source input data -z ZOOM, --zoom=ZOOM Zoom levels to render (format:'2-5' or '10'). -e, --resume Resume mode. Generate only missing files. -a NODATA, --srcnodata=NODATA NODATA transparency value to assign to the input data […] Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: PMA Errors
Hi! Le 19 août 2010 à 23:56, Brandon S Allbery KF8NH a écrit : [mress:~] allbery% grep !q /etc/passwd q: Event not found. [mress:~] allbery% grep !q /etc/passwd q: Event not found. [mress:~] allbery% grep '!q' /etc/passwd q: Event not found. [mress:~] allbery% Are you zapping histchars, like I usually do? (Admittedly, I haven't checked to see if OSX does it globally.) You're right with grep !q, the initial message was about grep q!… However, grep \!q seems to work fine. I would not put my hand in fire, though, as the French saying goes. Cheers, Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Next gcc46 Problem
Le 22 juil. 2010 à 07:55, Ryan Schmidt ryandes...@macports.org a écrit : I get the same as you. So either this is not how GCC is meant to be used (ask the developers of GCC how it's meant to be used) or there is a bug in GCC (ask the developers of GCC to fix it) or there is some alternate way we need to install GCC so it installs properly (ask the developers of GCC what we need to change in our packaging to make it work). That may prove difficult, since Darwin is not considered a prime target of GCC these days. Vincent Sent from my iPhone4 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: cputype problem on snow leopard
Salut ! ;) One last thing: it was not a migration, the computer came whith snow leopard... What's the output of: strings /usr/bin/lipo | grep x86_64 Bonne journée ! Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: cputype problem on snow leopard
Le 22 juil. 2010 à 11:16, Ryan Schmidt a écrit : On Jul 22, 2010, at 03:25, Anne Poupon wrote: sh-3.2# /usr/bin/lipo -info /usr/lib/libz.dylib Architectures in the fat file: /usr/lib/libz.dylib are: (cputype (16777223) cpusubtype (3)) i386 ppc7400 This confirms your lipo command is broken. Somehow, an older version of lipo than the one that shipped with Snow Leopard has been copied to /usr/bin/lipo. Replace it with a copy that came from Snow Leopard, either from your backups, or from the Mac OS X Snow Leopard DVD. It would also be interesting to know what is the output of: /usr/bin/lipo -info /usr/bin/lipo :) Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: cputype problem on snow leopard
Re- sh-3.2# /usr/bin/lipo -info /usr/bin/lipo Non-fat file: /usr/bin/lipo is architecture: ppc !!! On what model are you working? Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: cputype problem on snow leopard
Le 22 juil. 2010 à 11:36, Anne Poupon a écrit : 3.06 GHz intel core 2 duo ... Somehow, this is all wrong. You should have a two-way Intel universal lipo: PM: /usr/bin/lipo -info /usr/bin/lipo Architectures in the fat file: /usr/bin/lipo are: x86_64 i386 --- and Snow Leopard does not work with PPC, so you should not have any PPC binaries. What is the output of: uname -a? Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: cputype problem on snow leopard
Le 22 juil. 2010 à 11:53, Anne Poupon a écrit : sh-3.2# uname -a Darwin iMac-de-Pauline-Gloaguen.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 Well, beats me (comme disent les Anglais) ;) Somehow your binaries are messed up (SL n'aime pas les bretonnes ? :)). Have you tried lipo on some other /usr/bin/ binaries? Just to figure out if this flaw is limited to lipo or general. Bizarre… 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
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
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
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: NumPy, SciPy, universal builds, and default fortran compiler for scientific ports
Adam, Le 16 juin 2010 à 18:24, Adam Mercer a écrit : 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. […] 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)? I think two preliminary steps must be done before committing: - Further testing, especially on the new i7 machines: gcc43 seems to be incompatible, gcc45 seems to work, but gcc44 behavior is unknown to me at this time; - Maintainer's approval :) Cheers, Vincent PS : If gcc44 code is also incompatible with the i7 machines, we should maybe go a step further and adopt gcc45 for scientific packages… ___ 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
Adam I believe this i7 incompatiblity was the reason for ATLAS to use gcc44 instead of gcc43, but testing is important. I know that I systematically told the people that experienced bugs with Atlas on their i7 machine to use the newest possible gcc, that is gcc45, and it worked. But I am not aware of any owner of an i5/i7 machine trying with gcc44. But you're right, that's not really the subject here. gcc45 is still at 4.5.0, so if gcc45 is chosen it would probably be better waiting till at least 4.5.1. Seems perfectly sound. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: atlas depends on gcc43 *and* gcc44 ???
Le 2 juin 2010 à 23:13, Stephen Langer a écrit : I was wondering why anything depends on atlas at all. Is atlas noticeably better than the lapack and blas routines in the Accelerate framework? I couldn't find any comparisons on-line. I am unsure. But, as long as Apple does not state that its Blas and Lapack libraries are OpenCL based, in which case they may be hundred times quicker that CPU-thread-based Atlas, I am lead to believe that Atlas compiled with the latest gcc45 should be more efficient than Apple blas or lapack, most probably generated with gcc42 (the last GPL2 version) and backward-compatible with MacOS 10.4 or 10.5; Maybe they can get better efficiency with Clang/LLVM. However, I faintly remember comparing the Atlas built-in tests, and there was a clear gap between gcc43 and gcc44. It should not be very difficult to build up a test, like finding the eigenvalues of a random but symmetric definite positive matrix of great size (say : 50,000 x 50,000 or more) in Xcode, and link either with the built-in framework or our Atlas. Cheers Vincent PS : Does Apple provide scipy in its Python distribution? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Atlas universal portfile
Hi there, after much delay (due to the ongoing development of a Cocoa project), and many apologies, I have put at this address: ftp://ftp.cimaxonline.fr/Portfile-atlas-univ a portfile suitable to build a universal version of the atlas package. But do not expect miracles: 1. By universal I mean two-way universal: i386/x86-64 or ppc/ppc64 (the latter is untested). There is no way to build a full 4-way universal build; 2. To build the two-way universal version, you'll have to add the --enable-multilib option while building gcc. This is not done in any of the gccXX Portfiles, don't ask me why, I have requested it more than once. Building with multilib enabled works out of the box for gcc44 and gcc45, you just have to add the --enable-multilib to the configure.args variable (tested today on gcc45). The portfile allows you to choose between gcc43/gcc44 (default)/gcc45 by specifying an option. It should build one-way (tested on x86-64) and two-way binaries all right. The Portfile itself is reasonably well commented, but it uses a non-standard 2 spaces tab stop. Please let me know of any difficulty or bug. Have fun, Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Starting postgres84
Le 3 nov. 2009 à 19:09, Abram Gillespie a écrit : I'm getting this error in my log when I attempt to start postgres via /opt/local/lib/postgresql84/bin/pg_ctl sh: /opt/local/lib/postgresql83/bin/postgres: No such file or directory Is it possible 8.4 pg_ctl is compiled with old, 8.3 paths? Or is my system being probed for the path and I have old junk laying around that's confusing things? Normally, no, of course :) Look at the output of : strings /opt/local/lib/postgresql84/bin/pg_ctl You should get, at the end, postgresql84 hard coded paths. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: py26-numpy with veclib
Hi,
Is it possible to build py26-numpy against veclib with macports?
If linked against veclib the output should look like this:
numpy.show_config()
lapack_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-msse3']
define_macros = [('NO_ATLAS_INFO', 3)]
blas_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-msse3',
'-I/System/Library/Frameworks/vecLib.framework/Headers']
define_macros = [('NO_ATLAS_INFO', 3)]
My config shows this:
Python 2.6.3 (r263:75183, Oct 13 2009, 08:46:50)
[GCC 4.2.1 (Based on Apple Inc. build 5646) (LLVM build 2118)] on darwin
Type help, copyright, credits or license for more information.
import numpy
numpy.show_config ()
lapack_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-faltivec']
define_macros = [('NO_ATLAS_INFO', 3)]
blas_opt_info:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/
vecLib.framework/Headers']
define_macros = [('NO_ATLAS_INFO', 3)]
Note that I am on x86_64, so that looks a bit strange.
Vincent
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Why should I use macports?
Le 15 oct. 2009 à 17:28, Mikel King a écrit : Because there are thousands of readily available applications only a 'port install' away. Say you want to install lighttpd + PHP + MySql to host I could add that the advantage of compiling instead of just downloading and adding binaries is that you can tweak your compilation to suit exactly the kind of processor you have (or other needs), resulting in a much more optimized code (in order to run in all platforms, binary code is inherently compiled for old CPU models). The drawback, of course, is increased installation time. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Python26 again
Perry, you mean that under the directory /opt/local/Library/Frameworks/Python.framework you have only one entry, the subdirectory: Versions Right ? V. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Upgrading to Snow Leopard makes my programs no longer link to ports
Le 9 sept. 2009 à 22:11, Ryan Schmidt a écrit : lipo -info should be able to tell you what architecture libfreeimage.dylib is. file(1) does it also and requires less typing :) V. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: OSX Upgrades: Snow Leopard
Le 9 juin 09 à 14:32, Kurt Hillig a écrit : On the other hand I recently upgraded from 10.4 to 10.5 and my machine was horribly unstable until I blew away the MacPorts install. I'm not sure why this was, and I didn't have the time or gumption to run a lot of diagnostics, so it could well be that something less drastic would have sufficed. When you upgrade, the libraries change, so you may have to recompile some of your bricks. For example, when SL will be out, we'll have, at least, a 64-bit API to QuickTime, so we'll be able to compile WxWindows safely in 64-bit mode. But maybe also the old AGL will vanished, and all ports that are based on it will have to be rebuild, etc. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: MacPorts on Snow Leopard
(repost) Hello, Le 9 juin 09 à 15:57, Jean-Denis Muys a écrit : PS: I don't think this request does or most answers would violate the NDA, but I'm ready to move this conversation to private mail and/or to the Apple developer forums. Actually, now that I mention it, I will cross post this request over there :-) I am wondering how many macports developers out there have access to Snow L. Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Tweaking a Portfile
Ryan, You may want to consider splitting the port into two ports, one for the backend and one for the frontend, so that you can handle their universality separately. Of course you're right, that's the easiest path. I was hoping to be able to follow a steeper way, without having to split, which is going to be also a pain, since the package is bundled in one piece with recursive calls to configures in subdirectories. Thanks for the help though Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Tweaking a Portfile
Hi there,
hopefully I'm out of the tunnel and I can manage to work on some ports
again.
Specifically, I'm trying to improve the science/qucs port by enabling
a universal build.
Qucs is built in two parts: a front end that cannot be universal
because it links against Qt3, itself dependant on Carbon ; a back end
composed of a mathematical core that can and should be compiled in 64-
bit mode in order to improve performance.
So I have to configure one subdirectory with standard flags, even if
the universal variant is set, and I have to revert to normal universal
configuration in the second subdirectory. Is there an easy way to do
this?
I tried this piece of code:
pre-configure {
# We must configure QUCS in 32-bit mode because of QT3 dependency
# then we go back to qucs-core that we configure universal
if {[variant_isset universal]} then {
set cua ${configure.universal_args}
set cuc ${configure.universal_cflags}
set cucpp ${configure.universal_cppflags}
set cucxx ${configure.universal_cxxflags}
set culd${configure.universal_ldflags}
unset {configure.universal_args}
unset {configure.universal_cflags}
unset {configure.universal_cppflags}
unset {configure.universal_cxxflags}
unset {configure.universal_ldflags}
}
}
But it does not seem to work, since the environnement variables seem
to be computed before the pre-conf phase (and configure runs with the
universal flags). If I substitute pre-configure by configure, of
course nothing happens anymore.
Any easy way to get out of this maze?
Thanks,
Vincent
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
