LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Hardware (http://www.linuxquestions.org/questions/linux-hardware-18/)
-   -   64-bit Driver for Brother Printer (http://www.linuxquestions.org/questions/linux-hardware-18/64-bit-driver-for-brother-printer-754018/)

MQMan 09-09-2009 08:17 PM

64-bit Driver for Brother Printer
 
Hi,

I have a Brother MFC-8870DW printer currently hooked up to my Slackware 12.2 system.

I'm thinking of moving to the 64-bit, 13.0 release, which is a "pure" 64-bit system, not multilib.

I found these instructions on Brother's web site, for installing the drivers in a 64-bit environment.

However, I don't think that this would work, as both the LPR and CUPS packages contain 32-bit executables and libraries, which means that it will only work on a multilib system.

Am I correct in that assumption, and if so, does anyone know of any source for 64-bit drivers that might work with this printer.

Cheers.

GrapefruiTgirl 09-09-2009 08:26 PM

If your kernel has the "Enable support for 32bit code" (or whatever the option is called exactly) option enabled, you can actually run 32 bit code/applications/binaries and stuff.

I have this enabled on my "pure" Slack 13 64bit installation, and discovered that it worked, by accidentally booting my Slack 11 installation one day, by a LILO copy&paste error. The 32bit Slack booted fine, so I suspect CUPS & LPR packages should also be usable on 64bit, at least when the "execute 32bit" option is enabled. Besides, Slack13-64 includes CUPS, so evidentally that won't be a problem ;)

NOTE1: from looking at the instructions on the link you gave, it *appears* that *maybe* you wouldn't even need the kernel option enabled, as their instructions look like basically simple copy/paste relocations of the driver libs, which indicates to me that those libs will (apparently?) run on either architecture. That sounds weird, but that's how I read it. Other input pro or con would be appreciated by both myself, AND the OP I'm sure.

NOTE2: the kernel option for "32bit execution" does not enable you to build 32bit packages on the 64 bit arch; for actually building stuff, you would still need the multilib situation.

Hope this helps a bit, even though I'm not 100% on this. And I'm keen on hearing from others more knowledgeable, as I'll be in the exact same boat shortly with my own Brother MFC printer.

Sasha

MQMan 09-10-2009 03:26 AM

Quote:

Originally Posted by GrapefruiTgirl (Post 3676624)
If your kernel has the "Enable support for 32bit code" (or whatever the option is called exactly) option enabled, you can actually run 32 bit code/applications/binaries and stuff.

Hmmmm. That's interesting. I thought the applications/libraries had to be built under the correct architecture. I'll have to look for that option, once I get my 64-bit system up and running. Hopefully in the next few days.
Quote:

Originally Posted by GrapefruiTgirl (Post 3676624)
I have this enabled on my "pure" Slack 13 64bit installation, and discovered that it worked, by accidentally booting my Slack 11 installation one day, by a LILO copy&paste error. The 32bit Slack booted fine

Not quite sure I understand what you're saying. The architecture of LILO and the architecture of the Linux you are booting, should be independent.
Quote:

Originally Posted by GrapefruiTgirl (Post 3676624)
Besides, Slack13-64 includes CUPS, so evidentally that won't be a problem ;)

I was referencing the CUPS filters that Brother provides, not CUPS itself.
Quote:

Originally Posted by GrapefruiTgirl (Post 3676624)
NOTE1: from looking at the instructions on the link you gave, it *appears* that *maybe* you wouldn't even need the kernel option enabled, as their instructions look like basically simple copy/paste relocations of the driver libs, which indicates to me that those libs will (apparently?) run on either architecture. That sounds weird, but that's how I read it. Other input pro or con would be appreciated by both myself, AND the OP I'm sure.

I read this differently. My take was that they were looking for certain scripts in a "fixed" location, and they were just making sure that they would be found in either "lib", or "lib64", whichever was being searched. But, then again, I could be wrong.

As I said, if I get a chance over the next few days, I should be able to provide more input here.

Cheers,
Eddie

GrapefruiTgirl 09-10-2009 07:42 AM

Quote:

Originally Posted by MQMan (Post 3676966)
Hmmmm. That's interesting. I thought the applications/libraries had to be built under the correct architecture. I'll have to look for that option, once I get my 64-bit system up and running. Hopefully in the next few days.

No, you're right! They have to be BUILT under the right architecture, or via some chroot magic or something; but simply RUNNING them (not building stuff) seems to work fine.
Quote:

Not quite sure I understand what you're saying. The architecture of LILO and the architecture of the Linux you are booting, should be independent.
To clarify: I added my 64bit Slack13 kernel to LILO, but accidentally pointed it's root partition to that of my other Slack11-32 root filesystem. And it booted Slack11 no problem. The LILO thing was just me telling you how I accidentally came to make the discovery that the 64bit kernel would boot the 32bit OS ;)

Quote:

I was referencing the CUPS filters that Brother provides, not CUPS itself.

I read this differently. My take was that they were looking for certain scripts in a "fixed" location, and they were just making sure that they would be found in either "lib", or "lib64", whichever was being searched. But, then again, I could be wrong.
OK, maybe I misread the page you linked to -- I was under the impression that the items they were moving to/from lib64 were actually LIBS, rather than scripts. Sorry if I confused that angle.
Quote:

As I said, if I get a chance over the next few days, I should be able to provide more input here.

Cheers,
Eddie
Cool :) I look forward to your 'more input'

Kind regards,
Sasha

allend 09-10-2009 08:56 AM

This is what I did to get my Brother DCP-110C working in Slackware64.
http://www.linuxquestions.org/questi...3/#post3626123

Another alternative would be to create a multilib setup.
http://alien.slackbook.org/dokuwiki/...kware:multilib

Edit:
I did email Brother asking whether they were planning on releasing a 64bit printer driver, and they politely replied that the answer was no.
Edit2: Corrected link

GrapefruiTgirl 09-10-2009 08:59 AM

@ allend -- that first link you posted, could you check it? It's taking me to a REPLY dialog..

UPDATE - yep, you got it, thanks allend :)

