Trying to install Dymo CUPS drivers on SLES11 - getting errors

I have downloaded the tarball for the Dymo CUPS driver version 1.2 and am trying to install it on my SuSE Linux Enterprise 11.0 X86_64 server with no joy.  After working around a couple of issues, I am getting linker errors during the make install phase.  I have discussed these issues with the developer and got nowhere, so I thougt - "I'll take it to the real experts...' ;)

First problem worked around after unpacking, when running configure script it was saying the "missing" file was incomplete or outdated.  I located a newer one on my system and replaced the one that came with the tarball with the newer one that presumably was compatible with current stuff, because the configure script would finish with no errors.

Second problem worked around was that the script assumed that cups headers (and other headers) were installed at /usr/local/include.  They're all at /usr/include - /usr/local/include is empty - so I changed the variable in the config script that was getting set to /usr/local to /usr.   After getting past the configure problems, I cleaned out all the makefiles from prior, reran the configure script and ran the make install process.

The errors in the code snippet below appeared.  I double-checked the makefile scripts and the .Po files, and it appeared to be locating the header files and including them OK.  Just for kicks I copied the contents of /usr/include/cups to a folder under the ./common folder in the install folder set, in case it was having problems finding the includes despite what the makefile scripts and .Po files said.  Still no joy.

Running the make install process consistently fails in the linker, giving "undefined reference" errors as seen in the code snippet below.  I am getting no help from the developer.  The main "undefined reference" I see is `cupRasterReadHeader2' which is defined in the cups header file raster.h, which according to the makefiles and Po files is being found OK.   `cupsBackChannelRead' is also found in one of the CUPS header files, cups.h.

If it's finding those header files and including them in the .cpp's before they're compiled, why would the linker say the reference is undefined?

I am running this logged in as root user, in case running it su wasn't sufficient, so it should not be a filesystem permissions issue.   Using current gcc 4.3 x86_64 for my kernel, from the SLES repo.  CUPS version 1.3.9.

I want to have "real" Dymo Labelwriter drivers/filters instead of the generic rastertolabel filter because I cannot properly adjust the print density with the generic drivers/filters - the labels print too light using the generics, so please don't recommend I use what comes with CUPS - it's inadequate to my needs.  I need a fix for the error conditions so I can run the make install and use the dymo drivers/filters.

