El 21 de mayo de 2024 17:05:12 CEST, Rhialto <rhia...@falu.nl> escribió:
>On Mon 20 May 2024 at 22:20:30 +0200, Ramiro Aceves wrote:
>> AC_PREREQ(2.50)
>> AC_INIT(xmain.c)
>> AC_MSG_CHECKING([OS])
>> AC_CONFIG_FILES([Makefile])
>> AC_CONFIG_FILES([ft245.c])
>> BITS=`(getconf LONG_BIT)` <<<<------------Here
>> AC_SUBST(BITS)
>
Thanks Rihalto for answering. Sorry for delay, no free time to play with NetBSD
in the last days.
>I have also seen some programs that just want to know the "bitness" so
>that they can call the library they produced "libfoo32" or "libfoo64"
Yes, you are right, I think that is the reason.
>That seems to be out of some sort of habit for MSWindows or even Linux
>programs. But for NetBSD this is almost never relevant since pretty much
>all programs you build and run are for the "natural" size. In my case, I
>had to teach the packages to just create and use "libfoo" without
>numbers.
>
>If this is the case for this package, you could try and do the same.
>
>If the packge wants to know the bitness so that it can use the right
>types for typedefs or something like that, then you could change it to
>use int32_t and int64_t unconditionally.
>
>In both cases I would call this bugs and would report upstream. Even if
>you only determine that one of these scenarios is what's happening, and
>you don't manage to fix it.
>
>-Olaf.
After talking with upstream we agreed making the fewest changes in the code
just to make it work. Upstream suggested to add fixes to make it work under
FreeBSD cause years ago it worked in that OS (they have a port for an older
version) first and after that, try NetBSD. In the former I could get it work at
least partially. So we are moving towards the goal...not too much free time, we
move slowly.
Learning many thinks, I am very newbie in every aspect.
Regards.
Ramiro.