allend 09-10-2009 09:38 AM

Sasha, Thanks for picking up my error. Hopefully I have it right now.

MQMan 09-11-2009 04:04 PM

Quote:

Originally Posted by GrapefruiTgirl (Post 3677196)
No, you're right! They have to be BUILT under the right architecture, or via some chroot magic or something; but simply RUNNING them (not building stuff) seems to work fine.

To clarify: I added my 64bit Slack13 kernel to LILO, but accidentally pointed it's root partition to that of my other Slack11-32 root filesystem. And it booted Slack11 no problem. The LILO thing was just me telling you how I accidentally came to make the discovery that the 64bit kernel would boot the 32bit OS ;)

Sasha,

I think this only worked, because everything, except for the kernel was 32-bit.

In the investigation I've done since, if you are running a "pure" 64-bit system, then statically linked 32-bit programs will run. But dynamically linked programs need the 32-bit libraries in order to execute. You can't call a 64-bit library from a 32-bit application.

Or, at least, that's what I've understood from everything I've read.

Cheers,
Eddie

GrapefruiTgirl 09-11-2009 05:46 PM

Quote:

Originally Posted by MQMan (Post 3679255)
Sasha,

I think this only worked, because everything, except for the kernel was 32-bit

Or, at least, that's what I've understood from everything I've read.

Cheers,
Eddie

Hi Eddie :)

OK, I follow what you're saying, *I think*...

I'm not trying to derail your thread here either :) but if you think I'm (or we're) getting it off-track here, please feel free to hit the report button and ask that my post from here on be chopped off to its own new thread -- because I too would like to fully understand exactly how this all works.

you said:
Quote:

In the investigation I've done since, if you are running a "pure" 64-bit system, then statically linked 32-bit programs will run. But dynamically linked programs need the 32-bit libraries in order to execute. You can't call a 64-bit library from a 32-bit application.
So, regarding the bold part above, please tell me if I'm right here:

Query1) When I booted Slack32 with my 64bit kernel, it worked because all the 32bit libs are available on that filesystem; so even the dynamically linked 32bit programs on that filesystem worked (such as Xorg, which is almost certainly dynamically linked, no??).

Eureka moment: Did I effectively boot into a half-baked multi-lib environment, when I booted Slack32 with the 64bit kernel? I say half-baked, because:
1) while there were 32bit libs available, there were no 64bit ones on that filesystem; only the kernel was 64bit (though with the 32bit compat option). and..
2) the toolchain is not multi-lib.
------------

Query2) Regarding your printer driver, If it were a 64bit-ONLY driver, it would only work with a 64bit kernel, AND would REQUIRE whatever 64bit libs it may be dynamically linked against. (this is logical.) Plus, it would not work in any sort of 32bit environment.
-------------

