php53 ipv6 and file_get_contents getaddrinfo failed
New to the listserv and sorry if this is an old issue that I couldn't find an answer to via Google. I've been running an older OSX 10.6 (Snow Leopard) XServe server for some time. It's an older Mac that can't be updated further. I have MacPorts running on it, but until recently I was using the MacPorts PHP53 with Apple's built-in apache2 by including LoadModule php5_module/opt/local/apache2/modules/mod_php53.so in /etc/apache2/httpd.conf Recently my campus security people wanted me to update the apache version being run on this server, so I inactivated the apple apache2 and restarted using the MacPorts version. Suddenly I started getting this error in my apache error logs: file_get_contents(): php_network_getaddresses: getaddrinfo failed: nodename nor servname provided, or not known in... Googling this, there were a number of suggestions that this is an ipV6 problem, and indeed, if I inactivate ipv6 using ip6 -x and then restart apache (using stop and start) the functionality that uses file_get_contents starts working again. But once or twice per day, something breaks it again and I have to stop and start apache2 again. I don't understand why this would be an apache issue, but I think I've seen this for over a year because the reason I was running Apple's built in apache up until now, despite using MacPorts PHP is that certain functionalities on my site stopped working when I previously tried to switch to MacPorts apache2. I'm not even sure if ipv6 is the real problem, or whether the apache stop and start was what was providing the fix. Since this doesn't seem to be a problem for others, I suspect that there is a configuration problem on my server of some kind. But I can't figure out what it is. Any suggestions would be welcome. Thanks! Jim Hu ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Port install fails for curl, requires gcc4.2
20+ hrs later, DONE! No swapping that I could see. I just never imagined that it would take that long! My apologies for not digging deeper the first time! Now, let's see how long wireshark takes! Thank you very much for your help, Tom On Mar 3, 2015, at 15:40, t...@qx.net wrote: On Mar 3, 2015, at 2:11 PM, t...@qx.net wrote: Ryan Schmidt wrote: On Mar 3, 2015, at 11:01 AM, Tom Emmert wrote: Running OS X 10.4.11 on a PowerBook G3. To my knowledge Xcode 2.5, gcc4.0.1, is the last version that will work on my system. Mac port 2.3.3 installed ok. I also noticed that my next mac port install, wireshark, also requires gcc4.2. Any hope for a work around? Tom, Most ports on Tiger will use the MacPorts version of Apple GCC 4.2.1 -- it is the default compiler on Tiger -- because the version of Apple GCC 4.0.1 included in Tiger's Xcode is considered old and problematic by now. This should all work. What actual error message are you receiving? Thanks Ryan, the following is the verbose terminal output to the point the install hung. I waited a long time before cntl-c. ppc:~ me$ sudo port -v install curl Password: --- Computing dependencies for curl --- Dependencies to be installed: apple-gcc42 curl-ca-bundle perl5 perl5.16 gdbm gettext expat libiconv gperf ncurses libidn openssl zlib xz pkgconfig --- Building apple-gcc42 make: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/gcc-5666.3' cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/objroot \ /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/gcc-5666.3/build_gcc ppc ppc \ /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/gcc-5666.3 /opt/local /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/destroot /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/symroot + TRANSLATE_ARCH=sed -e s/ppc/powerpc/ -e s/i386/i686/ -e s/armv6/arm/ + OMIT_X86_64=sed -e s/x86_64// ++ echo ppc ++ sed -e s/ppc/powerpc/ -e s/i386/i686/ -e s/armv6/arm/ + HOSTS=powerpc ++ echo ppc ++ sed -e s/ppc/powerpc/ -e s/i386/i686/ -e s/armv6/arm/ ++ sed -e s/x86_64// + TARGETS=powerpc + BOOTSTRAP=bootstrap + '[' bootstrap '!=' bootstrap ']' + LANGUAGES=c,c++,objc,obj-c++ + CFLAGS=-g -O2 -std=gnu89 ++ echo ppc ++ sed -e s/ppc/powerpc/ -e s/i386/i686/ -e s/armv6/arm/ + BUILD=powerpc + ORIG_SRC_DIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/gcc-5666.3 + DEST_ROOT=/opt/local + DEST_DIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/destroot + SYM_DIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/symroot ++ pwd + DIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/objroot ++ cat /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/gcc-5666.3/gcc/BASE-VER + VERS=4.2.1 + '[' -z 4.2.1 ']' ++ echo 4.2.1 ++ sed 's/\([0-9]*\.[0-9]*\)[.-].*/\1/' + MAJ_VERS=4.2 + LIBSTDCXX_VERSION=4.2.1 + '[' '!' -d /usr/include/c++/4.2.1 ']' + LIBSTDCXX_VERSION=4.0.0 + NON_ARM_CONFIGFLAGS=--with-gxx-include-dir=/usr/include/c++/4.0.0 + PPC_SYSROOT=/ + PPC_CONFIGFLAGS=--with-gxx-include-dir=/usr/include/c++/4.0.0 --with-build-sysroot=/ ++ uname -r ++ sed 's/\..*//' + DARWIN_VERS=8 + echo DARWIN_VERS = 8 DARWIN_VERS = 8 + ARM_LIBSTDCXX_VERSION=4.2.1 + ARM_CONFIGFLAGS=--with-gxx-include-dir=/usr/include/c++/4.2.1 + '[' -n '' ']' + '[' x = xiPhone ']' + '[' -d /Developer/SDKs/Extra ']' + ARM_SYSROOT=/ + ARM_TOOLROOT=/ + ARM_CONFIGFLAGS=--with-gxx-include-dir=/usr/include/c++/4.2.1 --with-build-sysroot=/ + echo powerpc + grep arm + RANLIB=ranlib + STRIP=strip + DSYMUTIL=dsymutil + SRC_DIR=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src + rm -rf /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src + mkdir
Re: Port install fails for curl, requires gcc4.2
On Wed, Mar 4, 2015 at 12:29 PM, Tom Emmert t...@qx.net wrote: 20+ hrs later, DONE! No swapping that I could see. I just never imagined that it would take that long! My apologies for not digging deeper the first time! Now, let's see how long wireshark takes! Thank you very much for your help, Tom If you're building it with the GUI, expect it to drag in half of GNOME and take forever . -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Selfupdate doesn't work - solved
On Wed, 4 Mar 2015, Jim Goudie wrote: Then I got to thinking... what else would block it? I logged in to my router and found it has a firewall as well. I turned it off, and then the command worked! I'm finding that a lot of consumer routers have conservative firewalls by default; this is good. Think of it as a form of natural selection; if you know enough to turn it off or reconfigure it etc, then you probably aren't a danger to the Internet :-) -- Dave Horsfall DTM (VK2KFU) Bliss is a MacBook with a FreeBSD server. http://www.horsfall.org/spam.html (and check the home page whilst you're there) ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
error while building uhd
Hello... I was installing Gqrx, a software-defined radio program. The install took much longer than I expected, but then this is my first experience with Macports... I didn't know what to expect. When it finally stopped, it ended with an error while building uhd (see below). Any help understanding this and what to do next? I'm very new with all of this... Thanks, Jim --- Fetching distfiles for uhd --- Attempting to fetch uhd-003_008_002.tar.gz from https://github.com/EttusResearch/uhd/tarball/release_003_008_002 --- Verifying checksums for uhd --- Extracting uhd --- Configuring uhd --- Building uhd Error: org.macports.build for port uhd returned: command execution failed Error: Failed to install uhd Please see the log file for port uhd for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/main.log Error: The following dependencies were not installed: gnuradio uhd xmlto findutils getopt gr-osmosdr airspy bladeRF tecla git p5.16-authen-sasl p5.16-digest-hmac p5.16-digest-sha1 p5.16-gssapi p5.16-error p5.16-net-smtp-ssl p5.16-term-readkey rsync popt gr-fcdproplus hackrf rtl-sdr To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port Gqrx failed I tried running the install again, and then looked at the log file: Last login: Wed Mar 4 16:51:29 on ttys000 Office:~ Jim$ sudo port install Gqrx Password: --- Computing dependencies for gqrx --- Dependencies to be installed: gnuradio uhd xmlto findutils getopt gr-osmosdr airspy bladeRF tecla git p5.16-authen-sasl p5.16-digest-hmac p5.16-digest-sha1 p5.16-gssapi p5.16-error p5.16-net-smtp-ssl p5.16-term-readkey rsync popt gr-fcdproplus hackrf rtl-sdr --- Building uhd Error: org.macports.build for port uhd returned: command execution failed Error: Failed to install uhd Please see the log file for port uhd for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/main.log Error: The following dependencies were not installed: gnuradio uhd xmlto findutils getopt gr-osmosdr airspy bladeRF tecla git p5.16-authen-sasl p5.16-digest-hmac p5.16-digest-sha1 p5.16-gssapi p5.16-error p5.16-net-smtp-ssl p5.16-term-readkey rsync popt gr-fcdproplus hackrf rtl-sdr To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port Gqrx failed Office:~ Jim$ Office:~ Jim$ Office:~ Jim$ vim /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/main.log :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:11: error: integer constant is too large for ‘long’ type :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:11: error: integer constant is too large for ‘long’ type :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:11: error: integer constant is too large for ‘long’ type :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:12: error: integer constant is too large for ‘long’ type :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:12: error: integer constant is too large for ‘long’ type :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:12: error: integer constant is too large for ‘long’ type :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:12: error: integer constant is too large for ‘long’ type :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:13: error: integer constant is too large for ‘long’ type :info:build
Re: Port install fails for curl, requires gcc4.2
On March 4, 2015 7:04:04 PM EST, Ryan Schmidt ryandes...@macports.org wrote: On Mar 4, 2015, at 11:29 AM, Tom Emmert wrote: 20+ hrs later, DONE! No swapping that I could see. I just never imagined that it would take that long! My apologies for not digging deeper the first time! Now, let's see how long wireshark takes! Thank you very much for your help, Tom Great, glad it worked. 1 GB RAM should be ok for compiling most ports; my PowerPC test machine has only 512 MB. But your 500 MHz processor is slow. It may be the fastest G3 Apple shipped, but it's still much slower than my 1.67 GHz G4. And when I do updates on mine, I typically set them to go at night and check on them in the morning. Compiling compilers is one of the slowest tasks though. Most ports should build much quicker. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users Apple employee indicates an iBook had a 900mhz g3 (2003l. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: error while building uhd
On 2015-03-04 23:09, Jim Goudie wrote: Office:~ Jim$ vim /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/main.log :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:11: error: integer constant is too large for ‘long’ type On which version of OS X are you building this? (`sw_vers`) Which version of Xcode? (`xcodebuild -version`) Is this a 32-bit machine? I guess the constants in this file would need to be declared with a '.0' suffix for double. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Port install fails for curl, requires gcc4.2
On Mar 4, 2015, at 6:34 PM, Jeremy Lavergne wrote: On March 4, 2015 7:04:04 PM EST, Ryan Schmidt wrote: Great, glad it worked. 1 GB RAM should be ok for compiling most ports; my PowerPC test machine has only 512 MB. But your 500 MHz processor is slow. It may be the fastest G3 Apple shipped, but it's still much slower than my 1.67 GHz G4. And when I do updates on mine, I typically set them to go at night and check on them in the morning. Compiling compilers is one of the slowest tasks though. Most ports should build much quicker. Apple employee indicates an iBook had a 900mhz g3 (2003l. Oh right, I forgot iBooks still used the G3 for awhile after PowerBooks switched to the G4. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Port install fails for curl, requires gcc4.2
On Mar 4, 2015, at 11:29 AM, Tom Emmert wrote: 20+ hrs later, DONE! No swapping that I could see. I just never imagined that it would take that long! My apologies for not digging deeper the first time! Now, let's see how long wireshark takes! Thank you very much for your help, Tom Great, glad it worked. 1 GB RAM should be ok for compiling most ports; my PowerPC test machine has only 512 MB. But your 500 MHz processor is slow. It may be the fastest G3 Apple shipped, but it's still much slower than my 1.67 GHz G4. And when I do updates on mine, I typically set them to go at night and check on them in the morning. Compiling compilers is one of the slowest tasks though. Most ports should build much quicker. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: error while building uhd
Hi Jim - I'm going to work with you off-list since this is a 32/64 bit issue will require some programming work on my part and testing on your part. If we come up with something relevant to this list, I'll email a summary. - MLD On Wed, Mar 4, 2015, at 06:27 PM, Jim Goudie wrote: OS X 10.6.8 Xcode 3.2 (I haven't found an upgrade for this, yet... 3.2.6?) Yes... it is a 32-bit Macbook Pro, 2 Ghz Intel Core Duo; 2 GB ram ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: php53 ipv6 and file_get_contents getaddrinfo failed
On Mar 4, 2015, at 9:48 AM, Jim Hu wrote: New to the listserv and sorry if this is an old issue that I couldn't find an answer to via Google. I've been running an older OSX 10.6 (Snow Leopard) XServe server for some time. It's an older Mac that can't be updated further. I have MacPorts running on it, but until recently I was using the MacPorts PHP53 with Apple's built-in apache2 by including LoadModule php5_module/opt/local/apache2/modules/mod_php53.so in /etc/apache2/httpd.conf Recently my campus security people wanted me to update the apache version being run on this server, so I inactivated the apple apache2 and restarted using the MacPorts version. Suddenly I started getting this error in my apache error logs: file_get_contents(): php_network_getaddresses: getaddrinfo failed: nodename nor servname provided, or not known in... Googling this, there were a number of suggestions that this is an ipV6 problem, and indeed, if I inactivate ipv6 using ip6 -x and then restart apache (using stop and start) the functionality that uses file_get_contents starts working again. But once or twice per day, something breaks it again and I have to stop and start apache2 again. I don't understand why this would be an apache issue, but I think I've seen this for over a year because the reason I was running Apple's built in apache up until now, despite using MacPorts PHP is that certain functionalities on my site stopped working when I previously tried to switch to MacPorts apache2. I'm not even sure if ipv6 is the real problem, or whether the apache stop and start was what was providing the fix. Since this doesn't seem to be a problem for others, I suspect that there is a configuration problem on my server of some kind. But I can't figure out what it is. Any suggestions would be welcome. I haven't run into this, but I don't do much PHP programming anymore. All I can suggest is that, since PHP 5.3 is at end of life, you try a newer version of PHP. We have php54, php55 and php56 in MacPorts as well. Of course you may need to change your project's code to be compatible with these versions. There are guides on the PHP web site for how to do that, links to which are printed by running port notes php53. If you suspect this is related to using Apache, you could also consider trying a different web server, such as nginx which I understand is very popular. Under such a web server, you would no longer be using the PHP Apache SAPI (in the php*-apache2handler ports), but instead the PHP FastCGI Process Manager SAPI (in the php*-fpm ports). ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: php53 ipv6 and file_get_contents getaddrinfo failed
On March 4, 2015 8:22:01 PM EST, Ryan Schmidt ryandes...@macports.org wrote: On Mar 4, 2015, at 9:48 AM, Jim Hu wrote: New to the listserv and sorry if this is an old issue that I couldn't find an answer to via Google. I've been running an older OSX 10.6 (Snow Leopard) XServe server for some time. It's an older Mac that can't be updated further. I have MacPorts running on it, but until recently I was using the MacPorts PHP53 with Apple's built-in apache2 by including LoadModule php5_module /opt/local/apache2/modules/mod_php53.so in /etc/apache2/httpd.conf Recently my campus security people wanted me to update the apache version being run on this server, so I inactivated the apple apache2 and restarted using the MacPorts version. Suddenly I started getting this error in my apache error logs: file_get_contents(): php_network_getaddresses: getaddrinfo failed: nodename nor servname provided, or not known in... Googling this, there were a number of suggestions that this is an ipV6 problem, and indeed, if I inactivate ipv6 using ip6 -x and then restart apache (using stop and start) the functionality that uses file_get_contents starts working again. But once or twice per day, something breaks it again and I have to stop and start apache2 again. I don't understand why this would be an apache issue, but I think I've seen this for over a year because the reason I was running Apple's built in apache up until now, despite using MacPorts PHP is that certain functionalities on my site stopped working when I previously tried to switch to MacPorts apache2. I'm not even sure if ipv6 is the real problem, or whether the apache stop and start was what was providing the fix. Since this doesn't seem to be a problem for others, I suspect that there is a configuration problem on my server of some kind. But I can't figure out what it is. Any suggestions would be welcome. I haven't run into this, but I don't do much PHP programming anymore. All I can suggest is that, since PHP 5.3 is at end of life, you try a newer version of PHP. We have php54, php55 and php56 in MacPorts as well. Of course you may need to change your project's code to be compatible with these versions. There are guides on the PHP web site for how to do that, links to which are printed by running port notes php53. If you suspect this is related to using Apache, you could also consider trying a different web server, such as nginx which I understand is very popular. Under such a web server, you would no longer be using the PHP Apache SAPI (in the php*-apache2handler ports), but instead the PHP FastCGI Process Manager SAPI (in the php*-fpm ports). ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users You should use php fpm regardless of the web server. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: [poll]: has anyone built port:qt5-mac in universal or 32bit mode?
On Mar 4, 2015, at 7:45 AM, René J.V. Bertin wrote: The question is all in the subject: has anyone built port:qt5-mac in universal or 32bit mode, and if so, what Qt version is/was that? I'm most interested in success stories, though confirmation that it doesn't work would be of interest too. Yes! $ port -v installed qt5-mac The following ports are currently installed: qt5-mac @5.3.2_1+universal (active) platform='darwin 14' archs='i386 x86_64' ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: error while building uhd
Hello Rainer, OS X 10.6.8 Xcode 3.2 (I haven't found an upgrade for this, yet... 3.2.6?) Yes... it is a 32-bit Macbook Pro, 2 Ghz Intel Core Duo; 2 GB ram Jim On Mar 4, 2015, at 6:07 PM, Rainer Müller wrote: On 2015-03-04 23:09, Jim Goudie wrote: Office:~ Jim$ vim /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/main.log :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_uhd/uhd/work/uhd-003_008_002/host/lib/usrp/common/ad9361_driver/ad9361_synth_lut.h:11: error: integer constant is too large for ‘long’ type On which version of OS X are you building this? (`sw_vers`) Which version of Xcode? (`xcodebuild -version`) Is this a 32-bit machine? I guess the constants in this file would need to be declared with a '.0' suffix for double. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Selfupdate doesn't work - solved
Hello... I tried running this command with the OS X firewall off: rsync rsync://rsync.macports.org/release/ It timed out as usual. Then I got to thinking... what else would block it? I logged in to my router and found it has a firewall as well. I turned it off, and then the command worked! After experimenting with the router's firewall settings, 'selfupdate' worked! My biggest problem was forgetting that there was a second firewall! Thanks for all the help I received; it helped me think more clearly... Jim ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
[poll]: has anyone built port:qt5-mac in universal or 32bit mode?
Hello, The question is all in the subject: has anyone built port:qt5-mac in universal or 32bit mode, and if so, what Qt version is/was that? I'm most interested in success stories, though confirmation that it doesn't work would be of interest too. Thanks, René ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
Re: Problem configuring libcaca
I’m on Yosemite. I always do a “sudo port -v selfupdate” followed by “sudo port -v upgrade outdated”. I just did a “sudo port clean libcaca” and started it again. It is again hanging up at the same place (though it has only been hung for a few minutes - I’ll let it go and see if it gets any further). Tom On Mar 3, 2015, at 11:19 PM, Ryan Schmidt ryandes...@macports.org wrote: On Mar 3, 2015, at 8:28 PM, Tom Gederberg wrote: Yesterday and today I tried upgrading MacPorts and both days it stopped at the same location (/opt/local/bin/glibtooize). I let it go for over 24 hours but nothing happens. Any ideas. $ sudo port -v upgrade outdated Password: --- Computing dependencies for libcaca. --- Configuring libcaca autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: /opt/local/bin/aclocal --force autoreconf: configure.ac: tracing autoreconf: running: /opt/local/bin/glibtoolize --copy --force This wasn't a clean attempt. Always clean and try again when you encounter a problem; it may fix the problem: sudo port clean libcaca If that doesn't help, what system are you on? The port builds fine for me on Yosemite. I did commit a couple fixes to this port last week. Make sure you've run sudo port selfupdate since then so that you have those fixes. ___ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
