Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make Firebird correct detect its installed path in Linux [CORE2398] #2817

Closed
firebird-automations opened this issue Mar 30, 2009 · 10 comments
Closed

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @asfernandes

Attachments:
fb-reloc.diff.gz

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.

Commits: 0f0c4d0 8db711c

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

assignee: Adriano dos Santos Fernandes [ asfernandes ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

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.

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

Alex, here is the patch.

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

Attachment: fb-reloc.diff.gz [ 11433 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

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 \
../extern/binreloc/binreloc.c
was never used before. May be full import (like sha.cpp) will be better?

All the rest appears OK.

@firebird-automations
Copy link
Collaborator Author

Commented by: @asfernandes

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.

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

issuetype: Improvement [ 4 ] => New Feature [ 2 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @asfernandes

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.5 RC1 [ 10300 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants