Current aquavcl breaks in dtrans. It is not needed for vcl, but very often it
builds before vcl -> breaks my builds:

=============
Building project dtrans
=============
/Volumes/Build/oo/AQUA/BuildDir/ooo_SRC680_m176_src/dtrans/source/generic
dmake: Executing shell macro: xml2cmp -types stdout
$(MISC)$/$(COMP1TYPELIST)$($(WINVERSIONNAMES)_MAJOR).xml
-------------
/Volumes/Build/oo/AQUA/BuildDir/ooo_SRC680_m176_src/dtrans/source/cnttype
dmake: Executing shell macro: xml2cmp -types stdout
$(MISC)$/$(COMP1TYPELIST)$($(WINVERSIONNAMES)_MAJOR).xml
-------------
/Volumes/Build/oo/AQUA/BuildDir/ooo_SRC680_m176_src/dtrans/source/X11
dmake: Executing shell macro: xml2cmp -types stdout
$(MISC)$/$(COMP1TYPELIST)$($(WINVERSIONNAMES)_MAJOR).xml
Nothing to build for Mac OS X
/Volumes/Build/oo/AQUA/BuildDir/ooo_SRC680_m176_src/dtrans/source/aqua
dmake: Executing shell macro: xml2cmp -types stdout
$(MISC)$/$(COMP1TYPELIST)$($(WINVERSIONNAMES)_MAJOR).xml
-------------
regcomp -register -r ../../unxmacxp.pro/bin/dtransaqua.rdb -c dtransaqua680mxp
terminate called after throwing an instance of
'com::sun::star::registry::CannotRegisterImplementationException'
Abort
dmake:  Error code 134, while making 'ALL'
'---* tg_merge.mk *---'

ERROR: Error 65280 occurred while making
/Volumes/Build/oo/AQUA/BuildDir/ooo_SRC680_m176_src/dtrans/source/aqua

This is what I found during some investigation:

> I have compiled cppuhelper with debug and even extended it a bit and
> probably found some trace of error. Hope it helps you to track this issue
> further. I have added debugging to cppuhelper/source/shlib.cxx's
> makeComponentPath:
> 
>> implementation com.sun.star.security.comp.stoc.AccessController supports:
com.sun.star.security.AccessController
> PJ: makeComponentPath (security.uno.dylib,
file:///Volumes/Build/oo/AQUA/BuildDir/ooo_SRC680_m172_src/solver/680/unxmacxp.pro/lib)
> Thread:      1 :component
path=file:///Volumes/Build/oo/AQUA/BuildDir/ooo_SRC680_m172_src/solver/680/unxmacxp.pro/lib/security.uno.dylib
> 
> PJ: leaving makeComponentPath.
>> implementation com.sun.star.security.comp.stoc.FilePolicy supports:
com.sun.star.security.Policy
> PJ: makeComponentPath (dtransaqua680mxp, )
> Error: File
/Volumes/Build/oo/AQUA/BuildDir/ooo_SRC680_m172_src/cppuhelper/source/shlib.cxx,
Line 254: dtransaqua680mxp
> Thread:      1 :component path=libdtransaqua680mxp.dylib
> 
> PJ: leaving makeComponentPath.
> terminate called after throwing an instance of
'com::sun::star::registry::CannotRegisterImplementationException'
> Abort
> dmake:  Error code 134, while making 'ALL'
> 
> It somehow fails on dtransaqua680mxp, because this lib is not yet delivered
> into the solver. I copied it to the solver and it was then registered
> successfully. Looks like this is somehow connected to bootstrapping
> mechanisms or something similar? What is also interesting is that the
> library is not called how it is stored in the filesystem
> (libdtrans....dylib) but it is called as dtransaqua680mxp in
> makeComponentPath.

ause asked jsc how the components are loaded.

Juergen replied with:

   > The component itself is simply loaded via osl_loadModule and have to be 
   > specified with a full qualified path or an appropriate LD_LIBRARY_PATH. 
   > Especially the later one is important to find dependent libraries if no 
   > correct rpath option is used. But of course under Unix we use a correct 
   > rpath option nowadays.

I tried it:

macmini:~/AQUA/BuildDir/ooo_SRC680_m176_src/dtrans/source/aqua oo$ export
LD_LIBRARY_PATH=../../unxmacxp.pro/lib/
macmini:~/AQUA/BuildDir/ooo_SRC680_m176_src/dtrans/source/aqua oo$ dmake
dmake: Executing shell macro: xml2cmp -types stdout
$(MISC)$/$(COMP1TYPELIST)$($(WINVERSIONNAMES)_MAJOR).xml
-------------
regcomp -register -r ../../unxmacxp.pro/bin/dtransaqua.rdb -c dtransaqua680mxp
register component 'dtransaqua680mxp' in registry
'../../unxmacxp.pro/bin/dtransaqua.rdb' succesful!
macmini:~/AQUA/BuildDir/ooo_SRC680_m176_src/dtrans/source/aqua oo$ 

- it works.

So the question is:

- should we set LD_LIBRARY_PATH before the regcomp call

or

- is there any other problem we are workarounding by this change (connected to
bad rpath or ?)