Use of a Linux CUPS driver that contains a binary?

I am wondering if it is possible to use a Linux printer driver for CUPS that contains a filter program binary in FreeBSD.

Specifically this is about the MUNBYN ITPP941 label printer for which the Linux CUPS driver can be downloaded here.

That driver consists of a Beeprt.ppd and a rastertolabelbeeprt binary, and comes with a install/uninstall shell scripts for Ubuntu x86_64.

Is such a binary OS independent and only relying on CPU architecture, or is there any possible connection to FreeBSD's Linux binary compatibility?
 
I think that the first thing to do is change the path prefix in the installation script from /bin tu /sur/bin and so
 
I think that the first thing to do is change the path prefix in the installation script from /bin tu /sur/bin and so
Thanks for the hint, I know about the differences in file system paths. What I don't know is the actual issue, so if such a driver will work with FreeBSD despite it not only containing a PPD file, but a binary filter file as well.
 
Try file(1) on it, it should tell you what it is. If it is an actual compiled binary, it will be OS-specific.

Is such a binary OS independent and only relying on CPU architecture
This is generally impossible. You can't even write to stdout without issuing syscalls. So, even assuming a compatible binary format (ELF) and static linking, such a program wouldn't be able to achieve anything observable.

It might still be possible to get it to work using "Linuxulator". I assume CUPS filters communicate with pipes, so this could actually work.
 
Try file(1) on it, it should tell you what it is. If it is an actual compiled binary, it will be OS-specific.
Code:
$ file rastertolabelbeeprt
rastertolabelbeeprt: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=0d5e4c1ab244c46a8ccbf0dc9a3df7894d74dfe5, with debug_info, not stripped
So impossible to make use of it?
Failing that, there is a rastertolabel.c source available, which claims support for Munbyn ITPP941 label printers. So you could just try to compile it into a binary that runs under FreeBSD.
Nice! So how to compile that one under FreeBSD?
 
This is generally impossible. You can't even write to stdout without issuing syscalls. So, even assuming a compatible binary format (ELF) and static linking, such a program wouldn't be able to achieve anything observable.
I don't believe this is true. There is a large section in the FreeBSD handbook on Linux Binary Compatibility; specifically, it goes over how to install Linux ELF binaries, RPMs, and Linux shared libraries.

See below (emphasis mine)
When the ELF loader sees the Linux brand, the loader replaces a pointer in the proc structure. All system calls are indexed through this pointer. In addition, the process is flagged for special handling of the trap vector for the signal trampoline code, and several other (minor) fix-ups that are handled by the Linux® kernel module.

The Linux® system call vector contains, among other things, a list of sysent[] entries whose addresses reside in the kernel module.
When a system call is called by the Linux® binary, the trap code dereferences the system call function pointer off the proc structure, and gets the Linux®, not the FreeBSD, system call entry points.

Linux® mode dynamically reroots lookups. This is, in effect, equivalent to union to file system mounts. First, an attempt is made to lookup the file in /compat/linux/original-path. If that fails, the lookup is done in /original-path. This makes sure that binaries that require other binaries can run. For example, the Linux® toolchain can all run under Linux® ABI support. It also means that the Linux® binaries can load and execute FreeBSD binaries, if there are no corresponding Linux® binaries present, and that a uname(1) command can be placed in the /compat/linux directory tree to ensure that the Linux® binaries cannot tell they are not running on Linux®.

In effect, there is a Linux® kernel in the FreeBSD kernel. The various underlying functions that implement all of the services provided by the kernel are identical to both the FreeBSD system call table entries, and the Linux® system call table entries: file system operations, virtual memory operations, signal delivery, and System V IPC. The only difference is that FreeBSD binaries get the FreeBSD glue functions, and Linux® binaries get the Linux® glue functions. The FreeBSD glue functions are statically linked into the kernel, and the Linux® glue functions can be statically linked, or they can be accessed via a kernel module.

Technically, this is not really emulation, it is an ABI implementation. It is sometimes called "Linux® emulation" because the implementation was done at a time when there was no other word to describe what was going on. Saying that FreeBSD ran Linux® binaries was not true, since the code was not compiled in.Quoted from
- from https://docs.freebsd.org/en/books/handbook/linuxemu/
 