And as for the underlined part in your quote there: You can't call a 64bit library from a 32bit application. Period. That makes sense to me, if nothing else does :)

----------------

So let me theorize:

Q:what if you have...

A) 32bit compat option in the 64bit kernel.
B) 32bit CUPS & its required 32bit libs
C) 32bit brother driver & its required 32bit libs

That should work, shouldn't it?

OR: what if we have...

A) 32bit compat option in the 64bit kernel.
B) 64bit CUPS & its required 64bit libs
C) 32bit brother driver & its required 32bit libs

Again, should work, shouldn't it? (Does this qualify as somewhat "multilib", or is it "half-baked", as like when I booted 32bitOS w/ the 64bit kernel) -- I know it is not "True Multilib" -- because we still can't actually BUILD any 32bit stuff, only RUN it.
------------------------------------------

Well, now that we're thoroughly confused (speaking for myself, anyway :scratch: ) I say:

"It seems to me, from reading those simple instructions at the Brother link you gave above, that: the brother driver will work on EITHER 32bit or 64bit ARCH, and those instructions are merely making certain that whatever application goes looking for it, finds it *somewhere*."


Again, my apology for/if this is getting off-track here. Go ahead and report/request a move of some of this discussion if you feel it's not really addressing the issue at hand.

Cheers :)
Sasha

PS -- update: @ MQMan -- Yes, I saw the request for the move; good idea.

TO ALL READERS: Please try to keep further posts to this thread, directly on topic of the Brother printer driver in question. The 64 vs 32 situation will be undertaken in a new thread, once this stuff has been cleaned up. Thank you :)

MQMan 09-11-2009 08:01 PM

Quote:

Originally Posted by GrapefruiTgirl (Post 3679333)
Hi Eddie :)

I'm not trying to derail your thread here either :) but if you think I'm (or we're) getting it off-track here, please feel free to hit the report button and ask that my post from here on be chopped off to its own new thread -- because I too would like to fully understand exactly how this all works.

I've asked for this to be "spawned off", so I'll wait until that happens before I reply to each part.

Cheers,
Eddie

MQMan 09-12-2009 02:18 PM

Quote:

Originally Posted by GrapefruiTgirl (Post 3679333)
Hi Eddie :)
Query2) Regarding your printer driver, If it were a 64bit-ONLY driver, it would only work with a 64bit kernel, AND would REQUIRE whatever 64bit libs it may be dynamically linked against. (this is logical.) Plus, it would not work in any sort of 32bit environment.

Correct.
Quote:

Originally Posted by GrapefruiTgirl (Post 3679333)
So let me theorize:

Q:what if you have...

A) 32bit compat option in the 64bit kernel.
B) 32bit CUPS & its required 32bit libs
C) 32bit brother driver & its required 32bit libs

That should work, shouldn't it?

I would think so.
Quote:

Originally Posted by GrapefruiTgirl (Post 3679333)
OR: what if we have...

A) 32bit compat option in the 64bit kernel.
B) 64bit CUPS & its required 64bit libs
C) 32bit brother driver & its required 32bit libs

Again, should work, shouldn't it? (Does this qualify as somewhat "multilib", or is it "half-baked", as like when I booted 32bitOS w/ the 64bit kernel) -- I know it is not "True Multilib" -- because we still can't actually BUILD any 32bit stuff, only RUN it.

Again, yes I would guess so, and it would qualify as multilib, in my opinion.
Quote:

Originally Posted by GrapefruiTgirl (Post 3679333)
Well, now that we're thoroughly confused (speaking for myself, anyway :scratch: )

Not really. ;)
Quote:

Originally Posted by GrapefruiTgirl (Post 3679333)
I say:

"It seems to me, from reading those simple instructions at the Brother link you gave above, that: the brother driver will work on EITHER 32bit or 64bit ARCH, and those instructions are merely making certain that whatever application goes looking for it, finds it *somewhere*."

No. The instructions on the Brother site are only ensuring that a single shell script can be found in the correct location, for either 32-bit or 64-bit. The actual binaries provided are only 32-bit, dynamically linked, and so will only work in a true multilib environment.

The actual truth will be revealed tomorrow, as I plan to try out my 64-bit version then. :D

Cheers,
Eddie