Making install in src
make[1]: Entering directory `/home/me/dymo-cups-drivers-1.2.0/src'
Making install in lw
make[2]: Entering directory `/home/me/dymo-cups-drivers-1.2.0/src/lw'
Making install in tests
make[3]: Entering directory `/home/me/dymo-cups-drivers-1.2.0/src/lw/tests'
make[4]: Entering directory `/home/me/dymo-cups-drivers-1.2.0/src/lw/tests'
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory `/home/me/dymo-cups-drivers-1.2.0/src/lw/tests'
make[3]: Leaving directory `/home/me/dymo-cups-drivers-1.2.0/src/lw/tests'
make[3]: Entering directory `/home/me/dymo-cups-drivers-1.2.0/src/lw'
g++ -DHAVE_CONFIG_H -I. -I../../src -I../common    -O2 -Wall -Wno-unknown-pragmas   -MT raster2dymolw.o -MD -MP -MF .deps/raster2dymolw.Tpo -c -o raster2dymolw.o raster2dymolw.cpp
mv -f .deps/raster2dymolw.Tpo .deps/raster2dymolw.Po
g++ -DHAVE_CONFIG_H -I. -I../../src -I../common    -O2 -Wall -Wno-unknown-pragmas   -MT LabelWriterDriver.o -MD -MP -MF .deps/LabelWriterDriver.Tpo -c -o LabelWriterDriver.o LabelWriterDriver.cpp
mv -f .deps/LabelWriterDriver.Tpo .deps/LabelWriterDriver.Po
g++ -DHAVE_CONFIG_H -I. -I../../src -I../common    -O2 -Wall -Wno-unknown-pragmas   -MT LabelWriterLanguageMonitor.o -MD -MP -MF .deps/LabelWriterLanguageMonitor.Tpo -c -o LabelWriterLanguageMonitor.o LabelWriterLanguageMonitor.cpp
mv -f .deps/LabelWriterLanguageMonitor.Tpo .deps/LabelWriterLanguageMonitor.Po
g++ -DHAVE_CONFIG_H -I. -I../../src -I../common    -O2 -Wall -Wno-unknown-pragmas   -MT CupsFilterLabelWriter.o -MD -MP -MF .deps/CupsFilterLabelWriter.Tpo -c -o CupsFilterLabelWriter.o CupsFilterLabelWriter.cpp
mv -f .deps/CupsFilterLabelWriter.Tpo .deps/CupsFilterLabelWriter.Po
g++ -DHAVE_CONFIG_H -I. -I../../src -I../common    -O2 -Wall -Wno-unknown-pragmas   -MT CupsPrintEnvironment.o -MD -MP -MF .deps/CupsPrintEnvironment.Tpo -c -o CupsPrintEnvironment.o `test -f '../common/CupsPrintEnvironment.cpp' || echo './'`../common/CupsPrintEnvironment.cpp
mv -f .deps/CupsPrintEnvironment.Tpo .deps/CupsPrintEnvironment.Po
g++ -DHAVE_CONFIG_H -I. -I../../src -I../common    -O2 -Wall -Wno-unknown-pragmas   -MT Halftoning.o -MD -MP -MF .deps/Halftoning.Tpo -c -o Halftoning.o `test -f '../common/Halftoning.cpp' || echo './'`../common/Halftoning.cpp
mv -f .deps/Halftoning.Tpo .deps/Halftoning.Po
g++ -DHAVE_CONFIG_H -I. -I../../src -I../common    -O2 -Wall -Wno-unknown-pragmas   -MT ErrorDiffusionHalftoning.o -MD -MP -MF .deps/ErrorDiffusionHalftoning.Tpo -c -o ErrorDiffusionHalftoning.o `test -f '../common/ErrorDiffusionHalftoning.cpp' || echo './'`../common/ErrorDiffusionHalftoning.cpp
mv -f .deps/ErrorDiffusionHalftoning.Tpo .deps/ErrorDiffusionHalftoning.Po
g++ -DHAVE_CONFIG_H -I. -I../../src -I../common    -O2 -Wall -Wno-unknown-pragmas   -MT NonLinearLaplacianHalftoning.o -MD -MP -MF .deps/NonLinearLaplacianHalftoning.Tpo -c -o NonLinearLaplacianHalftoning.o `test -f '../common/NonLinearLaplacianHalftoning.cpp' || echo './'`../common/NonLinearLaplacianHalftoning.cpp
mv -f .deps/NonLinearLaplacianHalftoning.Tpo .deps/NonLinearLaplacianHalftoning.Po
g++ -DHAVE_CONFIG_H -I. -I../../src -I../common    -O2 -Wall -Wno-unknown-pragmas   -MT DummyLanguageMonitor.o -MD -MP -MF .deps/DummyLanguageMonitor.Tpo -c -o DummyLanguageMonitor.o `test -f '../common/DummyLanguageMonitor.cpp' || echo './'`../common/DummyLanguageMonitor.cpp
mv -f .deps/DummyLanguageMonitor.Tpo .deps/DummyLanguageMonitor.Po
g++  -O2 -Wall -Wno-unknown-pragmas     -o raster2dymolw raster2dymolw.o LabelWriterDriver.o LabelWriterLanguageMonitor.o CupsFilterLabelWriter.o CupsPrintEnvironment.o Halftoning.o ErrorDiffusionHalftoning.o NonLinearLaplacianHalftoning.o DummyLanguageMonitor.o  -lcupsimage -lcups 
raster2dymolw.o: In function `DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriver, DymoPrinterDriver::CDriverInitializerLabelWriterWithLM, DymoPrinterDriver::CLabelWriterLanguageMonitor>::Run(int, char**)':
raster2dymolw.cpp:(.text._ZN17DymoPrinterDriver11CCupsFilterINS_18CLabelWriterDriverENS_35CDriverInitializerLabelWriterWithLMENS_27CLabelWriterLanguageMonitorEE3RunEiPPc[DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriver, DymoPrinterDriver::CDriverInitializerLabelWriterWithLM, DymoPrinterDriver::CLabelWriterLanguageMonitor>::Run(int, char**)]+0xb2): undefined reference to `cupsRasterReadHeader2'
raster2dymolw.o: In function `DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriver, DymoPrinterDriver::CDriverInitializerLabelWriter, DymoPrinterDriver::CDummyLanguageMonitor>::Run(int, char**)':
raster2dymolw.cpp:(.text._ZN17DymoPrinterDriver11CCupsFilterINS_18CLabelWriterDriverENS_29CDriverInitializerLabelWriterENS_21CDummyLanguageMonitorEE3RunEiPPc[DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriver, DymoPrinterDriver::CDriverInitializerLabelWriter, DymoPrinterDriver::CDummyLanguageMonitor>::Run(int, char**)]+0xb2): undefined reference to `cupsRasterReadHeader2'
raster2dymolw.o: In function `DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriverTwinTurbo, DymoPrinterDriver::CDriverInitializerLabelWriterTwinTurboWithLM, DymoPrinterDriver::CLabelWriterLanguageMonitor>::Run(int, char**)':
raster2dymolw.cpp:(.text._ZN17DymoPrinterDriver11CCupsFilterINS_27CLabelWriterDriverTwinTurboENS_44CDriverInitializerLabelWriterTwinTurboWithLMENS_27CLabelWriterLanguageMonitorEE3RunEiPPc[DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriverTwinTurbo, DymoPrinterDriver::CDriverInitializerLabelWriterTwinTurboWithLM, DymoPrinterDriver::CLabelWriterLanguageMonitor>::Run(int, char**)]+0xb2): undefined reference to `cupsRasterReadHeader2'
raster2dymolw.o: In function `DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriverTwinTurbo, DymoPrinterDriver::CDriverInitializerLabelWriterTwinTurbo, DymoPrinterDriver::CDummyLanguageMonitor>::Run(int, char**)':
raster2dymolw.cpp:(.text._ZN17DymoPrinterDriver11CCupsFilterINS_27CLabelWriterDriverTwinTurboENS_38CDriverInitializerLabelWriterTwinTurboENS_21CDummyLanguageMonitorEE3RunEiPPc[DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriverTwinTurbo, DymoPrinterDriver::CDriverInitializerLabelWriterTwinTurbo, DymoPrinterDriver::CDummyLanguageMonitor>::Run(int, char**)]+0xb2): undefined reference to `cupsRasterReadHeader2'
raster2dymolw.o: In function `DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriver400, DymoPrinterDriver::CDriverInitializerLabelWriterWithLM, DymoPrinterDriver::CLabelWriterLanguageMonitor>::Run(int, char**)':
raster2dymolw.cpp:(.text._ZN17DymoPrinterDriver11CCupsFilterINS_21CLabelWriterDriver400ENS_35CDriverInitializerLabelWriterWithLMENS_27CLabelWriterLanguageMonitorEE3RunEiPPc[DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriver400, DymoPrinterDriver::CDriverInitializerLabelWriterWithLM, DymoPrinterDriver::CLabelWriterLanguageMonitor>::Run(int, char**)]+0xb2): undefined reference to `cupsRasterReadHeader2'
raster2dymolw.o:raster2dymolw.cpp:(.text._ZN17DymoPrinterDriver11CCupsFilterINS_21CLabelWriterDriver400ENS_29CDriverInitializerLabelWriterENS_21CDummyLanguageMonitorEE3RunEiPPc[DymoPrinterDriver::CCupsFilter<DymoPrinterDriver::CLabelWriterDriver400, DymoPrinterDriver::CDriverInitializerLabelWriter, DymoPrinterDriver::CDummyLanguageMonitor>::Run(int, char**)]+0xb2): more undefined references to `cupsRasterReadHeader2' follow
CupsPrintEnvironment.o: In function `DymoPrinterDriver::CCupsPrintEnvironmentForLM::ReadData(std::vector<unsigned char, std::allocator<unsigned char> >&)':
CupsPrintEnvironment.cpp:(.text+0x153): undefined reference to `cupsBackChannelRead'
collect2: ld returned 1 exit status
make[3]: *** [raster2dymolw] Error 1
make[3]: Leaving directory `/home/me/dymo-cups-drivers-1.2.0/src/lw'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/home/me/dymo-cups-drivers-1.2.0/src/lw'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/me/dymo-cups-drivers-1.2.0/src'
make: *** [install-recursive] Error 1

Open in new window

LVL 35
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

These are linker errors - seems that you have to link with libcupsimage.a ('-lcupsimage'), see
ShineOnAuthor Commented:
Yes, they are linker errors, as I mentioned in the Q.  

The library libcupsimage.a is in the library path /usr/lib64, which I have set the configure to use for the library path.   How do I make it link with libcupsimage.a, other than telling the configure script what the library path is?  Shouldn't it already know to link with libcupsimage.a?  Could there be another file that maybe has /usr/lib hardcoded into it rather than using what the configure script generates?
Check the configure script - it should have a command line option to pass an additional library path.
CompTIA Security+

Learn the essential functions of CompTIA Security+, which establishes the core knowledge required of any cybersecurity role and leads professionals into intermediate-level cybersecurity jobs.

ShineOnAuthor Commented:
As it turns out, it is already using -lcupsimage in the linker section of the configure script.  The problem is this:

The configure script is testing -libcupsimage for cupsRasterReadHeader and it's passing the test on that account, but that function is deprecated for cupsRasterReadHeader2, and for whatever reason, that current, non-deprecated, function isn't found at link time, or at configure time for that matter:

If I change the configure script to test -libcupsimage for cupsRasterReadHeader2, it doesn't pass the test during ./configure, which could be a clue as to why it's not finding a reference later.

Assuming that cupsBackChannelRead, the other "reference not found" error, is in -lcups (which also passes the configure script's test) that begs the question why the linker can't resolve that function from -lcups either.

Dumb question - I thought configure looks at the library path for the libraries, translating -lxxxxx to libxxxxx.a - so if there's only one libxxxxx.a in any of the library paths, shouldn't that be what it's using?  Browsing through the .a files in question (libcups.a and libcupsimage.a) I see both of the missing references, which leads me to believe something is hosed configuration-wise, whether it be in the Dymo files or in my system.

Is it possible that the configure process from Dymo is using some sort of "version level" modifier that's limiting the libraries to functions compatible with versions of CUPS before 1.2?  I don't know if configure and the processes that go into it have that sort of sophistication or not, which is why I'm asking.  If it is possible, what would I look for?
ShineOnAuthor Commented:
I think it may be that the configure/make templates were all built for 32-bit only, and I'm trying to shoehorn it into a 64-bit environment.  Does that make sense?

Any recommendations at this point?  Do I try to compile it using 32-bit tools and libraries?
ShineOnAuthor Commented:
I have a sort-of answer.

Things chunk along fine until it gets to the part in the make install process where it links all the object modules together to make the executable binary.  

I set up another SLES11 X86_64 box with the same patches and GCC version and CUPS version and libs versions and it ran through the make install process without a hitch.

Thinking maybe some lib got corrupted on the first server, I uninstalled CUPS and the CUPS libs and reinstalled them, and still had the same result.

It turns out that for as-yet-unknown reasons, either make wasn't passing/setting the library path properly for g++ to "see" the static libraries, or something was preventing g++ from seeing the path to the static libraries, so even though I tried using the command-line arguments for configure to pass info to the linker for the libraries, it wasn't retaining that info or couldn't access the path or something.

To this day I cannot run a make install for the dymo printer drivers on the first server.  If anyone has any clues as to where I can look to see why it's not working, or what steps I should take to troubleshoot this, I will keep this question open for a while...

I ran g++ -print-file-name on the cups libs and got no path on the problem server but got a path on the server that worked.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
ShineOnAuthor Commented:
OK, well, this is getting no traction, so I guess this can be chalked up to "one of those things."
ShineOnAuthor Commented:
Would have been nice to get some insight as to how to troubleshoot the dev environment problem on the one server.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Linux OS Dev

From novice to tech pro — start learning today.