Usually, you don't need multiple sip versions, but you do need the newest one
for the newest pyqt4. I'll see if I can sort this out by the weekend. There's
still an overlapping file issue with the -x11 and -mac versions, though.
Dave
On Mar 2, 2010, at 5:27 PM, BABA, Yoshihiko wrote:
> Dear,
>
On Mar 2, 2010, at 7:55 PM, Max Horn wrote:
> The issue is related to the that fact that Apple switched from
> ComponentDescription to AudioComponentDescription in 10.6, and
> deprecated some AudioUnit API in 10.5. And I can confirm that the
> issue occurs indeed on 32bit 10.6 (though this
The issue is related to the that fact that Apple switched from
ComponentDescription to AudioComponentDescription in 10.6, and
deprecated some AudioUnit API in 10.5. And I can confirm that the
issue occurs indeed on 32bit 10.6 (though this is suprisingly the
first report I got on the issue).
Dear,
The current packages of SIP-PY26 and PyQt4 don't match.
>>> import sip
>>> from PyQt4 import QtCore, QtGui
Traceback (most recent call last):
File "", line 1, in
RuntimeError: the sip module implements API v7.0 but the PyQt4.QtCore module
requires API v6.0
If this API version really m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/2/10 8:10 AM, Dr. Wolfram Schroers wrote:
> Hi,
>
> I have a problem building dosbox. During compiling I get the error message:
>
> [...]
> g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/sw/include
> -I/sw/include/SDL -D_GNU_SOURCE=1 -D_TH
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/2/10 12:49 PM, Pranay Airan wrote:
> so i figured out the way to resolve this problem. i am putting our own
> _structs.h into /sw/include folder and it is compiling from there, but
> now i am facing a new problem when i am running fink -m
> --buil
Hi,
I have a problem building dosbox. During compiling I get the error message:
[...]
g++ -DHAVE_CONFIG_H -I. -I../.. -I../../include -I/sw/include
-I/sw/include/SDL -D_GNU_SOURCE=1 -D_THREAD_SAFE -fast -MT midi.o -MD -MP -MF
.deps/midi.Tpo -c -o midi.o midi.cpp
In file included from midi.cp
so i figured out the way to resolve this problem. i am putting our own
_structs.h into /sw/include folder and it is compiling from there, but now i
am facing a new problem when i am running fink -m --build-as-nobody rebuild
cilk
Upto make it is working fine but at time of make install it is giving
On 03/02/2010 10:34 AM, Pranay Airan wrote:
> So here is what i figure out
>
> if you see line 97, 111,112, 125, 135, 136 of _structs.h they are
> declaring variables without names just like 39; 39; etc when i commented
> those lines i am able to compile
gcc allows anonymous bitfields like this
On 03/02/2010 09:56 AM, Pranay Airan wrote:
> hello
>
> We have been trying to package CILK through FINK. In this process, in
> order to port it on to MAC OSX, we require gcc. So, we installed XCODE
> 3.1.4 on our machine. Now while running Makefile of CILK, we
> encountered errors while trying t
(this time including fink-devel in my reply)
Please provide the output from your terminal that shows the errors. Maybe
someone recognizes it and can point you in the right direction.
- Koen.
On Tue, Mar 2, 2010 at 11:23 AM, Pranay Airan wrote:
> thanks but when i searched for cilk before star
So here is what i figure out
if you see line 97, 111,112, 125, 135, 136 of _structs.h they are
declaring variables without names just like 39; 39; etc when i commented
those lines i am able to compile
On Tue, Mar 2, 2010 at 9:56 PM, Peter O'Gorman wrote:
> On 03/02/2010 09:56 AM, Pranay Airan
hello
We have been trying to package CILK through FINK. In this process, in order
to port it on to MAC OSX, we require gcc. So, we installed XCODE 3.1.4 on
our machine. Now while running Makefile of CILK, we encountered errors
while trying to compiling example .cilk files ...
* This is due to som
On Tue, Mar 02, 2010 at 06:40:46PM +0900, mpsuz...@hiroshima-u.ac.jp wrote:
> Dear Peter,
>
> On Wed, 24 Feb 2010 10:02:32 -0600
> "Peter O'Gorman" wrote:
> >On 02/24/2010 02:42 AM, suzuki toshiya wrote:
> >> B. What should be fixed is GNU libtool, not library packages.
> >>
> >> There would be
Dear Peter,
On Wed, 24 Feb 2010 10:02:32 -0600
"Peter O'Gorman" wrote:
>On 02/24/2010 02:42 AM, suzuki toshiya wrote:
>> B. What should be fixed is GNU libtool, not library packages.
>>
>> There would be an opinion: the current GNU libtool behaviour:
>> - "-framework XXX" is copied to .la file.
Daniel Macks wrote:
[]
> According to the Debian package-script docs, postrm does run during an
> upgrade/reinstall (because the old/previous one is being rm'ed).
According to man dpkg, what should work is to use PreRmScript instead of
PostRmScript.
--
Martin
16 matches
Mail list logo
