On Mon, Oct 12, 2015 at 10:39:29PM +0200, René J.V. Bertin wrote:
> I can't remember, did I file a bug report on this,
>
that shouldn't be too hard to find out, no? ;)
> or has the issue already been picked up?
>
i don't really understand the issue, so no. please have a close look at
the status q
Hi,
I can't remember, did I file a bug report on this, or has the issue
already been picked up? I've seen others being bitten by it ...
R.
On 13 September 2015 at 04:20, Jake Petroules
wrote:
>
> On Sep 12, 2015, at 5:15 PM, René J.V. Bertin wrote:
>
> On Saturday September 12 2015 14:22:28 Ja
> On Sep 29, 2015, at 8:40 PM, Oswald Buddenhagen
> wrote:
>
> On Tue, Sep 29, 2015 at 08:32:21AM -0700, Jake Petroules wrote:
>> If you set QMAKE_RPATHDIR to some value (including an empty value),
>> then qmake won't add the absolute path in the first place.
>>
> note that things are differen
On Tue, Sep 29, 2015 at 08:32:21AM -0700, Jake Petroules wrote:
> If you set QMAKE_RPATHDIR to some value (including an empty value),
> then qmake won't add the absolute path in the first place.
>
note that things are different again in the 5.6 branch.
the only way to suppress the addition of the
> On Sep 29, 2015, at 2:11 AM, Ziller Eike wrote:
>
>
>> On Sep 29, 2015, at 10:16, Jake Petroules
>> wrote:
>>
>>
>>> On Sep 28, 2015, at 2:30 PM, Massimo Callegari
>>> wrote:
>>>
>>> On Monday 28 September 2015 19:09:11 Massimo Callegari wrote:
> But please guys, when introducing s
> On Sep 29, 2015, at 2:35 AM, Massimo Callegari
> wrote:
>
>
>> From what I can see, nothing is "broken" for him in the sense he is not
>> limited from doing anything >he was previously able to do.
>
>
> Again, the matter is simple: what was working from Qt 4.8 up to Qt 5.4.2 is
> not wor
>From what I can see, nothing is "broken" for him in the sense he is not
>limited from doing anything >he was previously able to do.
Again, the matter is simple: what was working from Qt 4.8 up to Qt 5.4.2 is not
working anymore with Qt 5.5.x. At least for me.
>>Since Qt 4.8 and up to Qt 5.4.2
> On Sep 29, 2015, at 10:16, Jake Petroules
> wrote:
>
>
>> On Sep 28, 2015, at 2:30 PM, Massimo Callegari
>> wrote:
>>
>> On Monday 28 September 2015 19:09:11 Massimo Callegari wrote:
But please guys, when introducing such an important change, you are
warmthly
invited to me
> On Sep 29, 2015, at 10:27, Jake Petroules
> wrote:
>
>
>> On Sep 28, 2015, at 2:40 PM, Thiago Macieira
>> wrote:
>>
>> On Monday 28 September 2015 21:30:33 Massimo Callegari wrote:
Can you explain what broke for you?
>>>
>>> Since Qt 4.8 and up to Qt 5.4.2 I was using the install_na
> On Sep 28, 2015, at 2:40 PM, Thiago Macieira
> wrote:
>
> On Monday 28 September 2015 21:30:33 Massimo Callegari wrote:
>>> Can you explain what broke for you?
>>
>> Since Qt 4.8 and up to Qt 5.4.2 I was using the install_name_tool procedure
>> as described here: http://doc.qt.io/qt-5/osx-de
> On Sep 28, 2015, at 2:30 PM, Massimo Callegari
> wrote:
>
> On Monday 28 September 2015 19:09:11 Massimo Callegari wrote:
>>> But please guys, when introducing such an important change, you are warmthly
>>> invited to mention it in a visible place.
>
>> It's in the changelog.
>
>> But I con
> On 28 Sep 2015, at 23:40, Thiago Macieira wrote:
>
> What if we add an extra rpath to Qt libs as @executable_path/../Frameworks?
> Would this make loading work?
>
> Jake, Morten: as a stop-gap, is there a configure-time switch to revert to
> the
> old behaviour? This change seems to be too
>- Messaggio originale -
>Da: Thiago Macieira
>A: development@qt-project.org; Jake Petroules
>Cc:
>Inviato: Lunedì 28 Settembre 2015 23:40
>Oggetto: Re: [Development] Qt 5.5.0 build issues on OS X : rpath
>>On Monday 28 September 2015 21:30:33 Massimo Calle
On Monday 28 September 2015 21:30:33 Massimo Callegari wrote:
> > Can you explain what broke for you?
>
> Since Qt 4.8 and up to Qt 5.4.2 I was using the install_name_tool procedure
> as described here: http://doc.qt.io/qt-5/osx-deployment.html
> With prebuilt Qt 5.5.x clang64, QtFrameworks don't
On Monday 28 September 2015 19:09:11 Massimo Callegari wrote:
>> But please guys, when introducing such an important change, you are warmthly
>> invited to mention it in a visible place.
> It's in the changelog.
> But I confess the line you're referring to does not indicate that anything
> shoul
On Monday 28 September 2015 19:09:11 Massimo Callegari wrote:
> But please guys, when introducing such an important change, you are warmthly
> invited to mention it in a visible place.
It's in the changelog.
But I confess the line you're referring to does not indicate that anything
should break.
Oh, and by "visible place" I mean this:
http://doc.qt.io/qt-5/osx-deployment.html
which is Qt5 docs and it still refers to Qt4 deployment with (now) wrong
install_name_tool -change calls.
- Messaggio originale -
Da: Massimo Callegari
A: "development@qt-project.org"
Cc: "jake.petrou..
...if I may add my 2 cents on this...
It took me 3 days to figure out what the heck was going on with a Qt 5.5.1
snapshot.
Then I googled and found the heck.
If one doesn't find this specific line:
http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.0#n578
Or this specific QTBUG:
http
> On Sep 12, 2015, at 5:15 PM, René J.V. Bertin wrote:
>
> On Saturday September 12 2015 14:22:28 Jake Petroules wrote:
>
>>
>> Relative install names are useless, there is virtually no reason you'd want
>> this.
>
> Not without something like @framework or @loader_path in from of them, no.
On Saturday September 12 2015 14:22:28 Jake Petroules wrote:
>
> Relative install names are useless, there is virtually no reason you'd want
> this.
Not without something like @framework or @loader_path in from of them, no.
> Many people seem to be confused by this decoupled aspect of loading
> On Sep 12, 2015, at 3:43 AM, René J.V. Bertin wrote:
>
> Hello,
>
> I've noticed another build issue on OS X that became apparent only after
> managing a full build and install.
> The default now appears to be to create shared libraries with the
> install_name containing @rpath, with the al
Hello,
I've noticed another build issue on OS X that became apparent only after
managing a full build and install.
The default now appears to be to create shared libraries with the install_name
containing @rpath, with the alternative being a fully relative install_name
(i.e. only the library na
22 matches
Mail list logo
