Bug 8825 - Fix the CUPS check
Fix the CUPS check
Product: Samba 3.6
Classification: Unclassified
Component: Build environment
All All
: P5 normal
: ---
Assigned To: Björn Jacke
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2012-03-24 16:58 UTC by Brad Smith
Modified: 2012-03-26 10:24 UTC (History)
0 users

See Also:

Fix the CUPS check (1.86 KB, application/octet-stream)
2012-03-24 16:58 UTC, Brad Smith
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brad Smith 2012-03-24 16:58:17 UTC
Created attachment 7402 [details]
Fix the CUPS check

The attached patch fixes the CUPS check to properly obey the cups-config(1) cflags and ldflags options to be able to find the headers and library with the test and when building.
Comment 1 Björn Jacke 2012-03-26 10:07:05 UTC
this is for *BSD systems, right? After all you don't mention what exact issue you see. It isn't clear what you want to achieve with that patch, in any case it removes the "try -lcups first approach" which we want to do in any case here. It's a known issue that some *BSD systems have a improperly linked libcups library. The upstream cups-config program isn't very useful either because it encourages to add some third party libraries to link in instead, which should actually be linked in libcups during the build of libcups.so. We don't want to link against a bunch of libraries that we do not use on our own, libcups should be fixed on *BSD systems. One reason for issues with this you can find in 15c04403496bb940c5981dca0b960ec45e47c7d8. If you have good connections to the *BSD people, please convince them to fix their libcups build.

If you have issues with the current "try -lcups first approach, try cups-config if linking failed" implmentation in configure.in, can you explain which or adapt you patch to it?
Comment 2 Björn Jacke 2012-03-26 10:24:48 UTC
the buildfarm openbsd machine shows the correctly intended behaviour:

checking for httpConnect in -lcups... no
configure: WARNING: your cups library doesn't link with -lcups alone, it might be underlinked.
checking for httpConnectEncrypt in -lcups... yes

and finally we end up with the insane PRINT_LIBS result we got from from cups-config because of the cups underlinking bug on *BSD:

PRINT_LIBS=' -lcups -lgssapi -lkrb5 -lasn1 -lcrypto -lssl -lcrypto -lz -pthread -lm'