Am 21.04.16 um 00:18 schrieb Ryan Schmidt:
That log shows the activation phase of the sqlite3, unrelated to
poppler-qt4-mac.
Either you attached the wrong main.log file, or you ran into the bug where
MacPorts
writes the wrong port's log to the file:
https://trac.macports.org/ticket/370
On Apr 20, 2016, at 5:16 AM, Thomas Ruedas wrote:
>
> Am 20.04.16 um 05:34 schrieb Ryan Schmidt:
>>> I then cleaned the poppler-qt4-mac installation and tried to reinstall it,
>>> but it still doesn't work, and the logfile doesn't really help either; at
&
Am 20.04.16 um 05:34 schrieb Ryan Schmidt:
I then cleaned the poppler-qt4-mac installation and tried to reinstall it, but
it still doesn't work, and the logfile doesn't really help either; at least it
doesn't show an actual error message, as it usually does in such cases. So
gt; ---> Found 2 broken port(s), determining rebuild order
> ---> Rebuilding in order
> ImageMagick @6.9.3-4 +x11
> poppler-qt4-mac @0.41.0
> The installation proceeded automatically with rebuilding ImageMagick, which
> apparently worked,
As far as I know, I
ing in order
ImageMagick @6.9.3-4 +x11
poppler-qt4-mac @0.41.0
The installation proceeded automatically with rebuilding ImageMagick,
which apparently worked, and the with rebuilding poppler-qt4-mac, which
didn't:
---> Extracting poppler-qt4-mac
Error: org.macports.extract for
On Oct 1, 2015, at 11:38 PM, Richard L. Hamilton wrote:
> Error: qt4-mac does not currently build on OSX later than 10.10 'Yosemite'.
> Error: org.macports.fetch for port qt4-mac returned: unsupported platform
>
> Is this expected to be fixed,
OS X 10.11 El Capitan was
Error: qt4-mac does not currently build on OSX later than 10.10 'Yosemite'.
Error: org.macports.fetch for port qt4-mac returned: unsupported platform
Is this expected to be fixed, or do I have to build plain (x11-dependent) qt4,
and all dependencies accordingly?
smime.p7s
Descripti
epth=1
> http://anongit.freedesktop.org/git/poppler/test
> :info:extract Exit code: 128
> :error:extract org.macports.extract for port poppler-qt4-mac returned:
> command execution failed
>
> It was working fine for me before with git:// .
The error message doesn't say th
;
> :info:extract Command failed: /opt/local/bin/git clone --depth=1
> http://anongit.freedesktop.org/git/poppler/test
> :info:extract Exit code: 128
> :error:extract org.macports.extract for port poppler-qt4-mac returned:
> command execution failed
>
> It was working fine for
est/': Couldn't resolve host '
anongit.freedesktop.org'
:info:extract Command failed: /opt/local/bin/git clone --depth=1
http://anongit.freedesktop.org/git/poppler/test
:info:extract Exit code: 128
:error:extract org.macports.extract for port poppler-qt4-mac returned:
command ex
FYI,
I just submitted standalone tickets for variants and patches included in my
qt4-mac concurrent ticket but not related to making Qt4 co-installable :
#46606: qt4-mac "noexceptions" variant
Ticket URL: <https://trac.macports.org/ticket/46606>
#46607: qt4-mac +KDE variant.
Ti
Now that we're making progress with making qt4-mac and qt5-mac co-installable,
there's a similar question that could be asked:
is there any reason (not) to allow Qt 5.3, 5.4 and beyond to co-exist? I
presume these iterations introduce less ABI incompatibilities, but if 5.4 is
alre
On 15/12/2014, at 9:46 AM, René J.V. Bertin wrote:
> 'evening!
>
> I finally got around to finishing up (or almost) my draft version for a
> qt4-mac port that can live alongside other (future) Qt port versions
> installed with the same approach: see https://trac.macpo
'evening!
I finally got around to finishing up (or almost) my draft version for a qt4-mac
port that can live alongside other (future) Qt port versions installed with the
same approach: see https://trac.macports.org/ticket/46238 .
Related submissions:
https://trac.macports.org/ticket/
On Dec 12, 2014, at 12:31 PM, René J.V. Bertin wrote:
> On Friday December 12 2014 12:21:54 Lawrence Velázquez wrote:
>
>> Does the variable "qt4_is_concurrent" exist? If not, the portfile itself
>> throws an error and won't index.
>
> Yes, it exists, and portindex doesn't throw an error...
P
he dependents have to be revbumped anyway to make sure that they
> are depending on this shim port? Then they'd have to be revbumped a second
> time to switch over to the hypothetical qt4-mac Mk 2.
No, there's no need to depend on +libsymlinks or an alternative shim port. That
v
On Dec 11, 2014, at 9:21 AM, René J.V. Bertin wrote:
> Yes, I have willingly not provided a mechanism to avoid breakage of ports
> installed against +concurrent.
> But remember that I did try to set +concurrent by default if qt4-mac is
> installed that way.
We have to consider al
On Thu, Dec 11, 2014 at 4:07 AM, René J.V. wrote:
> > How about a main port with the new paths, and a stub port or subport that
> > depends on the main port, conflicts with qt4-mac, and installs the
> > symlinks? Then we can replace qt4-mac with the stub port at some point.
&
s, qmake, and other
> Qt ports provide cmake files that all allow to find things where they're
> installed.
What happens if you install qt4-mac with this variant, then install some ports
that use qt4-mac, then install qt4-mac without this variant? Answer: the ports
that depend on qt4-
it just takes one try to find out.
The result of this simple test should be added to the documentation.
On Dec 11, 2014, at 8:45, Ryan Schmidt wrote:
>> BTW, does this update the sha tag in the statefile,
>
> I doubt it.
___
macports-users mailing l
On Dec 11, 2014, at 5:31 AM, René J.V. Bertin wrote:
> On Thursday December 11 2014 05:33:30 Lawrence Velázquez wrote:
>
>> The -o option does this. Check the port(1) manpage.
>
> Ah, has this behaviour been modified lately? I remember it didn't always work
> as I expected.
I'm not aware of a
On Thursday December 11 2014 05:33:30 Lawrence Velázquez wrote:
> The -o option does this. Check the port(1) manpage.
Ah, has this behaviour been modified lately? I remember it didn't always work
as I expected.
BTW, does this update the sha tag in the statefile, or will I still get a `port
clea
> On Dec 11, 2014, at 4:07 AM, René J.V. Bertin wrote:
>
> It'd also be very helpful if there were an override simply for the "portfile
> has changed, cleaning everything" feature.
The -o option does this. Check the port(1) manpage.
vq
Sent from my iPhone
__
t I'm doing? I'll stick to using a
> variant for now, so that it's easier to go back to the "normal" version.
>
> But me too I'd appreciate help where needed, esp. from the people who
> know these ports best (which would be the maintainers, I guess)!
I always
On Wednesday December 10 2014 15:50:59 Lawrence Velázquez wrote:
> On Dec 10, 2014, at 2:27 PM, René J.V. Bertin wrote:
>
>
> You're welcome to try to rework the Qt ports so that they can be installed
> concurrently. As far as I know, the maintainers simply don't have much time
> these days t
by using variants. MacPorts doesn't have the capability to
> declare a dependency on a variant (ticket #126) and I'm still not convinced
> that that should ever change.
>
How about a main port with the new paths, and a stub port or subport that
depends on the main port, conflicts with q
On Dec 10, 2014, at 2:27 PM, René J.V. Bertin wrote:
> I've repeated often enough that we should never have been in this situation
> of mutual exclusivity in the first place, but sadly the 2 Qt port maintainers
> seem to be absent or of a completely different opinion.
You're welcome to try t
o comply with that.
Yes, but not by using variants. MacPorts doesn't have the capability to declare
a dependency on a variant (ticket #126) and I'm still not convinced that that
should ever change.
> It was never my intention to introduce definitive Qt4-kde and Qt5-kde por
On Dec 9, 2014, at 3:54 PM, René J.V. Bertin wrote:
> I've taken my courage with 3 hands, and started working on a +concurrent
> variant for qt4-mac, as a prerogative to having a ditto variant for qt5-mac
> (which won't even build when qt4-mac is installed).
>
> 2
4 was installed with +concurrent, unless we're (re)building
without that variant
# that means that either building_qt4 isn't set, or the port's ${name} !=
"qt4-mac"
# or the name variable isn't defined yet. That means the qt4-mac portfile
must define its n
Hello,
I've taken my courage with 3 hands, and started working on a +concurrent
variant for qt4-mac, as a prerogative to having a ditto variant for qt5-mac
(which won't even build when qt4-mac is installed).
Still with me?
So rather than using a new port, I went with a varia
On Fri, Sep 12, 2014 at 5:45 PM, vic hug wrote:
> soo, it didn't want to install akonadi, so i went up to find the "master"
> thing that was the installed application that was depending on all those
> outgraded ports, it was kdenlive and i uninstalled the 3 different versions
> of it that i had..
update will run fine...
Anyway thanks for the help guys !
Cheers,
Victor
> From: pixi...@macports.org
> Subject: Re: problem with qt4-mac-mysql5-plugin
> Date: Fri, 12 Sep 2014 13:45:02 -0700
> To: xelnagazch...@hotmail.com
>
>
> On Sep 12, 2014, at 1:16 PM, vic hug wrote
Hello Michael,
I feared that much, and indeed I've noticed that configure.optflags="-O3 -ggdb"
appears in some compilations but not all (and of course someone puts a -O2
*after* my -O3 :-/ ). Let's hope that I get debug info in where I'd really like
to have it without having to hack hundreds of
ess you have a need for an older mysql.
To install akonadi with default mariadb use:
sudo port uninstall akonadi qt4-mac-mysql5-plugin mysql5 mysql5-server mysql51
mysql51-server
sudo port install akonadi
Regards,
Bradley Giesbrecht (pixilla)
signature.asc
Description
pendencies akonadithen
sudo port install akonadi +mysql51
?
Greets, Victor
> Subject: Re: problem with qt4-mac-mysql5-plugin
> From: mk-macpo...@techno.ms
> Date: Fri, 12 Sep 2014 06:27:42 +0200
> CC: macports-users@lists.macosforge.org
> To: xelnagazch...@hotmail.com
>
> Hi
Hi Victor,
check out [1] for further info where this was discussed as well.
Greets,
Marko
[1] https://trac.macports.org/ticket/43499
___
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macpo
gt;
> ---> Computing dependencies for qt4-mac-mysql51-plugin
> Error: Unable to exec port: Can't install qt4-mac-mysql51-plugin because
> conflicting ports are active: qt4-mac-mysql5-plugin
>
> Then, following advice on the irc, i entered :
> port echo install
Hello,
i'm on osx 10.6.8 and have been trying a port upgrade outdated. Previously had
done a sudo port selfupdate successfully. The ports upgrade hangs when it's
trying to update this plugin with the following mesage :
---> Computing dependencies for qt4-mac-mysql51-plugin
On Jul 26, 2014, at 7:08 AM, René J.V. Bertin wrote:
>
> I think a more obvious solutions would be for the port command not to try and
> be clever about /opt/local, in particular not to try to resolve it. I fail to
> see reasons to resolve /opt/local to an actual directory, but if ever there
>
Hi Ian,
On 26 Jul 2014, at 14:17 , Ian Wadham wrote:
> There was this discussion on macports-dev:
> https://lists.macosforge.org/pipermail/macports-dev/2014-June/027145.html
> preceded by a few remarks in a couple of messages on a KDE-Mac thread:
> http://mail.kde.org/pipermail/kde-mac/2014-June/
Hi René,
On 26/07/2014, at 9:12 PM, René J.V. Bertin wrote:
> On Jul 26, 2014, at 12:14, Ryan Schmidt wrote:
>
>> * don't use the +debug variant of qt4-mac, and
>
> Forgot. It might be useful to add a variant to the KDE portgroup (or the
> cmake portgroup, to ext
On Jul 26, 2014, at 12:14, Ryan Schmidt wrote:
> * don't use the +debug variant of qt4-mac, and
Forgot. It might be useful to add a variant to the KDE portgroup (or the cmake
portgroup, to extend the feature beyond KDE) that uses
-DCMAKE_TYPE:STRING=RelWithDebInfo . Possibly attempting
reason that I need to set
DYLD_IMAGE_SUFFIX=_debug to get everyone on the same wavelength ...
This may be related to the fact that apparently one needs to install
qt4-mac+debug in order to install kde*+debug ...
> * don't use the +debug variant of qt4-mac
Sure, and forego the possibility
On 26/07/2014, at 8:12 PM, René J.V. Bertin wrote:
> After installing the qt4-mac debug variant and rebuilding/upgrading a number
> of ports, I'm facing issues with the _debug libraries. As long as I keep the
> debug variant activated there are errors about symbols being presen
On Jul 26, 2014, at 5:12 AM, René J.V. Bertin wrote:
> After installing the qt4-mac debug variant and rebuilding/upgrading a number
> of ports, I'm facing issues with the _debug libraries. As long as I keep the
> debug variant activated there are errors about symbols being presen
After installing the qt4-mac debug variant and rebuilding/upgrading a number of
ports, I'm facing issues with the _debug libraries. As long as I keep the debug
variant activated there are errors about symbols being present twice (in the
regular and _debug libraries) and the only way to pr
On Sun, Mar 16, 2014, at 09:36 PM, René J.V. Bertin wrote:
> On Sunday March 16 2014 18:42:53 you wrote:
> > about for some project that's using QtGui via QMake, for which removing
> > the linking with Carbon worked? I've never tried the former, and the
> > latter could easily work depending on th
On Sunday March 16 2014 18:42:53 you wrote:
> Hi René - Are you saying that you removed the linking with "-framework
> Carbon" from when QtGui is linked and that worked? Or, are you talking
No, unfortunately I didn't test that.
> about for some project that's using QtGui via QMake, for which rem
and the
latter could easily work depending on the project. - MLD
On Sun, Mar 16, 2014, at 09:02 AM, René J.V. Bertin wrote:
> I see that Qt4-mac links against Carbon.framework (in QtGui.dylib) and
> even exports the dependency via qmake. But the times I tried to link
> without -framework
I see that Qt4-mac links against Carbon.framework (in QtGui.dylib) and even
exports the dependency via qmake. But the times I tried to link without
-framework Carbon everything worked just fine.
Is this dependency still valid, and is it really one that needs to be promoted
from the Qt
Hello,
Worked for me as well. Thank you.
On Feb 11, 2013, at 1:25 PM, Ryan Schmidt wrote:
On Feb 11, 2013, at 15:21, Frank J. R. Hanstick wrote:
I thought that MacPorts defaulted to the system gcc default
setting(s) (limited to Apple certified versions of course) rather
than a har
> Joshua, whereis behaved exactly as I expected it to.
I'd assume Josh was pointing out that `which` is appropriate for executables
in $PATH, as `whereis` does a lot of other scanning.
Verifying the symlinks with `ls` would be more helpful than a screenshot of
gcc-4.2 or comparing the ou
Hello,
Xcode installed them. I have not symlinked anything.
On Feb 11, 2013, at 6:46 PM, Lawrence Velázquez wrote:
On Feb 11, 2013, at 9:41 PM, "Frank J. R. Hanstick" > wrote:
I have both 4.0 and 4.2 in /usr/bin. The gcc, g++, and c++ are
aliases pointing to either gcc-4.0 or gcc-4.2
On Feb 11, 2013, at 9:41 PM, "Frank J. R. Hanstick" wrote:
> I have both 4.0 and 4.2 in /usr/bin. The gcc, g++, and c++ are aliases
> pointing to either gcc-4.0 or gcc-4.2. Mine happen to be set up to use
> gcc-4.2.
Is that how Xcode installed them, or did you symlink them yourself?
vq
__
> On Feb 11, 2013, at 15:21, Frank J. R. Hanstick wrote:
>
>> I thought that MacPorts defaulted to the system gcc default setting(s)
>> (limited to Apple certified versions of course) rather than a hard coded
>> default setting.
>
> The hardcoded default compiler in MacPorts, which varies by Xc
On Feb 11, 2013, at 15:21, Frank J. R. Hanstick wrote:
> I thought that MacPorts defaulted to the system gcc default setting(s)
> (limited to Apple certified versions of course) rather than a hard coded
> default setting.
The hardcoded default compiler in MacPorts, which varies by Xcode versio
On Feb 10, 2013, at 23:09, Frank J. R. Hanstick wrote:
> I keep getting the following error when trying to upgrade qt4-mac:
>
> :info:configure error: The compiler (/usr/bin/g++-4.0) does not seem to
> support the Objective-C blocks (^), which are used by Qt when compiling on
&g
Hello,
I keep getting the following error when trying to upgrade qt4-mac:
:info:configure error: The compiler (/usr/bin/g++-4.0) does not seem
to support the Objective-C blocks (^), which are used by Qt when
compiling on Mac OS X.
:info:configure Command failed: cd "/opt/loca
Ah; yes. I see. OK; should be addressed in r102936. Sorry for the
confusion. - MLD
On Feb 10, 2013, at 5:14 PM, Ryan Schmidt
wrote:
> > On Feb 10, 2013, at 12:55, Michael Dickens wrote:
> >
> > Not sure of the issue exactly, but qt4-mac 4.8 does not compile on PPC
>
On Feb 10, 2013, at 12:55, Michael Dickens wrote:
> Not sure of the issue exactly, but qt4-mac 4.8 does not compile on PPC
> nicely. See ticket #36497 < https://trac.macports.org/ticket/36497 >
As far as I know that's a Tiger issue, not a PowerPC issue. This user is on
L
Not sure of the issue exactly, but qt4-mac 4.8 does not compile on PPC
nicely. See ticket #36497 < https://trac.macports.org/ticket/36497 >
for more on that. Maybe your issue is the same as this ticket's? As
another has already said, we cannot do more without a log
On Sun, Feb 10, 2013 at 8:09 AM, Eneko Gotzon Ares wrote:
> Trying to upgrade ports an error happens:
> ·Unable to upgrade port: 1
> ·Error rebuilding qt4-mac
> ·Three unsuccessful attempts.
> ·Ports clean done.
> I upgrade the ports one by one to know what they are and what the
;t want disturb MacPorts.
Yes.
> 2nd. If the answer to the previous question is "yes", then here is my
> problem: installing kmymoney [1] quickly shows this error:
> ---> Computing dependencies for kmymoney
> Error: Unable to execute port: Can't install qt3 because
ng kmymoney [1] quickly shows this error:
> ---> Computing dependencies for kmymoney
> Error: Unable to execute port: Can't install qt3 because conflicting ports
> are installed: qt4-mac
>
> What I must do?
> ·Not install kmymoney.
> ·File a bug report.
> ·To un
t;, then here is my
problem: installing kmymoney [1] quickly shows this error:
---> Computing dependencies for kmymoney
Error: Unable to execute port: Can't install qt3 because conflicting
ports are installed: qt4-mac
What I must do?
·Not install kmymoney.
·File a bug report.
·To uninsta
Hi Comer - It is quite possible that qt4-mac is still building.
Depending on your specific Mac and OS, it can take 1 hour to 1 day. I
truly doubt that the install was stalled; more likely is that it just
takes a very long time to build. If you have the patience and
resources, leave it going
Hi,
I have run against an apparent problem in trying to do an upgrade outdated
for qt4-mac. Here is what I see
homelap-3:~ comerduncan$ sudo port upgrade outdated
---> Computing dependencies for qt4-mac
---> Building qt4-mac
The thing is that this just hangs (after 3 hours I cntrl-C
At 3:17 PM -0400 6/17/12, Michael Dickens wrote:
On Jun 17, 2012, at 11:41 AM, Craig Treleaven wrote:
From the Qt4-mac portfile, it appears that OS X 10.4 through 10.7
are supported on the various combinations of PPC, i386, x86_64 in
32 and 64 bit modes, as appropriate. (So the minimum would
On Jun 17, 2012, at 11:41 AM, Craig Treleaven wrote:
> From the Qt4-mac portfile, it appears that OS X 10.4 through 10.7 are
> supported on the various combinations of PPC, i386, x86_64 in 32 and 64 bit
> modes, as appropriate. (So the minimum would be PPC 32 bit if anyone was
> pa
At 10:14 AM -0400 6/14/12, Michael Dickens wrote:
I recently updated qt4-mac from 4.7.4 to 4.8.2. ... qt4-mac also
contains various fixes
that should allow it compile more reliably and faster, as well as work
better within the MacPorts framework. - MLD
From the Qt4-mac portfile, it appears
I recently updated qt4-mac from 4.7.4 to 4.8.2. For those of you using
qt4-mac-devel (4.8.0), I will be moving it to the 5.0 alpha release as
soon as it compiles cleanly for me. So, if you're still using
qt4-mac-devel, please switch to using qt4-mac instead since it's
actually more r
On Mar 26, 2012, at 07:58, Craig Treleaven wrote:
> The existing MythTV build script (perl) includes the following:
>
>> # We set 32-bit mode via environment variables.
>> # The messier alternative would be to tweak all the configure arguments.
>> if ( $OPT{'m32'} )
>> {
>>&Verbose('Forcing
At 10:43 PM -0500 3/25/12, Ryan Schmidt wrote:
On Mar 25, 2012, at 11:05, Craig Treleaven wrote:
I want to install QT4-mac as using Quartz, which is the default variant,
Right. So you don't need to do anything special; just install
qt4-mac and you'll get quartz.
even though
On Mar 25, 2012, at 11:05, Craig Treleaven wrote:
> I want to install QT4-mac as using Quartz, which is the default variant,
Right. So you don't need to do anything special; just install qt4-mac and
you'll get quartz.
> even though my Mac is 64 bit (early 2011 MBP).
The bit
Hi:
I want to install QT4-mac as using Quartz, which is the default
variant, even though my Mac is 64 bit (early 2011 MBP). The command
I used was:
$ sudo port -v install qt4-mac +mysql -sqlite2
It seems that MacPorts determined the machine architecture and
overrode the default variant
Hi Alexandre!
> I need to compile/resurrect an old project of mine, and it use qt3.
If you want to run Qt4 apps as well as Qt3 apps, you can not - as Brad wrote -
install qt3-mac parallel to qt4-mac, instead you would have to set up parallel
MacPorts installations with different prefixes
On 12/03/12 00:19, Bradley Giesbrecht wrote:
Not in the same prefix. What is your need for need qt3-mac? Regards,
Bradley Giesbrecht (pixilla)
I need to compile/resurrect an old project of mine, and it use qt3.
--
Alexandre Parent
___
macports-use
On Mar 11, 2012, at 4:15 PM, Alexandre Parent wrote:
> Hi everyone,
>
> Is there a way to make qt4-mac and qt3-mac package installed on the same
> system ?
> I have the following message :
> Error: Unable to execute port: Can't install qt3-mac because conflicting
> po
Hi everyone,
Is there a way to make qt4-mac and qt3-mac package installed on the same
system ?
I have the following message :
Error: Unable to execute port: Can't install qt3-mac because conflicting
ports are installed: qt4-mac
I need to have both on my system, is it possible wit
oblem with the Qt release?
The port was qt4-mac @4.7.4_0+debug+quartz
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
at the Makefiles are generated from the qmake project files, is the bug
in the way that they are generated or is this an upstream problem with the Qt
release?
The port was qt4-mac @4.7.4_0+debug+quartz
___
macports-users mailing list
macports-users@lists
t was in CXXFLAGS) and rebuilt Qt and
> retried my gdb session. I got symbols, line numbers, code listings, etc.
> Given that the Makefiles are generated from the qmake project files, is the
> bug in the way that they are generated or is this an upstream problem with
> the Qt relea
problem with the Qt release?
The port was qt4-mac @4.7.4_0+debug+quartz
Cheers,
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
st use the same suffix for everything to work. Of course, the last
OSX with system debug libraries was 10.5 (just confirmed this, at least from
developer.apple.com); I don't use 10.7 yet, so maybe they are available for it
by now?
Your issue is with which library is picked to use in the .p
I'm new to MacPorts, but having come from a Linux background I'm really
thankful for MP so that my favourite tools are available really easily!!
I built qt4-mac +debug however when you do a pkg-config to check the
libs to link against for say QtGui_debug, QtCore is listed r
On Aug 26, 2011, at 22:09, Frank J. R. Hanstick wrote:
> I was able to upgrade qt4 by simply deactivating qt3.
Correct. You just can't have multiple Qt ports installed and active at the same
time. Of course you can have any number of ports installed but inactive.
__
Hello,
I was able to upgrade qt4 by simply deactivating qt3.
On Aug 24, 2011, at 12:19 PM, Ryan Schmidt wrote:
On Aug 22, 2011, at 19:13, Frank J. R. Hanstick wrote:
Some programs require qt3 and some require qt4 which is why both
are installed. They did not conflict before.
They
On Aug 22, 2011, at 19:13, Frank J. R. Hanstick wrote:
> Some programs require qt3 and some require qt4 which is why both are
> installed. They did not conflict before.
They always conflicted, but they were not always marked as being conflicting,
resulting in users experiencing errors when tr
-mac @3.3.8b_2
---> Cleaning qt3-mac
---> Computing dependencies for qt3-mac
---> Deactivating qt3-mac @3.3.8b_0
---> Activating qt3-mac @3.3.8b_2
---> Cleaning qt3-mac
---> Computing dependencies for qt4-mac
Error: Unable to upgrade port: Can't install qt4-mac because
-> Deactivating qt3-mac @3.3.8b_0
> ---> Activating qt3-mac @3.3.8b_2
> ---> Cleaning qt3-mac
> ---> Computing dependencies for qt4-mac
> Error: Unable to upgrade port: Can't install qt4-mac because conflicting
> ports are installed: qt3-mac
> To report a bug, se
t; Cleaning qt3-mac
---> Computing dependencies for qt3-mac
---> Deactivating qt3-mac @3.3.8b_0
---> Activating qt3-mac @3.3.8b_2
---> Cleaning qt3-mac
---> Computing dependencies for qt4-mac
Error: Unable to upgrade port: Can't install qt4-mac because
conflicting
On Jul 14, 2011, at 00:26, Yifei Li wrote:
> Error: /opt/local/lib/libltdl.dylib is not in the destroot. Please clean
> libtool and try again.
> Error: Target org.macports.destroot returned: missing
> /opt/local/lib/libltdl.dylib in destroot
All but one of the tickets that I've seen filed for
Hi,
I got the following error when I tried to install qt4-mac:
Error: /opt/local/lib/libltdl.dylib is not in the destroot. Please clean
libtool and try again.
Error: Target org.macports.destroot returned: missing
/opt/local/lib/libltdl.dylib in destroot
However, libltdl.dylib does exist in /opt
7.0;
I'll check this to make sure, and remove those particular patches if
so.
I am experiencing this issue while building djview on PPC platform, I
am getting a string "-arch ppc -arch" without the second arch. This is
tracked in ticket 27073. Is there any known workarou
_soname" to
generate the full-path self-id name for libraries -- this seems like a wise
option to always be using, so that we're not forced to correct self-id's all
over the place. qt4 uses this option internally when building, but doesn't
include it in the macx-g++ defaul
On Sep 8, 2010, at 1:18 PM, Ryan Schmidt wrote:
On Sep 8, 2010, at 11:59, Jan Lübke wrote:
I assume that qt4-mac is basically the same. Only the paths
are different. Is that assumption correct?
I hope so, but do not know.
For all practical purposes, yes, they are the same. They
t) on Mac OS X 10.6.4 with
> qt-support and run into some difficulties. Maybe someone on this list can
> help me or give me a hint.
>
> It works flawlessly if I download and install the official package of qt
> 4.6.3 for cocoa.
>
> I assume that qt4-mac is basically the sam
into some difficulties. Maybe someone on this list can help
me or give me a hint.
It works flawlessly if I download and install the official package of qt 4.6.3
for cocoa.
I assume that qt4-mac is basically the same. Only the paths are different. Is
that assumption correct?
Of course I can not
On Aug 17, 2010, at 11:03, Thomas Weiss wrote:
> Sorry for bothering you again with a qt4 problem. I tried to update to
> qt4-mac 4.6.3 today and the build didn't finish. These are the last lines
> from the logfile:
>
> :info:build /usr/bin/g++-4.2 -c -pipe -O2 -arch
1 - 100 of 185 matches
Mail list logo
