0

I can successfully cross-compile boost on windows targeting QNX OS (x86) using the following command: b2 toolset=qcc target-os=qnx threadapi=pthread

However, of some reason, it seems like the resulting library files don't link correctly to the internal dependencies.

For example doing an objdump on the unit-test-framework results in:

Dynamic Section:
   NEEDED               bin.v2\libs\timer\build\qcc\release\target-os-qnx\threadapi-pthread\threading-multi\libboost_timer-qcc-mt-1_60.so.1.60.0
   NEEDED               bin.v2\libs\system\build\qcc\release\target-os-qnx\threadapi-pthread\threading-multi\libboost_system-qcc-mt-1_60.so.1.60.0
   NEEDED               libm.so.2
   NEEDED               libc.so.3

As you can see there is a ridiculous path to link to both the timer and the system library (also QNX, like linux, interpret '\' as an escape-char so I can't use the folder-structure in the QNX machine). I've manually edited the library's binary-file and removed the path (I know this is very risky...) to:

Dynamic Section:
   NEEDED               libboost_timer-qcc-mt-1_60.so.1.60.0
   NEEDED               libboost_system-qcc-mt-1_60.so.1.60.0
   NEEDED               libm.so.2
   NEEDED               libc.so.3

Which works. Is it possible to force Boost to not include the entire path into the library? Is this a boost issue or the QNX 6.6 qcc toolchain issue? I really don't want to edit each library's binary file manually...

A.Fagrell
  • 1,052
  • 8
  • 21
  • It seems to me you didn't use the `install` (or even `stage`) steps of the build process. That would collect all the relevant output of the compilation from the complex hierarchy of build directories, and put all the binaries into one location. – Dan Mašek May 26 '16 at 13:59
  • @DanMašek As far as I understand it should be `stage` by default. The output files are built to boost_root\stage\lib\ – A.Fagrell May 26 '16 at 14:12
  • Oh, I see. Interesting. – Dan Mašek May 26 '16 at 14:17

1 Answers1

0

The property that directly controls this is called hardcode-dll-paths, which is true by default to make it more convenient during development. The 'install' metatarget explicitly changes this to false, so that binaries you mean for installation don't refer to build tree. It sounds like you've used a build process that is not using either install or stage targets?

Vladimir Prus
  • 4,600
  • 22
  • 31
  • Sorry for late comment, I haven't tried your solution until now. Unfortunately, neither install or stage seem to solve this. I get the same results, the dll-paths is still using the build tree. Is it possible to change `hardcode-dll-paths` in another way other than using `install` or `stage`? Any ideas? Thanks – A.Fagrell Aug 02 '16 at 14:38
  • Could you try specifying `hardcode-dll-paths=false` on the command-line to b2? – Vladimir Prus Aug 02 '16 at 22:54
  • Thanks for the help, however it is still the same result. Running following command: `b2 stage hardcode-dll-paths=false toolset=qcc target-os=qnx threadapi=pthread`. Also tried running the same command through a Linux bash shell, but result is the same. Any more ideas? – A.Fagrell Aug 04 '16 at 10:18
  • I'm sorry but I still need to hardcode the correct path in the binary to make it work. Do you have any idea what could be the problem? Thanks – A.Fagrell Sep 19 '16 at 14:03