ghostscript @9.23 builds incorrectly when updating

[dstrubbe (David Strubbe)]

When upgrading from version 9.22, this version of ghostscript mistakenly linked against the old version of its own library (as below), which no longer existed after that was deactivated, making use of "gsx" in ImageMagick's build fail. Not sure how to prevent this happening in the first place, but uninstalling the new version and then re-installing was successful in getting a correct build.

$ otool -L /opt/local/bin/gsx
/opt/local/bin/gsx:
        /opt/local/lib/libgs.9.22.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)

[Schamschula (Marius Schamschula)]

Hmm. When I built ghostscript 9.23, with ghostscript 9.22 installed, I did not see this error. I get

$ otool -L /opt/local/bin/gsx
/opt/local/bin/gsx:
	/opt/local/lib/libgs.9.23.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

[dstrubbe (David Strubbe)]

Ok. Not sure what would be different on my end.

[ryandesign (Ryan Carsten Schmidt)]

Yes, I can confirm this problem, on macOS 10.12.6.

[ryandesign (Ryan Carsten Schmidt)]

$ port installed ghostscript
The following ports are currently installed:
  ghostscript @9.22_0+universal+x11 (active)
$ sudo port -n build ghostscript -universal build.jobs=1
--->  Computing dependencies for ghostscript
--->  Fetching distfiles for ghostscript
--->  Verifying checksums for ghostscript
--->  Extracting ghostscript
--->  Applying patches to ghostscript
--->  Configuring ghostscript
--->  Building ghostscript
$ otool -L $(port work ghostscript)/*/sobin/{gsc,gsx,libgs.dylib}
/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk_print_ghostscript/ghostscript/work/ghostscript-9.23/sobin/gsc:
	/opt/local/lib/libgs.9.22.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk_print_ghostscript/ghostscript/work/ghostscript-9.23/sobin/gsx:
	/opt/local/lib/libgs.9.22.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
/opt/local/var/macports/build/_Users_rschmidt_macports_macports-ports-svn-trunk_print_ghostscript/ghostscript/work/ghostscript-9.23/sobin/libgs.dylib:
	/opt/local/lib/libgs.9.23.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/libXt.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/opt/local/lib/libSM.6.dylib (compatibility version 7.0.0, current version 7.1.0)
	/opt/local/lib/libICE.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libXext.6.dylib (compatibility version 11.0.0, current version 11.0.0)
	/opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
	/opt/local/lib/libtiff.5.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libpng16.16.dylib (compatibility version 51.0.0, current version 51.0.0)
	/opt/local/lib/libjbig2dec.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libjpeg.9.dylib (compatibility version 13.0.0, current version 13.0.0)
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/opt/local/lib/liblcms2.2.dylib (compatibility version 3.0.0, current version 3.8.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
	/opt/local/lib/libiconv.2.dylib (compatibility version 9.0.0, current version 9.0.0)
	/opt/local/lib/libidn.11.dylib (compatibility version 18.0.0, current version 18.16.0)
	/opt/local/lib/libpaper.1.dylib (compatibility version 3.0.0, current version 3.2.0)
	/opt/local/lib/libfontconfig.1.dylib (compatibility version 12.0.0, current version 12.1.0)
	/opt/local/lib/libfreetype.6.dylib (compatibility version 22.0.0, current version 22.0.0)

[Schamschula (Marius Schamschula)]

On a hunch, I tried upgrading ghostscript on another machine. This time w/o trace mode (my default). I see the same error.

[dershow]

The error that I see is slightly different, but is likely the same issue, so I figured I would post here, and not create a new ticket. For me here's what the upgrade attempt reports:

--->  Applying patches to ghostscript
--->  Configuring ghostscript
--->  Building ghostscript
--->  Staging ghostscript into destroot
Error: Failed to destroot ghostscript: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_print_ghostscript/ghostscript/work/destroot-i386//opt/local/share/ghostscript/9.23/doc and /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_print_ghostscript/ghostscript/work/destroot-x86_64//opt/local/share/ghostscript/9.23/doc point to different targets (can't merge them)
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_print_ghostscript/ghostscript/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

[ryandesign (Ryan Carsten Schmidt)]

Replying to dershow:

The error that I see is slightly different, but is likely the same issue

No, that is a completely unrelated issue; see #56157.

[ryandesign (Ryan Carsten Schmidt)]

In 000d9ce147e91531e3347a028627001cb1f01bc9/macports-ports:

ghostscript: Remove incorrect doc symlink

Also ensure ghostscript is not active when building ghostscript, to
ensure that the new programs don't get linked to old libraries.

See: #56137

[ryandesign (Ryan Carsten Schmidt)]

The above is crappy, but will at least ensure that the port is built correctly for everybody, to give us time to figure out the cause of the problem and/or file an upstream bug report.

[ryandesign (Ryan Carsten Schmidt)]

It's caused by ​this upstream commit. Previously, LDFLAGS were not used when building gsc and gsx; now they are. Because MacPorts puts -L/opt/local/lib into LDFLAGS by default—and because I guess they don't prepend a -L flag with the path where the new libgs.dylib was built—that makes it find the previously-installed libgs.dylib instead of the newly-built one.

I don't know if we can just remove -L/opt/local/lib from our default LDFLAGS. That might make the build unable to find the libraries it needs.

I still can't see the actual build commands that are causing this problem in the log. I don't know where in the build system they're happening, why they're hidden, or how to make them visible.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

I was unable to make much headway with understanding the ghostscript build system, but the following change

configure.ldflags-prepend \
                    -L${worksrcpath}/sobin

at least seems to keep the user from having to deactivate ghostscript before upgrading.

[ryandesign (Ryan Carsten Schmidt)]

That looks good. I had tried configure.ldflags-prepend -L. which didn't work, presumably because the build doesn't happen in the ${worksrcpath}/sobin directory. (Maybe it happens in the ${worksrcpath} directory.)

I've gotten far enough to understand:

• The gsc program (to which gs is a symlink) is built by the $(GSSOC_XE): rule in unix-dll.mak.
• The gsx program is built by the $(GSSOX_XE): rule.
• They build using $(GLCC) ... -L$(BINDIR) -l$(GS_SO_BASE).
• BINDIR is defined as ./$(BUILDDIRPREFIX)bin.
• BUILDDIRPREFIX is set by the so: target in unix-dll.mak to $(SODIRPREFIX).
• SODIRPREFIX is defined in unix-dll.mak as so.
• GS_SO_BASE is defined as gs.

So -L$(BINDIR) -l$(GS_SO_BASE) is really -Lsobin -lgs.

• GLCC is defined in lib.mak as $(CC_) $(GLCCFLAGS).
• CC_ is defined in unix-gcc.mak as $(CC) $(CCFLAGS).
• CCFLAGS is defined in unix-gcc.mak as $(GENOPT) $(CAPOPT) $(CFLAGS).
• CFLAGS is defined in Makefile.in as $(CFLAGS_STANDARD) $(GCFLAGS) $(AC_CFLAGS) $(XCFLAGS) @CLUSTER_CFLAGS@.
• GCFLAGS is defined in Makefile.in as @CPPFLAGS@ @GCFLAGS@ @CFLAGS@ @LDFLAGS@ @HAVE_POPEN_PROTO@.
• The LDFLAGS that MacPort specifies at configure time replace the @LDFLAGS placeholder above.

So our -L/opt/local/lib is part of $(GLCC); there's no opportunity to move it to after -L$(BINDIR) where it belongs.

[ryandesign (Ryan Carsten Schmidt)]

In 75a8b40b1bb272041f40a251d3deb3195ed3f8f2/macports-ports:

ghostscript: Better workaround for wrong order of -L flags

See: #56137

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

file an upstream bug report.

​https://bugs.ghostscript.com/show_bug.cgi?id=699160

[ryandesign (Ryan Carsten Schmidt)]

Upstream believes ​this commit will fix it; I haven't tested it yet.