Hi Jakub,
On 26/08/15 05:50, Jakub Wilk wrote:
* Harshula <[email protected]>, 2015-08-26, 02:28:
2) Since m17n-config contains paths that include the <triplet>, should
m17n-config itself be placed somewhere architecture specific instead
of in /usr/bin/ ?
There is no such place for public executables. You either need to fix
the script to be identical across architectures, or remove it, or remove
the "Multi-Arch: same" annotation.
Are there some good examples of packages that are multi-arch enabled
that deal with the same issue?
Off the top of my head: #741519
Looking at the diff I sent you, fixing the script should be relative easy:
- if test "${prefix}/lib/i386-linux-gnu" != "/usr/lib"; then
- echo "-L${prefix}/lib/i386-linux-gnu ${LIBNAME}"
+ if test "${prefix}/lib/x86_64-linux-gnu" != "/usr/lib"; then
+ echo "-L${prefix}/lib/x86_64-linux-gnu ${LIBNAME}"
/usr/lib/<triplet> is already in the linker's search path, so these -L
options are needless.
--libtool)
for name in $LIBTOOLNAME; do
- echo -n "${prefix}/lib/i386-linux-gnu/lib${name}.la "
+ echo -n "${prefix}/lib/x86_64-linux-gnu/lib${name}.la "
done;
These seems to print names of *.la files that don't exist in the first
place! I'm not sure what is this option useful for anyway. Isn't libtool
supposed to find the .la files itself? (Disclaimer: I'm fairly
libtool-ignorant.) Perhaps the --libtool option should be removed. It
doesn't seem to have any users in the archive.
I'm discussing with upstream (CC'd), whether the m17n-config file can be
deprecated in favour of pkg-config.
cya,
#