So impossible to make use of it?
Not necessarily, but as I wrote, you'd need the Linuxulator to run it. But:
Failing that, there is a rastertolabel.c source available, which claims support for Munbyn ITPP941 label printers.
it's always the better idea to look out for open-source doing what you need and build it on/for FreeBSD.
I don't believe this is true.
Because you misread what exactly is impossible:
There is a large section in the FreeBSD handbook on Linux Binary Compatibility
FreeBSD provides a Linux ABI, which means the kernel implements (almost) all the Linux syscalls, yes. This doesn't make the binary in question "OS independent". What's impossible is to have an OS independent binary running on an OS, cause it could never do any I/O. Short of accessing hardware directly (which is prevented for good reasons; on any CPU of the last decades, this requires running in a privileged mode), doing I/O means interfacing with the OS. So, any binary is OS-specific.
 
What's impossible is to have an OS independent binary running on an OS, cause it could never do any I/O. Short of accessing hardware directly (which is prevented for good reasons; on any CPU of the last decades, this requires running in a privileged mode), doing I/O means interfacing with the OS. So, any binary is OS-specific.
We might be disagreeing on semantics at this point, but Justine Tunney has released an impressive C library and executable format which makes C binaries completely portable (every Linux distro, macOS, Windows NT, Windows 10, and the BSDs). Build once, run (almost) anywhere. Granted, it's kind of a hack, but what isn't?

Cosmopolitan makes C a build-once run-anywhere language, similar to Java, except it doesn't require interpreters or virtual machines be installed beforehand. Cosmo provides the same portability benefits as high-level languages like Go and Rust, but it doesn't invent a new language and you won't need to configure a CI system to build separate binaries for each operating system. What Cosmopolitan focuses on is fixing C by decoupling it from platforms, so it can be pleasant to use for writing small unix programs that are easily distributed to a much broader audience.
Links:

 
get the source tingo linked above
install cups
comment out third and fourth include (the ones with private)

cc -o rastertolabel -D_= -I /usr/local/include/ rastertolabel.c -L /usr/local/lib -l cups
ignore the warnings
use the resulting binary and the ppd from linux package
hope it works
 
We might be disagreeing on semantics at this point, but Justine Tunney has released an impressive C library and executable format which makes C binaries completely portable (every Linux distro, macOS, Windows NT, Windows 10, and the BSDs). Build once, run (almost) anywhere. Granted, it's kind of a hack, but what isn't?
Oh, that's a nice toy and definitely cool as hell, but of course, this binary still interfaces with the OS. It just contains wonderful trickery to interface with different systems.

In practice, this will find its limitations pretty quickly. Any library you'd want to use (other than the C library it directly accounts for) would need to be built with the same trickery. And if this library abstracts away vastly different APIs of different systems (like e.g. a toolkit like Qt does), you're up to a job that could be solved in theory…

Needless to say you're "frozen in time" with this approach as well. Unless of course this project is updated and you, well, recompile your "portable binary" ;)

But then, sure, it might be possible to write a CUPS filter using this. I don't expect any vendor to do it, though.
 
Cosmopolitan Libc doesn't have any limitations. It's a project that lets you write 16kb static binaries that run on seven different operating systems. Goal is to restore the dream of UNIX philosophy of having many small programs. In terms of dependencies, we've actually compiled several high level languages with it like Python, Lua, and JavaScript. So any code you write in those languages can be a portable single-file binary too. We also have a live FreeBSD demo of a multi-platform web server binary we wrote, called redbean, which you can visit here: http://redbean.justine.lol/
 
Hello I wrote Cosmopolitan Libc if you have any questions. I tried posting a comment earlier but I might be banned already.
 
New members' posts are moderated. A post will be approved when a moderator has time. Be patient.
 
Thank you DutchDaemon and for the work you do too, administrating this community. I'm excited to join. I've been using FreeBSD since I was kid because my algebra teacher bought a shrink-wrapped version for me as a reward for doing homework. So as you can imagine it's an operating system that's close to heart for me, and I love how it continues to have a strong community that's committed to technical excellence.
 
