Hi Kieran - Well, that's a tricky one. Let me elaborate; please bear with me.
See also <
http://developer.apple.com/library/mac/#technotes/tn2124/_index.html#//apple_ref/doc/uid/DTS10003391-CH1-SECDYLD
>, <
http://developer.apple.com/library/mac/#technotes/tn2124/_index.html#//apple_ref/doc/ui
Yup, works now. I really don't remember ever touching that part of
the config file. Anyway, if this comes up again for someone else it
probably means that there was a macports upgrade path that caused
people to have that specified by default. Hopefully there aren't too
many other people out ther
On Wed, Oct 12, 2011 at 4:23 PM, Scott Webster wrote:
> Hmm, seems that gstreamer and gst-plugins-base dependencies were just
> added to wine-devel. They of course have deps of their own. For
> instance libidl, which I already have installed non-universal. It
> needs to be universal for wine-de
On Wed, Oct 12, 2011 at 12:42 PM, Adam Dershowitz wrote:
> You might be right. Although, since wine-devel was all built and working
> before I tried to upgrade I am not sure how that could be. The errors were
> things like this:
> :info:build ld: warning: in /opt/local/lib/libIDL-2.dylib, file
> portarchivetype tgz
>
> I've never adjusted that manually. Should I set it to tbz2 or just
> comment it out?
Commenting out should do the trick; the default is currently tbz2.
smime.p7s
Description: S/MIME cryptographic signature
___
macpo
On Wed, Oct 12, 2011 at 2:50 PM, Jeremy Lavergne
wrote:
> Check your macports.conf: is there a archive type set?
>
Hmmm:
portarchivetype tgz
I've never adjusted that manually. Should I set it to tbz2 or just
comment it out?
Thanks,
Scott
__
Check your macports.conf: is there a archive type set?
Scott Webster wrote:
>Here's a snippet of a recent upgrade:
>
>---> Fetching archive for cmake
>DEBUG: Executing org.macports.archivefetch (cmake)
>---> cmake-2.8.6_0.darwin_10.x86_64.tgz doesn't seem to exist in
>/opt/local/var/macports/s
Here's a snippet of a recent upgrade:
---> Fetching archive for cmake
DEBUG: Executing org.macports.archivefetch (cmake)
---> cmake-2.8.6_0.darwin_10.x86_64.tgz doesn't seem to exist in
/opt/local/var/macports/software/cmake
---> Attempting to fetch cmake-2.8.6_0.darwin_10.x86_64.tgz from
http:
You might be right. Although, since wine-devel was all built and working
before I tried to upgrade I am not sure how that could be. The errors were
things like this:
:info:build ld: warning: in /opt/local/lib/libIDL-2.dylib, file was built for
unsupported file format which is not the architect
Thanks !
Rerunning the update did indeed work just fine.
Chris
On 12 Oct 2011, at 7:50pm, Dan Ports wrote:
> On Wed, Oct 12, 2011 at 06:36:37PM +0100, Chris Jones wrote:
>> :info:build libtool: link: `/opt/local/lib/libXt.la' is not a valid libtool
>> archive
>> :info:build make[1]: *** [coder
On Wed, Oct 12, 2011 at 06:36:37PM +0100, Chris Jones wrote:
> :info:build libtool: link: `/opt/local/lib/libXt.la' is not a valid libtool
> archive
> :info:build make[1]: *** [coders/xbm.la] Error 1
> :info:build make[1]: *** Waiting for unfinished jobs?.
This is bug #30809: libtool sometimes ra
wine-devel is 32 bit only.
Are you sure the problem wasn't that one of the dependencies was only
built as 64-bit, and therefore unsuitable for use with wine-devel?
Scott
On Wed, Oct 12, 2011 at 11:39 AM, Adam Dershowitz wrote:
> I was trying to upgrade wine-devel. It seems that it now requires
I was trying to upgrade wine-devel. It seems that it now requires universal
builds. That triggered a number of other ports to rebuild, since I had them as
32 bit only. No problem with that. The problem was that a number of these
dependencies gave errors on rebuilding. By looking at the logs
Hi,
The latest update does build on my OSX 10.7 machine, I get
port upgrade outdated
---> Computing dependencies for ImageMagick
---> Fetching archive for ImageMagick
---> Attempting to fetch ImageMagick-6.7.3-0_0+q16.darwin_11.x86_64.tbz2 from
http://packages.macports.org/ImageMagick
--->
> I have now found the following ticket:
> http://trac.macports.org/ticket/30349
>
> Changing the compiler with
>
> if {${configure.compiler} == "llvm-gcc-4.2"} {
>configure.compiler gcc-4.2
> }
>
> indeed works fine and basic cross-compilation seems to work with the
> binary that I get.
A
On Wed, Oct 12, 2011 at 16:23, Jeremy Lavergne
wrote:
>> I was about to submit a bug report, but it might be that the first
>> question they will ask will be, why I'm still using 3.4.5-20060117-2
>> (more than 5 years old) which might not be supported any more.
>>
>> A year ago when I had problems
> I was about to submit a bug report, but it might be that the first
> question they will ask will be, why I'm still using 3.4.5-20060117-2
> (more than 5 years old) which might not be supported any more.
>
> A year ago when I had problems with Segmentation fault of ldd, all
> problems were gone wh
On Wed, Oct 12, 2011 at 15:29, Jeremy Lavergne wrote:
> Looks like MingW itself crashed.
>
> internal compiler error: Segmentation fault: 11
> Please submit a full bug report, with preprocessed source if appropriate.
> See http://www.mingw.org/bugs.shtml for instructions.
I was about to submit a b
Looks like MingW itself crashed.
internal compiler error: Segmentation fault: 11
Please submit a full bug report, with preprocessed source if appropriate.
See http://www.mingw.org/bugs.shtml for instructions.
___
macports-users mailing list
macports-us
Hello,
I would like to ask for some help building mingw32 on Lion.
Compilation fails with:
:info:build
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_cross_i386-mingw32-gcc/i386-mingw32-gcc/work/build/gcc/xgcc
-B/opt/local/var/macports/build/_opt_l
20 matches
Mail list logo
