32bit compatibility


  • Netgate Administrator

    Hi all.
    Is there supposed to be 32bit compatibility on 64bit installs? I see this during boot:

    Creating symlinks......ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib
    32-bit compatibility ldconfig path: /usr/lib32
    done.
    

    But my 32 bit binary doesn't run giving instead only:

    [2.2-ALPHA][root@pfsense.localdomain]/tmp(20): /conf/WGXepc
    ELF interpreter /libexec/ld-elf.so.1 not found
    Abort
    
    

    Should this work or should I stop head scratching and move on?

    Steve


  • Rebel Alliance Developer Netgate

    I'm not certain it's ever officially been stated to work. It's probably got some necessary files that aren't being copied (or are being removed) during the build process.



  • FreeBSD does officially support using i386 binaries on amd64 assuming the lib32 compatibility libraries (/lib32 /usr/lib32 etc.) are installed and COMPAT_FREEBSD32 option is used in the kernel. It should work on pfSense but why do you need that? Do you have a binary only program that is only available for i386?


  • Netgate Administrator

    There is no good reason to have 32 compatibility on a firewall as far as I can see. I could only server to increase the attack surface. I am not asking to have it enabled if it isn't already just wondering if it is supposed to be included and is broken.
    Yes I have a program which I "wrote" (in the loosest possible terms!) which I compiled against FreeBSD 32bit. Until this point I've never tried to use it on a 64bit install. The obvious solution to this would be to re-compile it against a 64bit FreeBSD install but I seem to be having some problems doing that and my coding skills are very limited.  ::)

    The code uses some functions from some standard librarires that are pretty obviously i386:

    /*Use i386_get_ioperm, i386_set_ioperm from <machine sysarch.h=""> and inb and outb from <machine cpufunc.h=""> (FreeBSD) */</machine></machine>
    

    They won't compile against 64bit FreeBSD. The obvious answer is to swap them for amd64_get_ioperm etc which exist but also don't compile. That section of code is borrowed from lcdproc which does compile for 64bit so there is probably something very easy I don't know about. The program is very basic, originally it merelt turned on and off an LED.  ;) It's sufficiently basic that I originally compiled it against 8.1 and it ran fine on 8.3 ans still runs fine on 10. I compile it by calling gcc directly.
    Any help much appreciated.

    Steve



  • Just open /dev/io it will do the right thing for you!
    Then just rin the same code you did before ;)

    Normally amd64 should not have those calls with amd64_ prefix, iirc.


  • Netgate Administrator

    Thanks for that Ermal.  :)
    Interestingly looking at the most recent lcdproc file that uses these functions here:
    http://lcdproc.cvs.sourceforge.net/viewvc/lcdproc/lcdproc/server/drivers/port.h?revision=1.18.2.4&view=markup
    The FreeBSD section still uses i386_set_ioperm, however there is code that doesn't.

    Using /dev/io seems like cheating.  ;)
    It open all ports at once, no need to specify it, and there's no requirement to close the port afterwards. Also seems a bit resource wasteful maybe. Still, I know nothing!

    I'm sure I can get going using this.

    Steve



  • 
    #if (__FreeBSD_version > 500000)
    299	        if (port_access_handle
    300	            || (port_access_handle = fopen("/dev/io", "rw")) != NULL) {
    301	                return i386_set_ioperm(port, 1, 1);
    302	        }
    303	        else {
    304	                return (-1);    /* Failure */
    305	        };
    306	#else
    307	        return i386_set_ioperm(port, 1, 1);
    308	#endif
    
    

    from the link you attached seems what i suggested is about right, use /dev/io


Log in to reply