[mythtv] [mythtv-commits] mythtv branch master updated by jyavenard. v0.28-pre-1046-gd7de3ff
Craig Treleaven
ctreleaven at cogeco.ca
Fri Apr 4 11:37:13 UTC 2014
At 9:13 PM +1100 4/4/14, Jean-Yves Avenard wrote:
>On 4 April 2014 13:58, Craig Treleaven <ctreleaven at cogeco.ca> wrote:
>
>>
>> OK, I've checked that all the bits that were recently modified (latest
>> 0.27-fixes but including the two commits to master) work OK for me on
>> 10.6.8. Well, except AirPlay of photos--I've tried a LOT of different
>> things but can't make that work. Must be a MacPorts-Qt4 glitch but it
>> eludes me.
>>
>> Also tested the build on 10.9.2 and all seems well there.
>
>for your build, you could try this patch:
>
>diff --git a/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
>b/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
>index 0a6c046..75f75c0 100644
>--- a/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
>+++ b/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
>@@ -834,10 +834,10 @@ void
>MythAirplayServer::HandleResponse(APHTTPRequest *req,
> if (req->GetMethod() == "PUT")
> {
> // this may be received before playback starts...
>- QImage image = QImage::fromData(req->GetBody());
> bool png =
> req->GetBody().size() > 3 && req->GetBody()[1] == 'P' &&
> req->GetBody()[2] == 'N' && req->GetBody()[3] == 'G';
>+ QImage image = QImage::fromData(req->GetBody(), png ?
>"JPG" : "PNG");
> LOG(VB_GENERAL, LOG_INFO, LOC +
> QString("Received %1x%2 %3 photo")
> .arg(image.width()).arg(image.height()).
>
>
>This tells which format to use rather than letting Qt guess.
>
>not tested.
Thanks but I've essentially tried this. I knew that all the images I
was testing with are jpeg so, as a hack for testing, I did:
QImage image = QImage::fromData(req->GetBody(),"JPG");
and
QImage image = QImage::fromData(req->GetBody(),"JPEG");
Neither made any difference. I also rolled back libpng and jpeg to
the versions used in Qt's distributed binary. That eliminated the
ICC profile warning but I still can not get images to display.
Remember that it _does_ work on Mavericks for me. I've asked the
qt4-mac port maintainer if there is any build difference between
Mavericks and all the other OS builds. Waiting for an answer.
> >...
> > I know it is not a big deal to you, but I finally tracked down a build
>> problem that has plagued me from the start on MacPorts--installed versions
>> of the libs would be referenced due to an '-L/opt/local/lib' early in the
>> linker's args. I finally realized that it only affected libmythtv.
>> mythtv/libs/libmythtv/libmythtv.pro includes the line:
>>
>> QMAKE_LFLAGS_SHLIB += $${FREETYPE_LIBS}
>>
>> configure has filled FREETYPE_LIBS with the output from 'freetype-config
>> --libs'. On OS X, I get:
>>
>> $ freetype-config --libs
>> -L/opt/local/lib -lfreetype -L/opt/local/lib -lz -lbz2 -L/opt/local/lib
>> -lpng14
>>
>> I'm guessing that FreeType is trying to be 'helpful' since MacPorts
>> installed it to a 'non-standard' location.
>>
>> Anyway, the line in libmythtv.pro is wrong. FreeType's libs _are_ included
>> later in the linker parameters. Other uses of QMAKE_LFLAGS_SHLIB are for
>> linker flags, not library references. For example, line 83 of
>> libmythupnp.pro sets:
>>
>> QMAKE_LFLAGS_SHLIB += -flat_namespace
>>
>> The above is in 0.27-fixes. In master, I see that dblain wrapped the
>> problem line in a conditional so that it would be excluded on win32-msvc*.
>> I presume it was messing with him, too!
>>
>> I've deleted the offending line (line 52) and built successfully with both
>> XCode 3.2.6 and XCode 5.1.0.
>>
>> Should I raise a bug for this?
>
>I'm not sure I understand what your problem is.
>Is the issue in freetype or in myth?
>
>Are you saying the myth uses installed headers/libraries rather than
>using the one in the current source tree?
Yes
>I'm seeing this problem too, even to the point where before I compile
>I always delete the system's installed mythtv librarires and headers.
>It's a pain cause often a compilation will fail at linkage simply
>because I've modified a library, but the new code is trying to link
>against the installed one; and as such I get non-existing symbol
>
>could this be the reason?
Yes.
Plus the line makes no sense. It is for flags; not link libraries.
(And it's been there since 2006!) Due to a quirk in Freetype,
however, it has been no harm in the most common cases. Only bites
those of us packaging to non-standard locations.
Craig
More information about the mythtv-dev
mailing list