I tried posting a comment earlier but I might be banned already.
The original question is about being able to run a (possible) Linux binary from a printer driver and use it as a FreeBSD printer driver. For some reason it evolved into a thread about running various different binaries from different OSes and your post was just a step too far off-topic. That's why I initially deleted it.
 
A ppd is platform independent.
And there is also "cups-filters" & "foomatic-filters" which sometimes can be used.
The PPD part is not the issue, as it can just be used as provided, but cups-filters and foomatic-filters just don't contain the filter needed for the desired label printer (I already checked the CUPS repository, the original rastertolabel.c has last been updated more than 1.5 years ago and doesn't contain the needed model number, however the version from the forked repo as mentioned above does).

I'm currently not able to play around with this as I have no machine running FreeBSD ready yet (was waiting for FreeBSD 13 to give it a new try), and the printer will not arrive before next week, so I was asking beforehand to get an idea if it will be possible to make use of this one or the other way.
 
Thank you for restoring my comments. I'm here not to promote myself. Someone brought up my systems interface research earlier. Portable binaries seem off topic but that's not the point. It's simply an example of one of the use-cases that research knowledge can enable.

To see the research, take a look at consts.sh and syscalls.sh which are the magic numbers files explained in further detail by the APE Blob Post. This is a famous hack that was published last year. Lots of effort went into collecting that information in one easy to read place.

If I understand correctly, what you want to do here is leverage binary code from Linux and other kernels, which are hardcoded to assume that magic numbers conform to the first column in the above charts. If you copy those numbers tables, then you might be able to have FreeBSD more easily integrate and benefit from works sourced from other codebases.
 
jart, and the meaning of all of this is what exactly in this specific context with that specific driver issue with a Linux filter binary for CUPS?
 
OK so looking at the filter binary in question, it appears to be a simple stdio program that dynamically links glibc. It's small enough that if I needed it, I'd probably disassemble and reassemble it into something static. Printer companies ideally should change their practices to not release binaries that only run on Ubuntu. Next time you're in contact with one, suggest to them the benefits of writing simple stdio programs such as this using Cosmopolitan Libc instead, since it'll grant their work a broad audience across platforms.
 
OK so looking at the filter binary in question, it appears to be a simple stdio program that dynamically links glibc. It's small enough that if I needed it, I'd probably disassemble and reassemble it into something static. Printer companies ideally should change their practices to not release binaries that only run on Ubuntu. Next time you're in contact with one, suggest to them the benefits of writing simple stdio programs such as this using Cosmopolitan Libc instead, since it'll grant their work a broad audience across platforms.
Thanks for taking a look, obviously no company will listen to any kind of such user feedback, so it's not even worth trying.

So it's out of question that that one binary will just work with FreeBSD, right?

Just curious, since the mentioned patched rastertolabel.c should do the job just fine as well.

Too bad, that the patch will not make it into upstream and I'm not sure about LPrint - A Label Printer Application, since it hasn't been ported either (yet).
 
Specifically this is about the MUNBYN ITPP941 label printer for which the Linux CUPS driver can be downloaded here.
I downloaded this s/w to check it out. I am not running cups but directly running rastertolabelbeeprt at least doesn't crash! My guess is if you place it in the right directory it will just work. To find it you may have to poke around once you install cups - or may be their instructions will work fine. Assuming you have linux compatibility.
 
I have just received the following feedback from the maintainer of the Epson escpr/escpr2 ports concerning this matter:
rastertolabelbeeprt is missing libcupsimage.so.2 and libcups.so.2 when it is run. Installing print/linux-c7-cups-libs will fix this.

Store rastertolabelbeeprt anywhere under /compat/linux.

Edit path to rastertolabelbeeprt in Beeprt.ppd:

sed -i '' -e '/^\*cupsFilter: /{s,rastertolabelbeeprt,/compat/linux/opt/&,;}' Beeprt.ppd

Beeprt.ppd does not have to be installed, but can be uploaded in the CUPS web interface when adding the printer, or specified in the -m option of lpadmin.
So it should indeed be possible to just use that binary as provided without much hassle. :)
 
Last edited:
Back
Top