[QBS] Post Build process to install_name_tool

olivier musse olivier.musse at sfr.fr
Fri Sep 5 10:18:00 CEST 2014


Le 04/09/2014 18:40, Jake Petroules a écrit :
> On 2014-09-04, at 12:28 PM, Christian Kandeler <christian.kandeler at digia.com> wrote:
>
>> Hi,
>>
>> On 09/04/2014 05:33 PM, olivier musse wrote:
>>> With QBS 1.3 we are trying to defined a post build process on our
>>> product (a dynamiclibrary) to call install_name_tool in order to change
>>> some library dependencies.
>>> For that we defined the following rule (MyLib is defined as a type of
>>> the product)
>>> Rule{
>>>
>>>          inputs:  ['dynamiclibrary']
>>>
>>>          Artifact  {
>>>
>>>              filePath:  input.filePath
>>>
>>>              fileTags:  "MyLib"}
>>>
>>>          prepare:  {
>>>
>>>        ......
>>>
>>>          }
>>>
>>>      }
>>>
>>>
>>> When doing that, we get a conflict rule message with the internal qbs
>>> file (GenericGCC.qbs:113:18)
>>> Apparently this is because our rule as the same file as input and output.
>> in general, the question of how to "enrich" a build artifact is an
>> unsolved problem. I think https://bugreports.qt-project.org/browse/QBS-5
>> is referring to this issue as well.
>> But for your case, why not just use cpp.installNamePrefix?
>>
>>> With previous version of QBS it was possible to do it.
>> I don't think so. Can you give an example project where you do that
>> which works with qbs 1.2 but not wit 1.3?
>>
>>
>> Christian
>> _______________________________________________
>> QBS mailing list
>> QBS at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/qbs
>
> Any solution that uses install_name_tool is, 99% of the time, a broken solution (the only valid case I can think of is where a binary-only third party library you're using has a wrong install name). Certainly for your own code, you should be using the linker flags -install_name and -rpath, which are accessible in qbs using the cpp.installNamePrefix and cpp.rpaths properties.
>
> Almost all of the time, cpp.installNamePrefix should be set to "@rpath", and cpp.rpaths should generally be @executable_path/../Frameworks or @loader_path/../Frameworks depending on where a given binary's dependencies reside (note that rpaths is a LIST, so you can have multiple search paths).
>
> Also see Apple's documentation on dyld: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html (relevant parts at the bottom).
>
> Hope that helps.
Hi,

Thanks for these informations, they are precious.
In fact we are already using the cpp.rpaths property and the 
cpp.installNamePrefix property is not documented.
Whatever this does not work for our case but perhaps we are not using it 
the right case.
Our case is the following : we develop plugins for a not Qt application 
and we need to deploy Qt with the plugins (Qt is not installed on the 
target platform and must be automatically deployed with the application)
So with the cpp.installNamePrefix, only the install_name of the 
executable is set to "@rpath" and we would like it also to be set for Qt 
library
So we have something like
  @rpath/AudioPlugin (compatibility version 0.0.0, current version 0.0.0)
  /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 57.0.0)
  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.0.0)
  /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
(compatibility version 1.0.0, current version 275.0.0)
  /usr/local/qt-5.3.0-mana/lib/QtCore.framework/Versions/5/QtCore 
(compatibility version 5.3.0, current version 5.3.0)
  /usr/local/qt-5.3.0-mana/lib/QtGui.framework/Versions/5/QtGui 
(compatibility version 5.3.0, current version 5.3.0)
  /usr/local/qt-5.3.0-mana/lib/QtNetwork.framework/Versions/5/QtNetwork 
(compatibility version 5.3.0, current version 5.3.0)
  /usr/local/qt-5.3.0-mana/lib/QtMultimedia.framework/Versions/5/QtMultimedia (compatibility version 5.3.0, current version 5.3.0)
  /usr/local/qt-5.3.0-mana/lib/QtWidgets.framework/Versions/5/QtWidgets 
(compatibility version 5.3.0, current version 5.3.0)
  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 56.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 169.3.0)
and we need to have something like
  @rpath/AudioPlugin (compatibility version 0.0.0, current version 0.0.0)
  /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 57.0.0)
  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.0.0)
  /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 
(compatibility version 1.0.0, current version 275.0.0)
@rpath/QtCore.framework/Versions/5/QtCore (compatibility version 5.3.0, 
current version 5.3.0)
@rpath/QtGui.framework/Versions/5/QtGui (compatibility version 5.3.0, 
current version 5.3.0)
@rpath/QtNetwork.framework/Versions/5/QtNetwork (compatibility version 
5.3.0, current version 5.3.0)
@rpath/QtMultimedia.framework/Versions/5/QtMultimedia (compatibility 
version 5.3.0, current version 5.3.0)
  /usr/local/qt-5.3.0-mana/lib/QtWidgets.framework/Versions/5/QtWidgets 
(compatibility version 5.3.0, current version 5.3.0)
  /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current 
version 56.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 169.3.0)

Since we are not experimented OSX developers (sorry for that) we are 
perhaps not doing well.

Many thanks in advance for you help

Regards


Olivier




More information about the Qbs mailing list