# Use of a Linux CUPS driver that contains a binary?



## MasterOne (May 5, 2021)

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?


----------



## tuxador (May 5, 2021)

I think that the first thing to do is change the path prefix in the installation script from /bin tu /sur/bin and so


----------



## MasterOne (May 5, 2021)

tuxador said:


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


----------



## zirias@ (May 5, 2021)

Try file(1) on it, it should tell you what it is. If it is an actual compiled binary, it will be OS-specific.



MasterOne said:


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


----------



## tingo (May 5, 2021)

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.


----------



## MasterOne (May 6, 2021)

Zirias said:


> Try file(1) on it, it should tell you what it is. If it is an actual compiled binary, it will be OS-specific.




```
$ 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?


tingo said:


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


----------



## dlo (May 6, 2021)

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


 - from https://docs.freebsd.org/en/books/handbook/linuxemu/


----------



## zirias@ (May 6, 2021)

MasterOne said:


> So impossible to make use of it?


Not necessarily, but as I wrote, you'd need the Linuxulator to run it. But:


tingo said:


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


dlo said:


> I don't believe this is true.


Because you misread what exactly is impossible:


dlo said:


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


----------



## MasterOne (May 6, 2021)

So any hint on how to proceed?


----------



## dlo (May 6, 2021)

> 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:






						Cosmopolitan Libc: build-once run-anywhere C library
					






					justine.lol
				








						Actually Portable Executable
					






					justine.lol


----------



## covacat (May 6, 2021)

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


----------



## zirias@ (May 6, 2021)

dlo said:


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


----------



## jart (May 6, 2021)

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/


----------



## jart (May 6, 2021)

Hello I wrote Cosmopolitan Libc if you have any questions. I tried posting a comment earlier but I might be banned already.


----------



## DutchDaemon (May 6, 2021)

New members' posts are moderated.  A post will be approved when a moderator has time. Be patient.


----------



## jart (May 6, 2021)

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.


----------



## Alain De Vos (May 6, 2021)

A ppd is platform independent.
And there is also "cups-filters" & "foomatic-filters" which sometimes can be used.


----------



## SirDice (May 6, 2021)

jart said:


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


----------



## MasterOne (May 7, 2021)

Alain De Vos said:


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


----------



## jart (May 7, 2021)

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.


----------



## MasterOne (May 7, 2021)

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?


----------



## jart (May 8, 2021)

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.


----------



## MasterOne (May 8, 2021)

jart said:


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


----------



## bakul (May 8, 2021)

MasterOne said:


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


----------



## MasterOne (May 8, 2021)

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


So it should indeed be possible to just use that binary as provided without much hassle.


----------



## astyle (May 13, 2021)

MasterOne said:


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


My printer is HP LaserJet P1102w, which requires print/foo2zjs.  That stuff was originally released for Linux. I had to google around for a bit before I was able to get the CUPS install to accept it on FreeBSD. This was a long time ago, and I don't want to reproduce the details of how I pulled that off. I think I fed the driver to https://localhost:631 web interface for CUPS in the end. No messing around with compat-linux stuff. My point is, to answer your question,  it's perfectly possible.


----------



## Phishfry (May 13, 2021)

What about finding a ppd file for your label printer and feed that into CUPS.

I noticed in the Linux driver you linked to there is a ppd file inside the tar file.
Did you try extracting it and use it for CUPS on FreeBSD?
A ppd file is a printer driver. So it should work on FreeBSD.
Have you tried installing the ppd file in CUPS?


----------



## Phishfry (May 14, 2021)

So it looks like the ppd file references rastertolabelbeeprt.
So you might need to extract that too to the proper directory.
If you look at install file it shows you the CUPS path it looks for.
You might need to manually copy these two files to the proper directory.
/usr/local/etc/cups/ppd/


----------



## MasterOne (May 14, 2021)

Phishfry said:


> So it looks like the ppd file references rastertolabelbeeprt.


And that's what this thread is all about. If it were just a PPD file, it wouldn't be a problem, because such alone is platform independent, but the referenced filter file rastertolabelbeeprt is a Linux binary.

So far there are two possible solutions (both of which actually haven't been tested yet):

Install the original rastertolabelbeeprt under /compat/linux as explained by the maintainer of the Epson escpr/escpr2 ports.
Make use of the patched rastertolabel.c as pointed out by tingo instead.


----------



## zirias@ (May 14, 2021)

MasterOne said:


> Install the original rastertolabelbeeprt under /compat/linux


It probably doesn't make sense to install it under /compat/linux because this hierarchy is just an overlay used for Linux binaries. If it needs a shared library, this shared library must go in /compat/linux. But for the binary itself, I would just place it alongside the other CUPS filters. If it isn't properly recognized as a Linux binary, there's brandelf(1) to fix it.


----------



## astyle (Feb 18, 2022)

astyle said:


> My printer is HP LaserJet P1102w, which requires print/foo2zjs.  That stuff was originally released for Linux. I had to google around for a bit before I was able to get the CUPS install to accept it on FreeBSD. This was a long time ago, and I don't want to reproduce the details of how I pulled that off. I think I fed the driver to https://localhost:631 web interface for CUPS in the end. No messing around with compat-linux stuff. My point is, to answer your question,  it's perfectly possible.


Just remembered (Man, my memory picked a weird time to remember this tidbit): The key is to specify the printer's URI as http://your-printer-ip:9100 when setting up the _foo2zjs_ driver with CUPS! That's why it even worked under FreeBSD at all! (And still does even today  )


----------

