Configure issue on aarch64
I received a report from a pkgsrc user who wanted to build Hercules on their aarch64 machine.
They had built and installed the 4 helper libraries (extpkgs) in /usr/pkg/lib/hercules4sdl/lib and correspondingly passed the option --enable-extpkgs=/usr/pkg/lib/hercules4sdl to configure.
Nevertheless the build did not find them.
When I examined configure.ac I found this:
127 #--------------------------------------------------------------#
128 # Determine target CPU architecture (x86, mips, sparc, etc) #
129 #--------------------------------------------------------------#
130
131 AC_MSG_CHECKING( [target CPU architecture] )
132
133 case "$target_cpu" in
134
135 i*86|x86*)
136 hc_cv_cpu_arch=x86
137 hc_cv_pkg_lib_subdir=""
138 ;;
139
140 aarch64*)
141 hc_cv_cpu_arch=aarch64
142 hc_cv_pkg_lib_subdir="/aarch64"
143 ;;
144
and further down
3162 if test "${hc_cv_extpkg_dir}" != ""; then
3163 crypto_pkgdir="${hc_cv_extpkg_dir}"
3164 else
3165 crypto_pkgdir="${srcdir}/${crypto_pkgname}"
3166 fi
3167
3168 crypto_incdir="${crypto_pkgdir}/include"
3169 crypto_libdir="${crypto_pkgdir}/lib${hc_cv_pkg_lib_subdir}"
...
3298 LDFLAGS="$LDFLAGS -L${crypto_libdir}"
So what's happening here is that if the Hercules source package contains pre-compiled libraries, they would be in "${srcdir}/${crypto_pkgname}"/"lib${hc_cv_pkg_lib_subdir}" from lines 3165 and 3169.
Currently there are only IA32/IA64 binaries in there, but that's kind of beside the point. It's for "future expansion", let's say.
Unfortunately this effectively means that the directory specified by --enable-extpkgs is not obeyed.
What would be a good way out of this?
Something like this
3162 if test "${hc_cv_extpkg_dir}" != ""; then
3163 crypto_pkgdir="${hc_cv_extpkg_dir}"
crypto_libdir="${crypto_pkgdir}/lib"
3164 else
3165 crypto_pkgdir="${srcdir}/${crypto_pkgname}"
crypto_libdir="${crypto_pkgdir}/lib${hc_cv_pkg_lib_subdir}"
3166 fi
3167
3168 crypto_incdir="${crypto_pkgdir}/include"
times 4?
I'll work with you to clean this up.
Bill
(PING?)
Status?
@wrljet ? Are you still alive? Just wondering what the status of this issue is. Should it maybe be changed to "OnGoing" ("Issue is long-term. Variant of IN PROGRESS: it's being worked on but maybe not at this exact moment.")? Thanks.
Yes, I'm still alive.
I haven't looked at that issue.
Bill
I haven't looked at that issue.
Ah. Okay. That's fine. I'm not trying to rush you or anything! I just noticed that last comment from you (to Rhialto) was: "I'll work with you to clean this up", so I was just wondering how it was going, that's all.
I think it can be solved as I proposed, but it is a bit repetitive, so I was wondering if there is a more elegant method.
I think it can be solved as I proposed, but it is a bit repetitive, so I was wondering if there is a more elegant method.
for loop?? (or however you do it in bash?)
I had a look at that, but it won't be so great. The autoconf code for the 4 required libraries is very similar, but it is mostly assignments of variables, and those differ for the 4 cases. It goes like this (that is the proposed changed version already):
#------------------------------------------------------------------------------
# crypto
#------------------------------------------------------------------------------
crypto_pkgname="crypto" # case matters!
crypto_libname="lib${crypto_pkgname}${hc_cv_pkg_lib_suffix}.a"
if test "${hc_cv_extpkg_dir}" != ""; then
crypto_pkgdir="${hc_cv_extpkg_dir}"
crypto_libdir="${crypto_pkgdir}/lib"
else
crypto_pkgdir="${srcdir}/${crypto_pkgname}"
crypto_libdir="${crypto_pkgdir}/lib${hc_cv_pkg_lib_subdir}"
fi
crypto_incdir="${crypto_pkgdir}/include"
crypto_headers="${crypto_incdir}/aes.h \
${crypto_incdir}/crypto.h \
${crypto_incdir}/sha1.h \
${crypto_incdir}/sha256.h \
${crypto_incdir}/sshdes.h"
You could make the variable names variable in bash, but it won't be pretty.
Furthermore, the last bits, with the header names, does differ a lot between the 4.
Another approach could be to reset variable hc_cv_pkg_lib_subdir to empty, if the user used the --enable-extpkgs option. It would be briefer, but on the whole more complex, since then it is less easy to find out by inspection what value the variable would have.
So in all, repeating the same change 4 times seems the least ugly for now. I prepared a ~merge~ pull request to that effect, so you can see what it looks like: #681
PR #681 Merged! (commit 1b955f4b035a0bb71fc712cd7b849d643c2a48e1)
Closing.