:: Re: [DNG] Harbour programming langu…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Didier Kryn
Fecha:  
A: dng
Asunto: Re: [DNG] Harbour programming language
Le 18/10/2023 à 12:46, Olaf Meeuwissen via Dng a écrit :
> Hi Marc,
>
> Marc Shapiro via Dng <dng@???> writes:
>
>> On 10/16/23 02:34, Olaf Meeuwissen wrote:
>>
>>>   I also got the impression you hadn't re-run ./configure after installing
>>> the extra packages.  You probably should have and maybe even recompile
>>> from scratch.  I would the re-./configure to pick up on the location of
>>> dietlibc, assuming harbour supports its use, and then add the necessary
>>> linker flag to the gcc invocation.
>> I would do that, if 'configure' was present anywhere in the source
>> tree that I downloaded.  Unfortunately, it is not.  I am using the
>> Makefile that came with the source.
> Sorry about that.  For some reason incorrectly assumed harbour used
> automake/autoconf.  My bad.
>
> Your initial mail said
>
>    make[2]: *** [../../config/lib.mk:68: descend] Error 2gcc  -I. -I../../../../../include -W -Wall -O3 -DHB_LEGACY_TYPES_OFF -DHB_HAS_PCRE -I/usr/local/harbour/harbour-3.0.0/src/3rd/pcre -DPCRE_STATIC -DHB_HAS_ZLIB -I/usr/include  -oarc4.o  -c ../../../arc4.c
>    ../../../arc4.c:80:15: fatal error: sys/sysctl.h: No such file or directory
>       80 | #     include <sys/sysctl.h>
>          |               ^~~~~~~~~~~~~~
>    compilation terminated.
>    make[3]: *** [../../../../../config/rules.mk:97: arc4.o] Error 1
>    make[2]: *** [../../config/lib.mk:68: descend] Error 2
>
> A note to everyone else that chimed in, this says <sys/sysctl.h>, *not*
> <linux/sysctl.h>.  The former was removed from glibc in 2.32.  If you
> have an older glibc, like on Chimaera, you should still have it.
>
> I suggested installing dietlibc-dev which still provides this file, even
> in Daedalus.  After you installed it, the above error changed to
>
>    gcc -L../../../../../lib/linux/gcc -L/usr/X11R6/lib64 -L/usr/X11R6/lib   -o../../../../../bin/linux/gcc/hbmk2 hbmk2.o -lhbextern -lhbdebug -lhbvmmt -lhbrtl -lhblang -lhbcpage -lgtcgi -lgtpca -lgtstd -lgtcrs -lgtsln -lgtxwc -lgttrm -lhbnulrdd -lhbrtl -lhbvmmt -lhbmacro -lhbcplr -lhbpp -lhbcommon -lhbpcre -lncurses -lslang -lX11 -lgpm -lz -lrt -ldl -lpthread -lm
>    /usr/bin/ld: ../../../../../lib/linux/gcc/libhbrtl.a(arc4.o): in function `arc4_stir':
>    arc4.c:(.text+0x470): undefined reference to `sysctl'
>    collect2: error: ld returned 1 exit status
>
> This means that the compiler found <sys/sysctl.h> but could not find the
> library that provides the sysctl() implementation.  That library is part
> of the dietlibc-dev package.  Getting the compiler to find the library
> would involve adding a -L option with a path to the directory holding
> the library and a -l with the library file's name, minus the `lib`
> prefix and file extension.  You could copy the above gcc line and edit
> it to do so or look into the Makefile that sets it up.
>
> However, looking at the list of files that the package includes I cannot
> tell which of the many libraries, the lib*.a, files.  Also, it might not
> play nice with the default libc linkage.  On top of that, reading the
> package description I now think trying to use dietlibc-dev is a good
> idea.
>
> Sorry to have sent you down a dead-end but I think your best bet is to
> build this on Chimaera (or earlier).
>
> Hope this helps,



    I have followed a little bit this thread and understood that the
SYSCTL system-call had been removed from the kernel a while ago.
Therefore looking for a library which provides a wrapper for this
system-call looks vain, since the wrapper will invoke syscall(SYSCTL)
which will necessarily fail with error ENOSYS.

    AFAIU, the only way to repair the software is by using the Linux
proper ABI, wich means replacing the call to sysctl() by some new
function which performs the necessary reads/writes into /proc/sys.

    Unless dietlibc's wrapper were actually a big and complicated
function able to translate all possible sysctl()  arguments into I/O
requests to /proc/sys. This would be an interesting compatibility layer
between Linux and BSD, but I doubt it is so. Instead this is probably
the reason why the symbol is not resolved at link time -- sysctl() is
just not compiled when building dietlibc for Linux, for the reason
explained above.

    Hope this helps.

--     Didier