You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Ardiano, here we have one problem with libraries resolution. Currently switch -rpath is used to point ld to a place, where runtime libraries are located, and value of this switch is wrtten in all our binaries by ld. The result is that any binary (isql for example) always searchs for libfbembed.so.2.5 first in the directory, given by -rpath, and only after it - in paths, given in /etc/ld.so.conf and default paths.
Therefore if we place version of firebird, built with prefix /opt/firebird, into another location, it's isql will anyway try to use libfbembed.so.2.5 from /opt/firebird/lib. And if this is 2 different builds of 2.5 (say beta1 and rc1), one can get very unexpected results.
The only potential problem I see is as follows. I know very well that some people used to copy tools like isql, gbak, etc. to some other directories (like own working directories) in order to have eaiser access to them from something like shell scripts. Certainly, symbolic links should be used for that, but :-((
Do not think this should be a showstopper for making FB relocatable, but IMO adding a note to 'incompatibilities' is worth to do.
What about the form of it - direct use of extern files like
OS_SPECIFIC_Sources = $(addprefix jrd/, $(OS_SPECIFIC_Files)) common/dllinst.cpp \
was never used before. May be full import (like sha.cpp) will be better?