1. On static systems LIBS must have -lz appended. Enforce it. 2. Use pkgconfig to check for libtiff-4 on systems which may have it. 3. When using ALL, turn off opvp/oprp if it can't be supported. 4. Actually check the enable-dynamic flag to turn on shared support. 5. Disable sha2 as openssl has these functions and it fails on static only systems.
Created attachment 8053 [details] static build fixes
These changes break our default build, so I cannot apply the patch as it stands.
Hi Chris, Can you let me know how you are building and on what system and I'll check ?
Hi Alan, I just used the archived as we release, download here: http://www.ghostscript.com/download/gsdnld.html Apply your patch, then, in the ghostscript directory: ./autogen.sh make result: ./obj/ssha2.o: In function `s_SHA256E_process': ssha2.c:(.text+0x70): undefined reference to `SHA256_Update' ssha2.c:(.text+0x92): undefined reference to `SHA256_Final' ./obj/ssha2.o: In function `s_SHA256E_init': ssha2.c:(.text+0xb9): undefined reference to `SHA256_Init' collect2: ld returned 1 exit status make: *** [bin/gs] Error 1 On Ubuntu 11.04. It should be reproducible on any common distribution/platform combo. Please take note that the base/*.mak files are (mostly) common to all platforms, so cannot contain GNU make-isms. In fact, we'd prefer to have no GNU make specific features anywhere in the build (although I think a couple have crept into the top Makefile). So, for example, conditionals would not be allowed, nor would shell call outs.
O.k. I got it. Seems that on the static system I've got cups is linking with -lssl -lcrypto which OpenSSL already has SHA256_Update/Init/Final. But on Linux, it doesn't. So I guess the easiest option is to rename these functions in sha2.c, and update ssha2.c to call these instead. Is that acceptable ?
Drat, silly of me - I forgot there is already a bug open about that, and yes, my plan was to rename the symbols in there. I'd planned to simply prepend "gs_" to the names, I figured that would be clear enough what was going on. I do want to check through your other changes in more detail - I only looked *very* briefly because I'm middle of something else, right now.
Created attachment 8054 [details] new build patch Renames SHA256_Init/Update/Final to pSHA256_Init/Update/Final to indicate private version.
Alan, Apologies for the delay - been a bit snowed under...... The next issue I see is your addition of "-lz" to the library list. By default, the build uses the zlib sources included in the release archive, so we really don't want to try to link in zlib. Normally, just removing/renaming the zlib directory from the Ghostscript tree is all that's needed to force the system zlib to be linked in - the build system adds the "-lz" automatically under those circumstances. So, could you explain the reason for adding zlib to the library list in the configure script? Thanks
Hi Chris, And sorry for the delay getting back to you. This hunk of the patch can be deleted. It turned out to be a bug in pkg-config for our platform. Fixed now, so that small hunk can go. Cheers,
Alan, Patch applied: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=f52122 Thanks for the contribution. It would be great if you could grab the sources, and test it on your system, just to be sure. You can reopen the bug if there's a problem. (sorry for the delay, we had a staff meeting last week) Chris
Hi Chris, It seems a later fix in another part of ghostscript exposed the SHA256_Transform() function too. So in base/sha2.c look for this and change to pSHA256_Transform(). Thanks !
Hi Alan, I made that change here: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c974aa83 Thanks for spotting it. If another case comes up, if you could open a new bug for it, please - it's better for our tracking that way. Cheers, Chris