hyperion icon indicating copy to clipboard operation
hyperion copied to clipboard

Configure issue on aarch64

Open Rhialto opened this issue 1 year ago • 8 comments

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?

Rhialto avatar Apr 05 '24 20:04 Rhialto

I'll work with you to clean this up.

Bill

wrljet avatar Apr 06 '24 02:04 wrljet

(PING?)

Status?

Fish-Git avatar Jul 23 '24 19:07 Fish-Git

@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.

Fish-Git avatar Aug 27 '24 18:08 Fish-Git

Yes, I'm still alive.

I haven't looked at that issue.

Bill

wrljet avatar Aug 27 '24 18:08 wrljet

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.

Fish-Git avatar Aug 27 '24 18:08 Fish-Git

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.

Rhialto avatar Aug 28 '24 09:08 Rhialto

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?)

Fish-Git avatar Aug 28 '24 23:08 Fish-Git

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

Rhialto avatar Aug 29 '24 18:08 Rhialto

PR #681 Merged! (commit 1b955f4b035a0bb71fc712cd7b849d643c2a48e1)

Closing.

Fish-Git avatar Aug 31 '24 05:08 Fish-Git