Issue 77360

Weired thing is:

Despite berkeleydb was already built, rebuilding & delivering it again allows
desktop module to build successfully.

e.g. 
cd berkeleydb
rm -rf unxmacxp.pro # without this, nothing is rebuilt or redelivered
build
build --deliver
cd desktop
build

And desktop builds fine.

So whatever it is, I suspect it is a parallel build issue with berkeleydb -
something that has been built in the meantime apparently solves the problem. But
I don't have a clue what would affect this module. Unfortunately a whole lot of
modules were built in between berkeleydb and desktop, so I don't have a clue
what module could be missing.

Please check its' install_name.

Please run otool -L on it.

sorry for the delay, but here's the result:

$ otool -L berkeleydb/unxmacxp.pro/lib/libdb-4.2.dylib
solver/680/unxmacxp.pro/lib/libdb-4.2.dylib
berkeleydb/unxmacxp.pro/lib/libdb-4.2.dylib:
        /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.dylib (compatibility version
0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
88.1.9)
solver/680/unxmacxp.pro/lib/libdb-4.2.dylib:
        /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.dylib (compatibility version
0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
88.1.9)

So both the in-module version as well as the delivered one contain the hardcoded
path with /usr/local

The compiler/link line from the logs reads like this:

gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libdb-4.2.dylib 
.libs/mut_tas.o [many other .o files] .libs/xa_map.o  -install_name 
/usr/local/BerkeleyDB.4.2/lib/libdb-4.2.dylib

It uses -install_name with that hardcoded path.

The deliver-line on stdout prints:
LINK: ../unxmacxp.pro/lib/libdb-4.2.dylib ->
/Users/buildslave/compile/shadow/solver/680/unxmacxp.pro/lib/libdb-4.2.dylib

But deliver.log in solver reads
COPY berkeleydb/unxmacxp.pro/lib/libdb-4.2.dylib unxmacxp.pro/lib/libdb-4.2.dylib

(not sure whether that difference is relevant at all, I doubt it)

Here:

Macintosh:~/BUILD/X11/BuildDir/ooo_OOF680_m17_src pavel$ otool -L solver/680/unxmacxi.pro/lib/
libdb-4.2.dylib berkeleydb/unxmacxi.pro/lib/libdb-4.2.dylib 
solver/680/unxmacxi.pro/lib/libdb-4.2.dylib:
        @executable_path/libdb-4.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.7)
berkeleydb/unxmacxi.pro/lib/libdb-4.2.dylib:
        @executable_path/libdb-4.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.7)
Macintosh:~/BUILD/X11/BuildDir/ooo_OOF680_m17_src pavel$ 

Are you really building m206? maybe it was fixed later...

Yes, that was while building jimmactango3 - at the time of building (and I guess
still now) based on m206

But since tinderbox did build all milestones without problem, and that same cws
without problem on other occasion, and since rm -rf'ing berkeleydb's output-dir
and building only that module again "fixes" the problem, I didn't think it
depends on the milestone at all. But one can be so mislead...

But now I think I got the problem:

While building the first time, I used --dlv_switch -link, when rebuilding I
didn't specify it.

It seems that when using link, it sometimes fails. This is not an issue with
newer milestones that already have @executable_path in the -install_name flag
(from m207 on), but when it relies on deliver to clean up.

Thanks for thinking with (for) me - sometimes you just don't see clear when only
talking with yourself.

###################################
Summary:

* building with "--dlv_switch -link" and < m207 breaks
* building without that switch or a milestone >= m207 works fine

Worth to investigate deliver's behaviour further? Or close as worksforme? 

These two facts are incompatible:

1. deliver is changing the install_name of delivered libraries, thus the library in the local output tree is 
different from the library in the solver.

2. using links in deliver.

@cloph

Is the issue fixed, or pending, or ...  ?

Well - the question is whether it is worth to fix deliver for that case
(when deliver should rewrite info in the lib) or not. I mean the specific
problem with berkeleydb is fixed by compiling/linking it with the right flags
from the beginning...

So I guess it is "worksforme"

Berkeley DB is not used anymore due to license concerns so it would be surprising to see this error again.

see comment #9