Bug 696508

could even do something like:

if test x${is_cross_compiler} = xno; then
  CCAUX="${CCAUX:-${CC}}"
  CFLAGSAUX="${CFLAGSAUX}"
else
  CCAUX=cc
  CFLAGSAUX="-O"
fi

Created attachment 12228 [details]
[PATCH] Pick better host defaults for CCAUX/CFLAGSAUX

How about this? It picks reasonable defaults for both native and cross compilation, and it still allows configuration during the ./configure step.

Created attachment 12229 [details]
[PATCH] Add safe default for libtiff conf directory

+ one more patch for consideration. I can file a separate bug if needed.

both look fine to me

The libtiff patch I will apply.

The CCAUX/CFLAGSAUX is really *not* sufficient - if that was all that was required, I'd have done it a *long* time ago.

Given that this is intended to support cross compilation better, we cannot have the majority of the CFLAGS shared between the host and target compilers - as the currently are, and would remain so with your patch.

We'd need to separate out the compiler arguments for the two compilers, and (where appropriate) have configure check the appropriate flags for *both* the host and target compilers.

We also need to do the same for LDFLAGS and LDFLAGSAUX.

(In reply to Chris Liddell (chrisl) from comment #5)

i'm not following what you're saying.  this patch does not merge CFLAGS into CFLAGSAUX and explicitly does not do that.  i also see it as being an incremental fix, so even if there is more cross-compiling work pending, we'd still want this as a basis.  why do we have to have 100% things fixed first ?

(In reply to Mike Frysinger from comment #6)
> (In reply to Chris Liddell (chrisl) from comment #5)
> 
> i'm not following what you're saying.  this patch does not merge CFLAGS into
> CFLAGSAUX and explicitly does not do that.

In the Makefile, the flags are merged, so CCAUX gets the same flags as CC, that needs to change.

>  i also see it as being an
> incremental fix, so even if there is more cross-compiling work pending, we'd
> still want this as a basis.  why do we have to have 100% things fixed first ?

Sure, and I'll include the patch on that basis, when I have a few minutes free.

(In reply to Chris Liddell (chrisl) from comment #7)
> 
> In the Makefile, the flags are merged, so CCAUX gets the same flags as CC,
> that needs to change.

Makefile.in *used* to merge them:

CCAUX=@CC@
CCAUX_=$(CCAUX) $(CFLAGS)

But now it doesn't:

CCAUX=@CCAUX@
CFLAGSAUX=@CFLAGSAUX@
CCAUX_=$(CCAUX) $(CFLAGSAUX)

Did you miss part of my patch, or am I missing something?

(In reply to Brian Norris from comment #8)
> (In reply to Chris Liddell (chrisl) from comment #7)
> > 
> > In the Makefile, the flags are merged, so CCAUX gets the same flags as CC,
> > that needs to change.
> 
> Makefile.in *used* to merge them:
> 
> CCAUX=@CC@
> CCAUX_=$(CCAUX) $(CFLAGS)
> 
> But now it doesn't:
> 
> CCAUX=@CCAUX@
> CFLAGSAUX=@CFLAGSAUX@
> CCAUX_=$(CCAUX) $(CFLAGSAUX)
> 
> Did you miss part of my patch, or am I missing something?

Sorry, I did miss that.

But with that, your patch stops Ghostscript from building at all for me:

cc -O -I./obj -I./base -I./devices  -DWHICH_CMS="lcms2" -DUSE_LIBPAPER -I/usr/include/freetype2  -o ./obj/aux/gp_unix.o -c ./base/gp_unix.c
In file included from ./base/gp_unix.c:21:0:
./base/time_.h:51:8: error: redefinition of ‘struct timeval’
 struct timeval {


As I said, *some* flags from configure are needed by CCAUX.

Also, I'm fairly sure your patch with break (at least) building against a shared zlib library (required by both Ghostscript "proper" and the mkromfs utility) - a configuration we are required to support.

(In reply to Chris Liddell (chrisl) from comment #9)
> As I said, *some* flags from configure are needed by CCAUX.

It's really not clear how to do this properly, then. I can either make assumptions about similarities between $CC and $CCAUX, or else I can tread into territory not really covered by autotools.

The best info I could drudge up was this suggestion:

http://lists.gnu.org/archive/html/automake/2014-01/msg00006.html

This doesn't really give a satisfactory answer for anything beyond how to figure out a compiler targeting the build system.

Any other suggestions?

(In reply to Brian Norris from comment #10)
> (In reply to Chris Liddell (chrisl) from comment #9)
> > As I said, *some* flags from configure are needed by CCAUX.
> 
> It's really not clear how to do this properly, then. I can either make
> assumptions about similarities between $CC and $CCAUX, or else I can tread
> into territory not really covered by autotools.
> 
> The best info I could drudge up was this suggestion:
> 
> http://lists.gnu.org/archive/html/automake/2014-01/msg00006.html
> 
> This doesn't really give a satisfactory answer for anything beyond how to
> figure out a compiler targeting the build system.

Precisely the problem: the autotools make no provision for "interim" tools that need built and executed as part of a larger build process - which, although not terribly common, really isn't unheard-of.

> Any other suggestions?

I have two ideas: one I *know* will work, but has slight long term maintenance implications. The other I much less sure it will work, *but* would be considerably simpler for long term support, and thus *if* it works, would be preferable.

I had hoped to have messed with this a bit more this week, but I've been involved with other things. Give me a few (working) days, and I should know which of my two ideas I'll pursue, and will outline it then.

So, this looks like it's going to work:

My plan to have configure call itself, if required.

If call configure in such a way that $CCAUX != $CC, then we'll create a temporary directory, and have configure call itself, thus:
../configure MAKEFILE=auxflags.mak CC=$CCAUX CCAUX= <other params>

The "other params" disabling a load of tests not relevant for the AUX tools.

That'll then create a separate "makefile" containing just CCAUX and associated settings, which is then included in the Makefile.

If configure is called in such a way that $CCAUX == $CC, then the single configure pass will create both Makefile and auxflags.mak

I'm pretty close to having this working how I want it.

Here's what I have:

http://tinyurl.com/joyypd2


The top three commits relate to this.

I don't currently have a cross compiling environment setup on this machine, so I've been testing with different compilers for CC and CCAUX, but both compilers target the current environment.

So, if you'd like to have a play.....

There are still many problems. Quite a number of tests look at the current platform (uname) to make decisions, some can be overridden from the command line, others cannot, so those that cannot will have to changed to allow that.

I can post a single patch on here if that would be easier.

Interesting approach. I've never seen that done, but I'm also not very experienced with autoconf.

I see a few problems:

For one, you're not bailing out if the sub-configure fails. So errors are masked, and you'll only see the failure later, when auxflags.mak is missing.

It also looks like you're not switching over the sub-configure to use the host CFLAGS properly. You're just re-using CFLAGS that were specified in the containing environment (which in my case is the cross-compilation flags). So I get failures when the x86 (host) compiler is trying to use ARM (target) machine flags.

I've tweaked the changes based on your feedback, thanks.

We're getting close to the next scheduled release, so I'm wary about pulling in such a significant change for another month or so (after the release).

I'm hoping to have some time to install a cross compiling environment and test this stuff myself.

Created attachment 12303 [details]
[PATCH] fixup missing quotes on shell variables

You're missing some quotes

Created attachment 12305 [details]
[PATCH] gitignore updates

Adding another small patch for .gitignore.

BTW, almost all the non-wildcard entries should probably be prefixed with a slash ('/'), to make sure they are treated relative to the root. e.g.:

gs/Makefile

should be:

/gs/Makefile

On a native-compile Linux build, I'm seeing this:

gcc  -DHAVE_MKSTEMP -DHAVE_FILE64 -DHAVE_FSEEKO -DHAVE_MKSTEMP64 -DHAVE_FONTCONFIG -DHAVE_LIBIDN -DHAVE_SETLOCALE -DHAVE_SSE2 -DHAVE_DBUS -DHAVE_BSWAP32 -DHAVE_BYTESWAP_H -DHAVE_STRERROR -DHAVE_ISNAN -DHAVE_ISINF -DHAVE_PREAD_PWRITE=1 -DGS_RECURSIVE_MUTEXATTR=PTHREAD_MUTEX_RECURSIVE -O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -DHAVE_STDINT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_INTTYPES_H=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -D__USE_UNIX98=1     -O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -Werror=declaration-after-statement -fno-builtin -fno-common -Werror=return-type -DHAVE_STDINT_H=1 -DHAVE_DIRENT_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_INTTYPES_H=1 -DGX_COLOR_INDEX_TYPE="unsigned long long" -D__USE_UNIX98=1     -I./base -I./obj/ -I./zlib ./base/mkromfs.c -o ./obj/aux/mkromfs_0 ./obj/aux/compress.o ./obj/aux/deflate.o ./obj/aux/zutil.o ./obj/aux/adler32.o ./obj/aux/crc32.o ./obj/aux/trees.o ./obj/aux/gpmisc.o ./obj/aux/gp_getnv.o ./obj/aux/gscdefs.o ./obj/aux/gp_unix.o ./obj/aux/gp_unifs.o ./obj/aux/gp_unifn.o ./obj/aux/gp_stdia.o ./obj/aux/gsutil.o ./obj/aux/memento.o  -ldl -lm  -lidn -rdynamic -ldl -lfontconfig -lfreetype    
./obj/aux/gp_unix.o: In function `gp_enumerate_fonts_init':
gp_unix.c:(.text+0x346): undefined reference to `dmprintf_file_and_line'
./obj/aux/gp_unix.o: In function `gp_enumerate_fonts_next':
gp_unix.c:(.text+0x654): undefined reference to `dmprintf_file_and_line'
gp_unix.c:(.text+0x682): undefined reference to `dmprintf_file_and_line'
gp_unix.c:(.text+0x6b4): undefined reference to `dmprintf_file_and_line'
gp_unix.c:(.text+0x6f2): undefined reference to `dmprintf_file_and_line'
./obj/aux/gp_unix.o:gp_unix.c:(.text+0x722): more undefined references to `dmprintf_file_and_line' follow
collect2: error: ld returned 1 exit status
make: *** [obj/aux/mkromfs_0] Error 1

I can provide more build info if needed.

Looks like that last problem can be papered over with a difference in ./configure parameters? If I rerun my build with:

./configure --disable-fontconfig

then the relevant code gets dropped from obj/aux/gp_unix.o, and everything can compile/link fine.

I think this shows some deficiency in the way that AUX files are generated.

It looks like I included a bunch of flags not require or bad for the aux tools. The basic build should work now.

Created attachment 12308 [details]
[PATCH] unix-aux: don't build AUX files with target CFLAGS

One more cross compile issue

Created attachment 12309 [details]
[PATCH] xps.mak: drop unnecessary header dependency

Another issue, when using the system (shared) libpng:

make[2]: *** No rule to make target 'src/png.h', needed by 'soobj/xpspng.o'.  Stop.

I think the attached patch is reasonable? Not sure why the dependency was required in the first place, actually.

Your unix-aux.mak is fine, but there were a couple of other things in there that, now you've drawn my attention to them, were wrong - we may well find others as we go.... but I've dealt with the ones I see, as well as your changes.

The png.h dependency seems to have been a typo (quite possibly mine), because xpspng.c does include *our* header png_.h, so I've changed it to that.

Ping. Are you still working on this Chris? I'm testing your latest work and it seems to get my configuration cross-compiling OK now. There are probably still the other problems you mentioned, but I'm not sure it's absolutely necessary for tests to run for the cross-build.

We do still need to resolve bug 696506 to get the proper type info for the target, not the build host, but I've been hacking around that for now.

I've been busy with other things, but this has certainly not dropped off my radar.

There are a very few more things in the configure script I want to clean up, then I should get this stuff onto the Ghostscript master branch (that does not imply it will be "finished", just in a state that I'm happy it shouldn't break any existing functionality), then I can start looking more closely at the genarch side of things.

*** Bug 696506 has been marked as a duplicate of this bug. ***

What I've done is, using the patches on Bug 696506 as a basis, I've added support in configure so that *when cross compiling*, configure will create am arch.h and pass the file name to the rest of the build system (genarch will still run, but will use the pre-defined file contents, rather than generate its own). If we're not cross compiling, the existing use of genarch will remain.

There remain some issues that I think relate to pkconfig that I would like to resolve before moving this onto master.

A few more problems:

My build env needs different LDFLAGS for the native and cross toolchains (to fix arch-specific errata). So I guess we need to support providing an LDFLAGSAUX too?

Attaching a patch to fix that shortly.

I also don't know what you're trying to do here in configure.ac:

  SUBCONFPARMS=
  for parm in $OPARMS ; do
    SUBCONFPARMS="$(echo $parm | grep -v CC | grep -v CCAUX | grep -v CFLAGSAUX | grep -v CFLAGS) $SUBCONFPARMS"
  done

You never use the result of SUBCONFPARMS later in the file... also, if you were trying to locate certain --with-XXX flags to pass to the sub-configure -- please don't. Do we really need all the same dependencies for both the build system and for the target?

And a few more notes on that shell snippet above: you could avoid all the pipes by using grep better:

    SUBCONFPARMS="$(grep -v -e ^CC -e ^CCAUX -e ^CFLAGSAUX -e ^LDFLAGSAUX "$parm") $SUBCONFPARMS"

You also need better quoting around $OPARMS, and $parm, if you want to handle anything with spaces.

Created attachment 12606 [details]
[PATCH] add LDFLAGSAUX

(In reply to Brian Norris from comment #28)
> A few more problems:
> 
> My build env needs different LDFLAGS for the native and cross toolchains (to
> fix arch-specific errata). So I guess we need to support providing an
> LDFLAGSAUX too?
> 
> Attaching a patch to fix that shortly.

I've applied that, thanks.

TBH, I'm not sure about using the:
THINGAUX="${THINGAUX:-$THING}"

construct for CFLAGSAUX and LDFLAGSAUX. It means you *have* to specify both CFLAGSAUX and LDFLAGSAUX if you have specific CFLAGS and LDFLAGS for your target - you can't leave it to configure to find reasonably defaults for CFLAGSAUX and LDFLAGSAUX. I just stumbled across that yesterday, so I need to have a think about that.

> I also don't know what you're trying to do here in configure.ac:
> 
>   SUBCONFPARMS=
>   for parm in $OPARMS ; do
>     SUBCONFPARMS="$(echo $parm | grep -v CC | grep -v CCAUX | grep -v
> CFLAGSAUX | grep -v CFLAGS) $SUBCONFPARMS"
>   done
> 
> You never use the result of SUBCONFPARMS later in the file... also, if you
> were trying to locate certain --with-XXX flags to pass to the sub-configure
> -- please don't.

Given that the greps were searching for CC, CCAUX CFLAGSAUX and CFLAGS, and eliminating those, I'm not sure why you'd think it was eliminating --with- options.....

Anyway, not, it's not required - the remnants of an earlier experiment that I forgot to remove.

> Do we really need all the same dependencies for both the
> build system and for the target?

We need a fairly wide cross section (if you look at the recursive call to configure, a load of options are disabled/withouted). I originally set off down the route of testing each common requirement explicitly for both the cross compiler and the native compiler - that proved unwieldy, with, I felt, too much duplicated code and the hassles that go along with that.

(In reply to Chris Liddell (chrisl) from comment #30)

usually the construct is something like:
  if test "$cross_compiling" = "no"; then
    THINGAUX="${THINGAUX:-$THING}"
  fi

it's not 100% correct, but it works the vast majority of the time.

So I'm having some more problems. I think although the compile completes successfully, it's still getting a few things wrong. I haven't quite figured out where things went wrong exactly, but Ghostscript is choking for me when run with 'gstoraster'. Here's some snippets out of my system/cups log. (Notably, ghostscript is *not* actually returning an error properly, which seems to be a bug on its own. But hpcups notices that it doesn't actually get any raster input from Ghostscript.)

Tests done on 9.19 + your CCAUX patches:


2016-06-24T14:40:38.901292-07:00 DEBUG cupsd[19388]: [Job 6] 3 filters for job:
2016-06-24T14:40:38.901310-07:00 DEBUG cupsd[19388]: [Job 6] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
2016-06-24T14:40:38.901337-07:00 DEBUG cupsd[19388]: [Job 6] gstoraster (application/vnd.cups-pdf to application/vnd.cups-raster, cost 99)
2016-06-24T14:40:38.901354-07:00 DEBUG cupsd[19388]: [Job 6] hpcups (application/vnd.cups-raster to printer/HP_OFFICE_4, cost 0)

[...]

2016-06-24T14:40:38.903009-07:00 INFO cupsd[19388]: [Job 6] Started filter /usr/libexec/cups/filter/pdftopdf (PID 27)
2016-06-24T14:40:38.903685-07:00 INFO cupsd[19388]: [Job 6] Started filter /usr/libexec/cups/filter/gstoraster (PID 28)
2016-06-24T14:40:38.904277-07:00 INFO cupsd[19388]: [Job 6] Started filter /usr/libexec/cups/filter/hpcups (PID 29)
2016-06-24T14:40:38.904866-07:00 INFO cupsd[19388]: [Job 6] Started backend /usr/libexec/cups/backend/ipp (PID 30)

[...]

2016-06-24T14:59:53.459087-07:00 DEBUG cupsd[19388]: [Job 7] Color Manager: ICC Profile: None
2016-06-24T14:59:53.459729-07:00 DEBUG cupsd[19388]: [Job 7] Ghostscript command line: /usr/bin/gs -dQUIET -dPARANOIDSAFER -dNOPAUSE -dBATCH -dNOINTERPOLATE -sDEVICE=cups -sstdout=%stderr -sOutputFile=%stdout -sOutputType=0 -r600x600 -dMediaPosition=1 -dDEVICEWIDTHPOINTS=612 -dDEVICEHEIGHTPOINTS=792 -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=1 -dcupsInteger0=2 -scupsPageSizeName=Letter -I/usr/share/cups/fonts -c \'<</.HWMargins[8.400000 8.400000 8.400024 8.400024] /Margins[0 0]>>setpagedevice\' -f -_
2016-06-24T14:59:53.459749-07:00 DEBUG cupsd[19388]: [Job 7] envp[0]=\"CUPS_CACHEDIR=/var/cache/cups\"
2016-06-24T14:59:53.459759-07:00 DEBUG cupsd[19388]: [Job 7] envp[1]=\"CUPS_DATADIR=/usr/share/cups\"
2016-06-24T14:59:53.460078-07:00 DEBUG cupsd[19388]: [Job 7] envp[2]=\"CUPS_DOCROOT=/usr/share/cups/html\"
2016-06-24T14:59:53.460096-07:00 DEBUG cupsd[19388]: [Job 7] envp[3]=\"CUPS_FONTPATH=/usr/share/cups/fonts\"
2016-06-24T14:59:53.460106-07:00 DEBUG cupsd[19388]: [Job 7] envp[4]=\"CUPS_REQUESTROOT=/var/spool/cups\"
2016-06-24T14:59:53.460116-07:00 DEBUG cupsd[19388]: [Job 7] envp[5]=\"CUPS_SERVERBIN=/usr/libexec/cups\"
2016-06-24T14:59:53.460125-07:00 DEBUG cupsd[19388]: [Job 7] envp[6]=\"CUPS_SERVERROOT=/etc/cups\"
2016-06-24T14:59:53.460134-07:00 DEBUG cupsd[19388]: [Job 7] envp[7]=\"CUPS_STATEDIR=/run/cups\"
2016-06-24T14:59:53.460143-07:00 DEBUG cupsd[19388]: [Job 7] envp[8]=\"HOME=/var/spool/cups/tmp\"
2016-06-24T14:59:53.460152-07:00 DEBUG cupsd[19388]: [Job 7] envp[9]=\"PATH=/usr/libexec/cups/filter:/usr/bin:/usr/sbin:/bin:/usr/bin\"
2016-06-24T14:59:53.460162-07:00 DEBUG cupsd[19388]: [Job 7] envp[10]=\"SERVER_ADMIN=root@localhost\"
2016-06-24T14:59:53.460171-07:00 DEBUG cupsd[19388]: [Job 7] envp[11]=\"SOFTWARE=CUPS/2.1.2\"
2016-06-24T14:59:53.460180-07:00 DEBUG cupsd[19388]: [Job 7] envp[12]=\"TMPDIR=/var/spool/cups/tmp\"
2016-06-24T14:59:53.460189-07:00 DEBUG cupsd[19388]: [Job 7] envp[13]=\"USER=root\"
2016-06-24T14:59:53.460198-07:00 DEBUG cupsd[19388]: [Job 7] envp[14]=\"CUPS_MAX_MESSAGE=2047\"
2016-06-24T14:59:53.460208-07:00 DEBUG cupsd[19388]: [Job 7] envp[15]=\"CUPS_SERVER=/run/cups/cups.sock\"
2016-06-24T14:59:53.461406-07:00 DEBUG cupsd[19388]: [Job 7] envp[16]=\"CUPS_ENCRYPTION=IfRequested\"
2016-06-24T14:59:53.461434-07:00 DEBUG cupsd[19388]: [Job 7] envp[17]=\"CHARSET=utf-8\"
2016-06-24T14:59:53.461445-07:00 DEBUG cupsd[19388]: [Job 7] envp[18]=\"LANG=en_US.UTF-8\"
2016-06-24T14:59:53.461455-07:00 DEBUG cupsd[19388]: [Job 7] envp[19]=\"PPD=/var/cache/cups/printers/ppd/HP_OFFICE_4.ppd\"
2016-06-24T14:59:53.461465-07:00 DEBUG cupsd[19388]: [Job 7] envp[20]=\"RIP_MAX_CACHE=128m\"
2016-06-24T14:59:53.461475-07:00 DEBUG cupsd[19388]: [Job 7] envp[21]=\"CONTENT_TYPE=application/pdf\"
2016-06-24T14:59:53.461485-07:00 DEBUG cupsd[19388]: [Job 7] envp[22]=\"DEVICE_URI=ipp://192.168.1.4/\"
2016-06-24T14:59:53.461496-07:00 DEBUG cupsd[19388]: [Job 7] envp[23]=\"PRINTER_INFO=HP_OFFICE_4\"
2016-06-24T14:59:53.461505-07:00 DEBUG cupsd[19388]: [Job 7] envp[24]=\"PRINTER_LOCATION=\"
2016-06-24T14:59:53.461515-07:00 DEBUG cupsd[19388]: [Job 7] envp[25]=\"PRINTER=HP_OFFICE_4\"
2016-06-24T14:59:53.461524-07:00 DEBUG cupsd[19388]: [Job 7] envp[26]=\"PRINTER_STATE_REASONS=none\"
2016-06-24T14:59:53.461548-07:00 DEBUG cupsd[19388]: [Job 7] envp[27]=\"CUPS_FILETYPE=document\"
2016-06-24T14:59:53.461558-07:00 DEBUG cupsd[19388]: [Job 7] envp[28]=\"FINAL_CONTENT_TYPE=application/vnd.cups-raster\"
2016-06-24T14:59:53.461568-07:00 DEBUG cupsd[19388]: [Job 7] envp[29]=\"AUTH_INFO_REQUIRED=none\"
2016-06-24T14:59:53.477625-07:00 DEBUG cupsd[19388]: [Job 7] Unknown device: cups
2016-06-24T14:59:53.478274-07:00 DEBUG cupsd[19388]: [Job 7] ./base/gsicc_manage.c:1130: gsicc_open_search(): Could not find default_gray.icc 
2016-06-24T14:59:53.478308-07:00 DEBUG cupsd[19388]: [Job 7] | ./base/gsicc_manage.c:1760: gsicc_set_device_profile(): cannot find device profile
2016-06-24T14:59:53.478544-07:00 DEBUG cupsd[19388]: [Job 7] Unrecoverable error: unknownerror in .special_op
2016-06-24T14:59:53.478683-07:00 DEBUG cupsd[19388]: [Job 7] Operand stack:
2016-06-24T14:59:53.478792-07:00 DEBUG cupsd[19388]: [Job 7] defaultdevice
2016-06-24T14:59:53.480364-07:00 DEBUG cupsd[19388]: [Job 7] Unrecoverable error: undefined in .uninstallpagedevice
2016-06-24T14:59:53.480478-07:00 DEBUG cupsd[19388]: [Job 7] Operand stack:
2016-06-24T14:59:53.480621-07:00 DEBUG cupsd[19388]: [Job 7] defaultdevice
2016-06-24T14:59:53.482831-07:00 DEBUG hpcups[22218]: prnt/hpcups/HPCupsFilter.cpp 565: cupsRasterOpen failed, fd = 0
2016-06-24T14:59:53.482861-07:00 DEBUG cupsd[19388]: [Job 7] PID 33 (/usr/libexec/cups/filter/gstoraster) exited with no errors.
2016-06-24T14:59:53.482873-07:00 DEBUG cupsd[19388]: [Job 7] prnt/hpcups/HPCupsFilter.cpp 565: cupsRasterOpen failed, fd = 0
2016-06-24T14:59:53.483481-07:00 DEBUG cupsd[19388]: [Job 7] PID 34 (/usr/libexec/cups/filter/hpcups) stopped with status 1.



Any tips or help would be appreciated.

My debugging so far suggests that it's a problem with trying to find the file '%rom%iccprofiles/default_gray.icc' -- where '%rom%' is getting translated to an empty string, instead of finding /usr/share/ghostscript/9.19/iccprofiles/default_gray.icc.

I have a build I hacked to cross compile on 9.18 (not using this patch set) and it finds /usr/share/ghostscript/9.18/iccprofiles/default_gray.icc and prints successfully, so I'm pretty sure this patch set just isn't getting something configured right.

Created attachment 12640 [details]
[PATCH] allow specifying $CUPSCONFIG for cross-compile

Ah, I figured it out. You've made it so that I can't get 'cups' device support when cross compiling. I'm not sure how best to do that... For my cross-compile environment, I have a cross-targeted cups-config binary, which is generated by the cross-compilation of CUPS, but runs on the host system. So if you relax the ./configure to allow inheriting the $CUPSCONFIG variable properly again, then things work fine.

Patch attached to do just that.

(In reply to Brian Norris from comment #33)
> Created attachment 12640 [details]
> [PATCH] allow specifying $CUPSCONFIG for cross-compile
> 
> Ah, I figured it out. You've made it so that I can't get 'cups' device
> support when cross compiling. I'm not sure how best to do that... For my
> cross-compile environment, I have a cross-targeted cups-config binary, which
> is generated by the cross-compilation of CUPS, but runs on the host system.
> So if you relax the ./configure to allow inheriting the $CUPSCONFIG variable
> properly again, then things work fine.

Ah, I had forgotten about that. I do wish cups would ditch cups-config and either do without, or use pkg-config.....

> Patch attached to do just that.

I'm surprised that works as you'll be missing the cups specific CFLAGS and LDFLAGS. And I have a vague memory of getting false positives just checking for the headers, but I may be mis-remembering that.

I'll look at it again on Monday.

(In reply to Chris Liddell (chrisl) from comment #34)
> I'm surprised that works as you'll be missing the cups specific CFLAGS and
> LDFLAGS. And I have a vague memory of getting false positives just checking
> for the headers, but I may be mis-remembering that.

No, you won't necessarily be missing the CFLAGS and LDFLAGS, will you? If you specify the cross-targeted cups-config (e.g., /usr/bin/armv7a-linux-gnueabi-cups-config) in $CUPSCONFIG, then it'll be able to provide the right --libs, --image, --cflags, and --ldflags options.

Would it be best to use same trick/hack for cups-config that I used for pkg-config using a combination of AC_PATH_TOOL() and AC_PATH_PROG() to get reasonably sane/consistent results when and when not cross-compiling?

(In reply to Chris Liddell (chrisl) from comment #36)
> Would it be best to use same trick/hack for cups-config that I used for
> pkg-config using a combination of AC_PATH_TOOL() and AC_PATH_PROG() to get
> reasonably sane/consistent results when and when not cross-compiling?

That wouldn't work, I don't think, although I'm really not an expert at these things. (Mike is many times more knowledgeable of these things.) But the cross-targeted cups-config is not actually installed at /usr/bin/${CHOST}-cups-config for me -- that was just an example. It's actually under a separate root path, like /build/${BOARD}/usr/bin/${CHOST}-cups-config. So I think that has to be provided by the cross-compiler environment. Such is life when using a custom-rolled non-pkg-config tool like cups-config...

BTW, is this comment still true (from you configure.ac)?

        # We MUST NOT use PKG_CHECK_MODULES since it is a) not a standard
        # autoconf macro and b) requires pkg-config on the system, which is
        # NOT standard on ANY OS, including Linux!

Isn't it possible to safely use PKG_CHECK_MODULES only for pkg-config systems, and fall back to non-pkg-config only when not present?

(In reply to Brian Norris from comment #37)
> (In reply to Chris Liddell (chrisl) from comment #36)
> > Would it be best to use same trick/hack for cups-config that I used for
> > pkg-config using a combination of AC_PATH_TOOL() and AC_PATH_PROG() to get
> > reasonably sane/consistent results when and when not cross-compiling?
> 
> That wouldn't work, I don't think, although I'm really not an expert at
> these things. (Mike is many times more knowledgeable of these things.) But
> the cross-targeted cups-config is not actually installed at
> /usr/bin/${CHOST}-cups-config for me -- that was just an example. It's
> actually under a separate root path, like
> /build/${BOARD}/usr/bin/${CHOST}-cups-config. So I think that has to be
> provided by the cross-compiler environment. Such is life when using a
> custom-rolled non-pkg-config tool like cups-config...

So, something comprising both approaches:
http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=cad02a59



> BTW, is this comment still true (from you configure.ac)?
> 
>         # We MUST NOT use PKG_CHECK_MODULES since it is a) not a standard
>         # autoconf macro and b) requires pkg-config on the system, which is
>         # NOT standard on ANY OS, including Linux!
> 
> Isn't it possible to safely use PKG_CHECK_MODULES only for pkg-config
> systems, and fall back to non-pkg-config only when not present?

It depends: I'm not sure what happens if you run a configure script that calls PKG_CHECK_MODULES() on system that doesn't have (or properly support) pkg-config.

TBH, I suspect it was introduce more problems with cross compiling than it would solve, though.

Any progress on this bug?

(In reply to Chris Liddell (chrisl) from comment #38)
> So, something comprising both approaches:
> http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;
> h=cad02a59

Still stretching the limits of my expertise with autoconf, but I think that solution looks OK.

(In reply to Brian Norris from comment #39)
> Any progress on this bug?

I've been busy with other work, and also was waiting for feedback from you on the CUPSCONFIG solution I proposed - since you are the only other person actively testing this stuff, other than myself.

> (In reply to Chris Liddell (chrisl) from comment #38)
> > So, something comprising both approaches:
> > http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;
> > h=cad02a59
> 
> Still stretching the limits of my expertise with autoconf, but I think that
> solution looks OK.

Good, okay thanks.


Basically, it's too late to get into the 9.20 release. What I'd like to do is get this stuff onto the master branch immediately after we release 9.20, thus meaning it gets hammered on for six months before going into an actual release.

The remaining thing I'm kicking around is if there might be a way to get this to work without the additional makefile (auxflags.mak)..... not sure about that one.

(In reply to Chris Liddell (chrisl) from comment #40)
> Basically, it's too late to get into the 9.20 release. What I'd like to do
> is get this stuff onto the master branch immediately after we release 9.20,
> thus meaning it gets hammered on for six months before going into an actual
> release.

I believe 9.20 has been out for a while now. Any chance on getting this merged yet?

> The remaining thing I'm kicking around is if there might be a way to get
> this to work without the additional makefile (auxflags.mak)..... not sure
> about that one.

If you have any proposals, let me know and perhaps I can give it a spin. But this has been outstanding for a really long time now.

Email from a customer received that indicate that this is a customer issue.

Updated priority and customer number accordingly.

What's been holding me up (other that time!), is the interaction with the libtiff configure - but I think that's just one of those things we'll have to live with (libtiff's configure, for example, doesn't understand "arm-linux-androideabi" and similar).

Other than that, I'm pretty happy with how things stand.

I'd like to get this committed to master by the end of the week.

The state of the branch is now on the master branch:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c3c4bf02

The branch (for history) is accessible:
http://git.ghostscript.com/?p=ghostpdl.git;a=shortlog;h=refs/heads/CCAUX-configure


When (not if!) more problem are found, *please* open a new bug, and don't continue with this one.