FreeBasic installed in /usr/lib for x86_64, but it is against policy for packaging x86_64 libraries. You should use /usr/lib64.
hardcoded-library-path in %{_prefix}/lib/freebasic
According to file system standard that's true, but it also depends on distro, doesn't it? For example Debian/Ubuntu with multiarch layout uses /usr/lib/x86_64-linux-gnu. Although I think even there /usr/lib64 still exists (and is one of the linker's default search dirs).
In a way it's similar to gcc which can also have both 32bit and 64bit libraries in the same directory under a multilib setup. An example from my OpenSUSE x86_64:
And it's worth noting that the libraries in lib/freebasic/ are "private" ones, that will be statically linked (currently anyways) (so it's somewhat similar to gcc's libgcc.a).
Honestly I'm not sure what to do yet. I'd prefer keeping it as-is, but if it's really necessary then we can also use lib64 for 64bit stuff:
A libdir=... config option could tell fbc to use lib64/freebasic/ instead of lib/freebasic/ for everything, but then the problem is not really solved, since now the 32bit libs (for cross-compiling from x86_64 to x86) are also under lib64. Same problem, just reversed.
So then something like lib32dir=... and lib64dir=...? But then what about the cross-compiling libs for ARM or other architectures? Are you going to put them into lib/freebasic/ in the cross-compiler toolchain sysroot or Debian's multiarch directories?
From the looks of it, we'd need one libdir config option for each supported target. I haven't tried that yet but it sounds ugly.
fbc already uses a model similar to multiarch for its own internal libs (multiple targets/architectures supported at the same time), and uses gcc -print-file-name=... to find the rest... it works well and is the same on every Linux system. I don't really want to make it more complicated than that. So I'm worrying not just about the libs for native compilation, but also all kinds of cross-compiling.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see problem. For RPM distros for spec file:
libdir=%{_libdir}
For 32bit it will be "libdir=/usr/lib", for 64bit it will be "libdir=/usr/lib64" automaticly.
Debian has the same macroses.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm thinking not only about native compilation, but also cross-compiling. For this, fbc needs to know the libdirs for all targets, not just one target.
Would it be possible to use symlinks here?
1. Install 64bit libs at
/usr/lib64/freebasic/linux-x86_64
(in the packaging script, it is safe to move the libs after the build)
2. symlink
from /usr/lib/freebasic/linux-x86_64
to /usr/lib64/freebasic/linux-x86_64
Then the libs would be installed inside /usr/lib64, and fbc would still find the libs (via the symlink). This could also be used for Debian's multiarch directories, or any other configurations (e.g. in case 32bit libs have to go into a /usr/lib32/ directory).
If symlinks don't work, another idea is to use a config file (e.g. lib/freebasic/libdirs.cfg) which specifies the target-specific libdirs.
The advantage is that fbc doesn't need to know the distro-specific paths, and no build configuration option is needed for FB (moving the libraries and creating the symlinks can be done manually, after the build, during the packaging process).
Last edit: dkl 2015-01-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure whether a global config file would be a good idea though - there can be multiple fbc installs with their own libdirs each. If they all read the same /etc/fbc.cfg that would be a problem.
Ideally the config file would be specific to each fbc - i.e. in the lib/freebasic/ directory belong to that fbc (much like ldscripts). And I think at that point it comes down to symlinks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
According to file system standard that's true, but it also depends on distro, doesn't it? For example Debian/Ubuntu with multiarch layout uses
/usr/lib/x86_64-linux-gnu. Although I think even there/usr/lib64still exists (and is one of the linker's default search dirs).FreeBASIC will currently use:
which I think is pretty nice.
In a way it's similar to gcc which can also have both 32bit and 64bit libraries in the same directory under a multilib setup. An example from my OpenSUSE x86_64:
(note the 32bit libs under /usr/lib64)
And it's worth noting that the libraries in lib/freebasic/ are "private" ones, that will be statically linked (currently anyways) (so it's somewhat similar to gcc's libgcc.a).
Honestly I'm not sure what to do yet. I'd prefer keeping it as-is, but if it's really necessary then we can also use lib64 for 64bit stuff:
Last edit: dkl 2014-10-19
Will you implement option for build and install? For example, libdir= and the 3rd parameter for install.sh.
I'm not sure...
A
libdir=...config option could tell fbc to uselib64/freebasic/instead oflib/freebasic/for everything, but then the problem is not really solved, since now the 32bit libs (for cross-compiling from x86_64 to x86) are also under lib64. Same problem, just reversed.So then something like
lib32dir=...andlib64dir=...? But then what about the cross-compiling libs for ARM or other architectures? Are you going to put them into lib/freebasic/ in the cross-compiler toolchain sysroot or Debian's multiarch directories?From the looks of it, we'd need one libdir config option for each supported target. I haven't tried that yet but it sounds ugly.
fbc already uses a model similar to multiarch for its own internal libs (multiple targets/architectures supported at the same time), and uses
gcc -print-file-name=...to find the rest... it works well and is the same on every Linux system. I don't really want to make it more complicated than that. So I'm worrying not just about the libs for native compilation, but also all kinds of cross-compiling.I don't see problem. For RPM distros for spec file:
libdir=%{_libdir}
For 32bit it will be "libdir=/usr/lib", for 64bit it will be "libdir=/usr/lib64" automaticly.
Debian has the same macroses.
I'm thinking not only about native compilation, but also cross-compiling. For this, fbc needs to know the libdirs for all targets, not just one target.
Would it be possible to use symlinks here?
1.Install 64bit libs at(in the packaging script, it is safe to move the libs after the build)
2.symlinkThen the libs would be installed inside /usr/lib64, and fbc would still find the libs (via the symlink). This could also be used for Debian's multiarch directories, or any other configurations (e.g. in case 32bit libs have to go into a /usr/lib32/ directory).
If symlinks don't work, another idea is to use a config file (e.g. lib/freebasic/libdirs.cfg) which specifies the target-specific libdirs.
The advantage is that fbc doesn't need to know the distro-specific paths, and no build configuration option is needed for FB (moving the libraries and creating the symlinks can be done manually, after the build, during the packaging process).
Last edit: dkl 2015-01-09
Good idea with config file. /etc is directory for configs (/etc/freebasic/libdirs.cfg or /etc/fbc.cfg).
I'm not sure whether a global config file would be a good idea though - there can be multiple fbc installs with their own libdirs each. If they all read the same /etc/fbc.cfg that would be a problem.
Ideally the config file would be specific to each fbc - i.e. in the lib/freebasic/ directory belong to that fbc (much like ldscripts). And I think at that point it comes down to symlinks.
I've added an ENABLE_LIB64 compile-time option now that makes the compiler use lib64: [00e0e0]
Related
Commit: [00e0e0]