MQMan 09-12-2009 02:22 PM

Quote:

Originally Posted by GrapefruiTgirl (Post 3679333)
Hi Eddie :)

So, regarding the bold part above, please tell me if I'm right here:

Query1) When I booted Slack32 with my 64bit kernel, it worked because all the 32bit libs are available on that filesystem; so even the dynamically linked 32bit programs on that filesystem worked (such as Xorg, which is almost certainly dynamically linked, no??).

Yes, because the "allow 32-bit" applications would let you start any application, and it would only go searching for the equivalent 32-bit libraries.
Quote:

Originally Posted by GrapefruiTgirl (Post 3679333)
Eureka moment: Did I effectively boot into a half-baked multi-lib environment, when I booted Slack32 with the 64bit kernel? I say half-baked, because:
1) while there were 32bit libs available, there were no 64bit ones on that filesystem; only the kernel was 64bit (though with the 32bit compat option). and..
2) the toolchain is not multi-lib.

Yes, truly "half-baked". :D

And yes, the toolchain is pure 32-bit.

Cheers,
Eddie

MQMan 09-14-2009 06:13 PM

OK, back on the printer topic. :D

You can't even install the Brother lpr driver without full multilib support. Here's the 1st attempt:
Code:

# rpm -ihv --nodeps brmfc8870dwlpr-2.0.1-1.i386.rpm
Preparing...                ########################################### [100%]
  1:brmfc8870dwlpr        ########################################### [100%]
/var/tmp/rpm-tmp.p1UtOP: line 2: /usr/local/Brother/inf/braddprinter: No such file or directory

Well, the file /usr/local/Brother/inf/braddprinter does exist, and it's a statically linked executable. But, it contains a hardcoded reference to /lib/ld-linux.so.2, which obviously doesn't exist on a "pure" 64-bit system.

Next attempt, was after creating a soft link, /lib/ld-linux.so.2 -> /lib64/ld-linux-x86-64.so.2:
Code:

# rpm -ihv --nodeps brmfc8870dwlpr-2.0.1-1.i386.rpm
Preparing...                ########################################### [100%]
  1:brmfc8870dwlpr        ########################################### [100%]
/var/tmp/rpm-tmp.luZ046: line 2: /usr/local/Brother/inf/braddprinter: Accessing a corrupted shared library

So, I guess that 'aint going to work.

However, firing up CUPS, and trying to add a printer, seems to have worked. On the Device screen, my printer was offered as one of the choices. Next, on the Driver screen, it highlighted "Brother MFC-8300 - CUPS+Gutenprint v5.2.4 (en)" as the "suggestion". I chose that, and it seemed to install fine. I ran a Test Page, which printed fine. I guess that will work, for basic printing.

So, bottom line, at least for my printer, is that it works "out of the box", without the Brother Drivers.

BTW I e-mailed Brother, to ask them about a 64-bit driver, and received this reply:
Quote:

Thank you for your inquiry.

At this time we only have drivers designed for the 32bit OS.

We appreciate your business and look forward to serving you again.

Brother Linux Support
Cheers.

GrapefruiTgirl 09-14-2009 06:53 PM

I find it odd that they give instructions for installing into a 64 bit environment, yet they give that statement:
Quote:

Originally Posted by brother
At this time we only have drivers designed for the 32bit OS.

Hm.
Sasha

MQMan 10-22-2009 04:46 PM

OK, I know this is an old thread, but I finally found the time to work on it, as it wasn't as urgent, as the printer seemed to be running OK with the MFC-8300 drivers.

What's needed, is a 32-bit system, and statifier, which someone pointed me at here.

OK, the steps to follow are:

On the 32-bit system:

Install statifier.
Install both the Brother lpr and cups drivers.
Identify which components of the drivers are executables, and not scripts. I used file.
Run statifier on those executables, to create pseudo-static 32-bit executables.

Now, on the 64 bit system:

Install both the, same, Brother lpr and cups drivers, but specify -i, --nodeps (if necessary), and --noscripts on the rpm command.
Replace the 32-bit executables, with the "statified" ones, from above.
Extract the postinstall scripts, from both drivers, with the -ql --scripts options.
Create install and uninstall scripts from the scriptlets.
Run the install scripts, lpr first, then cups.

Add printer to CUPS and test.

So far, everything appears to be working fine.

Cheers.


All times are GMT -5. The time now is 05:04 PM.