Re: clamav and bzip2
Having performed software update a number of times what else must I do? Is a later Xcode archived? From: http://guide.macports.org/#installing.xcode Always make sure to install the latest available version of Xcode for your Mac OS X release (with the exception of Xcode 4.3, for now); using outdated versions of Xcode may cause port install failures. Also note that Xcode is not updated via Mac OS X's Software Update utility on OS versions prior to 10.6, and is updated via the Mac App Store on 10.7. You can find all Xcode downloads through connect.apple.com. smime.p7s Description: S/MIME cryptographic signature ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: clamav and bzip2
On Feb 22, 2012, at 10:11 AM, John Brown wrote: Error: On Mac OS X 10.4, zlib 1.2.6 requires Xcode 2.4.1 or later but you have Xcode 2.3. Error: See http://guide.macports.org/chunked/installing.xcode.html for download links. Error: Target org.macports.extract returned: incompatible Xcode version Error: Failed to install zlib Did you follow that link? The guide has a link specifically for you to get the latest Xcode for 10.4 (guide section 2.2.3) -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: clamav and bzip2
Daniel J. Luke wrote: On Feb 22, 2012, at 2:29 AM, John Brown wrote: Warning: The installed version of Xcode (2.3) is known to cause problems. Version 2.5 or later is recommended on Mac OS X 10.4. this warning is printed for a reason, you should upgrade Xcode. --- Verifying checksum(s) for bzip2 Error: Checksum (md5) mismatch for bzip2-1.0.6.tar.gz Error: Checksum (sha1) mismatch for bzip2-1.0.6.tar.gz Error: Checksum (rmd160) mismatch for bzip2-1.0.6.tar.gz *** The non-matching file appears to be HTML. See this page for possible reasons for the checksum mismatch: https://trac.macports.org/wiki/MisbehavingServers *** This message is also printed for a reason, did you follow that link and read what was there? -- Daniel J. Luke ++ | * dl...@geeklair.net * | | *-- http://www.geeklair.net -* | ++ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | ++ Yes, I followed the link. Shalom, John B Brown j...@vcn.com 358 High Street Buffalo, Wyoming 82834 Freedom is not worth having if it does not include the freedom to make mistakes Mahatma Gandhi There was never a good war, or a bad peace. Benjamin Franklin I wonder whether the world is being run by smart people who are putting us on or by imbeciles who really mean it. Mark Twain 1-307-684-9068 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: problem to install apr-util in OSX 10.8?
On Feb 22, 2012, at 10:08, Giovanni Lovato wrote: Jeremy Lavergne wrote: Log for apr-util is at: /opt/local/var/macports/logs/.../apr-util/main.log We cannot help you without this log file. I have the same issue with OS X 10.8, XCode 4.4, fresh MP trunk install: Most of us do not have the pre-releases of OS X 10.8 or Xcode 4.4, and you may be prohibited from discussing it publicly due to your non-disclosure agreement. building apr-util fails on :info:build /bin/sh /opt/local/share/apr-1/build/libtool --silent --mode=link /usr/bin/clang -pipe -O2 -arch x86_64 -L/opt/local/lib -arch x86_64 -L/opt/local/lib/db46 -L/opt/local/lib -release 1 -module -rpath /opt/local/lib/apr-util-1 -o dbd/apr_dbd_sqlite3.la dbd/apr_dbd_sqlite3.lo -L/opt/local/lib -lsqlite3 :info:build clang: error: unable to execute command: Segmentation fault: 11 :info:build clang: error: linker command failed due to signal 2 (use -v to see invocation) Here's the full log: http://pastebin.com/0fMbwTSP The full error message reads: :info:build clang: error: unable to execute command: Segmentation fault: 11 :info:build clang: error: linker command failed due to signal 2 (use -v to see invocation) :info:build clang: note: diagnostic msg: Please submit a bug report to http://developer.apple.com/bugreporter/ and include command line arguments and all diagnostic information. :info:build clang: note: diagnostic msg: Error generating preprocessed source(s) - cannot generate preprocessed source with multiple -arch options. So please do that. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Help please
On Feb 21, 2012, at 22:44, James Linder wrote:
checking for Apple Objective-C runtime... yes
checking for GNU Objective C runtime... no
configure: Using Apple Objective-C runtime
checking for Apple Foundation library... no
configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your
environment, preventing the use of GNUstep's Foundation library
configure: error: Could not find a working Foundation implementation
This is an error we've encountered a few times before, such as:
https://trac.macports.org/ticket/28452
https://trac.macports.org/ticket/30298
We didn't receive further feedback from the reporters so were unable to
pursue the matter further. Can you attach your config.log? Maybe it will
shed further light.
In #28452 we presumed software installed in /usr/local was interfering. Do
you have anything installed in /usr/local? If so, remove it and try again.
In #30298 we presumed the user's operating system components had become
damaged and the OS should be reinstalled. So that's another avenue you
could pursue.
haycorn:~ # ls /usr/local
.git Library etc share
.gitignore README.md include texlive
Cellar bin lib
This was put here by latex install ...
haycorn:~ # mv /usr/local/ /usr/oldlocal
haycorn:~ # port -d selfupdate
[snip]
Error: /opt/local/bin/port: port selfupdate failed: Error installing new
MacPorts base: shell command failed (see log for details)
OK it'll take me a day or so to backup everything I want, so reinstall
(which will certainly work, it did work before) and I'll report back
Snow Leopard and install CD: Insert CD 'Instal Mac OS X': whirr whirr (1
hour) {but this way is very easy)
then
...
DEBUG: Error installing new MacPorts base: shell command failed (see log for
details)
while executing
macports::selfupdate [array get global_options] base_updated
Error: /opt/local/bin/port: port selfupdate failed: Error installing new
MacPorts base: shell command failed (see log for details)
That portion of the error doesn't tell us anything other than something went
wrong. If you check back further in the log, was it the same Could not find a
working Foundation implementation error?
OK next I'll format the disk then install and report
I would not have suggested that as the next step, but then again I have no
further suggestions, so if you do this, let us know if it helps.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gcc et al without XCode
On Feb 21, 2012, at 11:08, Craig Treleaven wrote: Haven't tried it, but Apple has released a new package that installs Apple's tools and SDK's without having to download and install the full XCode app. http://www.kennethreitz.com/xcode-gcc-and-homebrew.html Yes they have. But as always, MacPorts will require both those and Xcode; we're not changing that. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Still no Universal variant for NSS?
On Feb 21, 2012, at 12:38, Greg Earle wrote: I wanted to update WINE-devel via MacPorts but was told my ports were out of date when I ran sudo port update wine-devel. I've migrated my system from a 32-bit (only) old MacBook Pro to a present-model Mac Pro running in full 64-bit mode. When I ran sudo port selfupdate it converted me from 1.9.2 to 2.0.3. (Oops) Why oops? That's what selfupdate is supposed to do -- update MacPorts base to the latest version, and update your portfile definitions. MacPorts 2 was released a long time ago. In the future, please do not wait so long to selfupdate. I soon had problems with programs crashing so I said the heck with it and reinstalled 2.0.3 from DMG. Indeed; the migration instructions state that you must reinstall MacPorts and all ports when you migrate to a new machine with a different OS version or processor architecture. I then decided to try the sudo port -qv installed /tmp/installed_ports.txt sudo port -fp uninstall --follow-dependents installed sudo port clean all curl -O http://svn.macports.org/repository/macports/contrib/restore_ports/restore_ports.tcl chmod +x restore_ports.tcl sudo ./restore_ports.tcl /tmp/installed_ports.txt method described in the migration FAQ. Right, that should reinstall all your ports. It was humming along quite nicely until it got to xulrunner: -- [...] --- Activating libcanberra @0.28_0+universal --- Cleaning libcanberra Error: Cannot install xulrunner for the arch(s) 'i386' because Error: its dependency nss is only installed for the arch 'x86_64' Error: and does not have a universal variant. architecture mismatch while executing macports::_upgrade_mport_deps $mport $target (procedure mportexec line 33) invoked from within mportexec $workername $install_target Unable to execute target 'install' for port 'xulrunner': architecture mismatch while executing install_ports $operationList (file ./restore_ports.tcl line 269) [21:39] nightowl:/tmp % sudo port installed nss Password: The following ports are currently installed: nss @3.13.1_0 (active) [21:47] nightowl:/tmp % lipo -info /opt/local/lib/nss/libnss3.dylib Non-fat file: /opt/local/lib/nss/libnss3.dylib is architecture: x86_64 [21:47] nightowl:/tmp % grep firefox /tmp/installed_ports firefox-x11 @3.6.13_0 platform='darwin 10' archs='i386' firefox-x11 @3.6.15_0 platform='darwin 10' archs='i386' firefox-x11 @3.6.16_0 (active) platform='darwin 10' archs='i386' [21:48] nightowl:/tmp % sudo port installed firefox None of the specified ports are installed. [21:48] nightowl:/tmp % sudo port installed firefox-x11 None of the specified ports are installed. [21:48] nightowl:/tmp % sudo port installed firefox-x11-devel None of the specified ports are installed. -- This looks suspiciously like Ticket #23424 - nss: add universal variant and support for build_arch https://trac.macports.org/ticket/23424 which looks like a 2-year-old ticket that has had no fix/movement on in well over a year. Am I hosed? Should I try 'cheating' and change the firefox-x11 to firefox-x11-devel in my installed_ports.txt file and run it again? The current version of the firefox-x11 port does not appear to have a dependency on nss or xulrunner so try removing those from your installed_ports.txt. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
error using MacPorts zlib, not present with system zlib?
Hi
Not sure of the correct place to discuss this but in tracking down a
build issue with a port I've found an interesting issue with MacPorts
zlib.
This simple test code illustrates the problem:
[ram@mimir tmp]$ cat test.c
#include stdio.h
#include stdlib.h
#include zlib.h
int main(void)
{
void *file;
int c;
file = gzopen(test.dat.gz, r);
if (file == Z_NULL)
{
fprintf(stderr, unable to open file\n);
exit(1);
}
c = gzgetc(file);
fprintf(stdout, c = %c\n, c);
gzclose(file);
}
[ram@mimir tmp]$ zcat test.dat.gz
test
file
If I compile this against the system zlib then it works as expected:
[ram@mimir tmp]$ clang -o test test.c -lz
[ram@mimir tmp]$ ./test
c = t
But not against the MacPorts zlib:
[ram@mimir tmp]$ clang -o test test.c -I/opt/local/include -L/opt/local/lib -lz
test.c:17:7: error: member reference base type 'void' is not a structure or
union
c = gzgetc(file);
^~~~
/opt/local/include/zlib.h:1655:11: note: instantiated from:
((g)-have ? ((g)-have--, (g)-pos++, *((g)-next)++) : gzgetc_(g))
~~~ ^
test.c:17:7: error: member reference base type 'void' is not a structure or
union
c = gzgetc(file);
^~~~
/opt/local/include/zlib.h:1655:24: note: instantiated from:
((g)-have ? ((g)-have--, (g)-pos++, *((g)-next)++) : gzgetc_(g))
~~~ ^
test.c:17:7: error: member reference base type 'void' is not a structure or
union
c = gzgetc(file);
^~~~
/opt/local/include/zlib.h:1655:37: note: instantiated from:
((g)-have ? ((g)-have--, (g)-pos++, *((g)-next)++) : gzgetc_(g))
~~~ ^
test.c:17:7: error: member reference base type 'void' is not a structure or
union
c = gzgetc(file);
^~~~
/opt/local/include/zlib.h:1655:51: note: instantiated from:
((g)-have ? ((g)-have--, (g)-pos++, *((g)-next)++) : gzgetc_(g))
~~~ ^
4 errors generated.
[ram@mimir tmp]$
Does anyone know why MacPorts zlib treats this as an error but the
system version doesn't?
Cheers
Adam
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: error using MacPorts zlib, not present with system zlib?
On 22.02.2012 15:32, Adam Mercer wrote:
Hi
Not sure of the correct place to discuss this but in tracking down a
build issue with a port I've found an interesting issue with MacPorts
zlib.
This simple test code illustrates the problem:
[ram@mimir tmp]$ cat test.c
#include stdio.h
#include stdlib.h
#include zlib.h
int main(void)
{
void *file;
snip
c = gzgetc(file);
This code is wrong. The zlib documentation says gzgetc takes a gzFile*
not a void*.
Does anyone know why MacPorts zlib treats this as an error but the
system version doesn't?
I'm not near a Mac right now, but I believe the system version of zlib
is pretty ancient. In version 1.2.4 there was a Wholesale replacement
of gz* functions with faster versions according to zlib.net, one of
which I suspect was the replacement of the gzgetc() function with a
macro.
C treats void* very unsafely, silently converting it to and from other
pointer types whenever it knows how. So converting the gzFile* gzopen()
returned to the void* 'file' is legal. Then, if gzgetc() is an actual
function declared as 'char gzgetc(gzFile*)' the compiler will allow the
void* be passed to the function, and within the function it is treated
as a gzFile*. But if gzgetc is just a macro the compiler doesn't know
to convert 'file' to a gzFile*, so you get errors about trying to treat
void as struct/union. If the API said gzgetc took a void* they would
fix this by casting g to a gzFile* inside the macro that replaced the
function, but the API doesn't say this, and so the zlib authors don't...
The current version is actually both faster and safer since it catches
this type of void* abuse.
So tldr answer: patch the port using libz to use a gzFile* or to cast
the void* gack to a gzFile* before calling functions expecting a
gzFile*.
Thanks,
Eric
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: error using MacPorts zlib, not present with system zlib?
On Wed, Feb 22, 2012 at 15:50, Eric Cronin ecro...@macports.org wrote: I'm not near a Mac right now, but I believe the system version of zlib is pretty ancient. In version 1.2.4 there was a Wholesale replacement of gz* functions with faster versions according to zlib.net, one of which I suspect was the replacement of the gzgetc() function with a macro. Looks like it, Lion seems to have zlib 1.2.5 which has a standard fucntion prototype for the gzgetc() function whereas 1.2.6 in MacPorts gzgetc() is indeed a macro. C treats void* very unsafely, silently converting it to and from other pointer types whenever it knows how. So converting the gzFile* gzopen() returned to the void* 'file' is legal. Then, if gzgetc() is an actual function declared as 'char gzgetc(gzFile*)' the compiler will allow the void* be passed to the function, and within the function it is treated as a gzFile*. But if gzgetc is just a macro the compiler doesn't know to convert 'file' to a gzFile*, so you get errors about trying to treat void as struct/union. If the API said gzgetc took a void* they would fix this by casting g to a gzFile* inside the macro that replaced the function, but the API doesn't say this, and so the zlib authors don't... The current version is actually both faster and safer since it catches this type of void* abuse. So tldr answer: patch the port using libz to use a gzFile* or to cast the void* gack to a gzFile* before calling functions expecting a gzFile*. I ended up applying a patch to the port that casts the void* pointer to gzFile and that allows it to build, but the upstream developer didn't like that approach. But this analysis is interesting and imagine this build error will be seen on other platforms that have zlib-1.2.6. Thanks for the help. Cheers Adam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Debian-like rename utility - available via MacPorts?
Dear all, If I'm not mistaken, in Debian Linux ( Ubuntu, etc), there is a rename utility, which I think comes from Debian's Perl package. It allows file renaming using regular expressions, as described in Jens Dreger's post here[1]. Apparently it (or something very much like it) is now available for Mac users via Brew.[2] However, I'm not a Brew user, I'm a MacPorts user. Please can you tell me if this utility is available via MacPorts? The closest I've found so far is renameutils, which IMO doesn't offer anything like the same ease of use, and isn't what I'm looking for at all. I haven't yet tried installing any of MacPorts's Perl packages, because in order to exhaustively check all of them for whether they include the rename utility, I'd potentially have to install several of them! In any case, it would be much better if MacPorts users could simply get rename by running port install rename much as Brew users can apparently get it by running brew install rename[2]. I did do a web search before posting this message and this topic doesn't seem to have been discussed before, but if my google-fu failed me and it *has* already been discussed, please feel free to point me to the relevant discussion. Thanks in advance for your comments and assistance, Sam [1] https://answers.launchpad.net/ubuntu/+source/nautilus/+question/2309 [2] http://superuser.com/questions/152627/renaming-many-files-in-mac-os-x-batch-processing ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Help please
On 23/02/2012, at 1:07 AM, Ryan Schmidt wrote:
On Feb 21, 2012, at 22:44, James Linder wrote:
checking for Apple Objective-C runtime... yes
checking for GNU Objective C runtime... no
configure: Using Apple Objective-C runtime
checking for Apple Foundation library... no
configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your
environment, preventing the use of GNUstep's Foundation library
configure: error: Could not find a working Foundation implementation
This is an error we've encountered a few times before, such as:
https://trac.macports.org/ticket/28452
https://trac.macports.org/ticket/30298
We didn't receive further feedback from the reporters so were unable to
pursue the matter further. Can you attach your config.log? Maybe it will
shed further light.
In #28452 we presumed software installed in /usr/local was interfering. Do
you have anything installed in /usr/local? If so, remove it and try again.
In #30298 we presumed the user's operating system components had become
damaged and the OS should be reinstalled. So that's another avenue you
could pursue.
haycorn:~ # ls /usr/local
.gitLibrary etc share
.gitignore README.md include texlive
Cellar bin lib
This was put here by latex install ...
haycorn:~ # mv /usr/local/ /usr/oldlocal
haycorn:~ # port -d selfupdate
[snip]
Error: /opt/local/bin/port: port selfupdate failed: Error installing new
MacPorts base: shell command failed (see log for details)
OK it'll take me a day or so to backup everything I want, so reinstall
(which will certainly work, it did work before) and I'll report back
Snow Leopard and install CD: Insert CD 'Instal Mac OS X': whirr whirr (1
hour) {but this way is very easy)
then
...
DEBUG: Error installing new MacPorts base: shell command failed (see log for
details)
while executing
macports::selfupdate [array get global_options] base_updated
Error: /opt/local/bin/port: port selfupdate failed: Error installing new
MacPorts base: shell command failed (see log for details)
That portion of the error doesn't tell us anything other than something went
wrong. If you check back further in the log, was it the same Could not find
a working Foundation implementation error?
Aaaargh hangs head in shame! I had not reinstalled Xcode.
So
Reinstall OS
install Xcode
Everything running sweetly again.
Thanks for all the help.
James
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Debian-like rename utility - available via MacPorts?
On Wed, Feb 22, 2012 at 11:33:50PM +, Sam Kuper wrote: If I'm not mistaken, in Debian Linux ( Ubuntu, etc), there is a rename utility, which I think comes from Debian's Perl package. It allows file renaming using regular expressions, as described in Jens Dreger's post here[1]. [...] In any case, it would be much better if MacPorts users could simply get rename by running port install rename much as Brew users can apparently get it by running brew install rename[2]. Sounds like a useful thing to have. I just added the p5-file-rename port, which is a newer version of that script. It installs both a perl module and a command-line script `file-rename`. Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: error using MacPorts zlib, not present with system zlib?
--On February 22, 2012 4:50:52 PM -0500 Eric Cronin ecro...@macports.org wrote: This code is wrong. The zlib documentation says gzgetc takes a gzFile* not a void*. Your analysis of this is correct except for one minor point. gzopen returns and gzgetc (and others) take a gzFile not a gzFile*. The definition of gzFile is typedef struct gzFile_s *gzFile; so it's defined as a pointer. Some compilers at some warning levels get annoyed if you use a gzFile* instead of gzFile for these parameters. Mike ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: error using MacPorts zlib, not present with system zlib?
On Wed, Feb 22, 2012 at 21:36, Mike Alexander m...@umich.edu wrote: --On February 22, 2012 4:50:52 PM -0500 Eric Cronin ecro...@macports.org wrote: This code is wrong. The zlib documentation says gzgetc takes a gzFile* not a void*. typedef struct gzFile_s *gzFile; so it's defined as a pointer. Some compilers at some warning levels get annoyed if you use a gzFile* instead of gzFile for these parameters. As they well should. -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
