Issue Details (XML | Word | Printable)

Key: CORE-2398
Type: New Feature New Feature
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Adriano dos Santos Fernandes
Reporter: Adriano dos Santos Fernandes
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
Firebird Core

Make Firebird correct detect its installed path in Linux

Created: 30/Mar/09 10:19 AM   Updated: 12/Nov/09 02:31 PM
Component/s: Engine
Affects Version/s: 2.5 Beta 1
Fix Version/s: 2.5 Beta 2

File Attachments: 1. GZip Archive fb-reloc.diff.gz (7 kB)

Environment: Linux; Maybe others POSIX

 Description  « Hide
Currently Firebird detects it install path as the directory used in configuration (build) phase (with --prefix). The correct install path should be the one where Firebird executables/libraries are.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 31/Mar/09 07:36 AM
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 first in the directory, given by -rpath, and only after it - in paths, given in /etc/ 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 from /opt/firebird/lib. And if this is 2 different builds of 2.5 (say beta1 and rc1), one can get very unexpected results.

Adriano dos Santos Fernandes added a comment - 31/Mar/09 09:35 PM
Alex, I'm testing solution using $ORIGIN rpath more binreloc. This would make Firebird true relocatable.

I'll attach a patch here so you can look at better way to support it in Linux and maybe others platforms.

Adriano dos Santos Fernandes added a comment - 02/Apr/09 08:06 PM
Alex, here is the patch.

Can you please verify it, and the better way to support it in all possible platforms?

Alexander Peshkov added a comment - 06/Apr/09 02:36 AM
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?

All the rest appears OK.

Adriano dos Santos Fernandes added a comment - 07/Apr/09 07:42 PM
Thanks Alex. I've changed reference in Makefile to use $ROOT. Header file is still referencing extern directory.

I think better approach would be to use -Iextern and include "binreloc/binreloc.h", but leave it for now.