groff @1.22.4 +universal: automake.pdf differs and cannot be merged

[RobbieNutland (Robbie Nutland)]

Posting here in case someone else experiences the same problem.

I was trying to build groff v1.22.4 with the universal variant on macOS 10.13.6 to produce binaries for both i386 and x86_64 architecture.

'port install groff +universal' would fail at the 'destroot' phase. Seemingly, multiple destroot directories were being created for each architecture type due to the way that muniversal defined the universal variant. This ultimately led to the destroot phase complaining that select files could not be merged as their architecture could not be identified by 'libtool'/'lipo' or becuase they differed when evaluated through 'cmp'/'diff'.

To resolve this, it was necessary to comment out line 5 of the groff Portfile:

PortGroup           muniversal 1.1

To:

#PortGroup           muniversal 1.1

Subsequently, cleaning the port and reattempting an install of groff succeeded.
Hope that helps - Rob.

[ryandesign (Ryan Carsten Schmidt)]

Removing the muniversal portgroup would unfix #66631 so before we jump to that conclusion, please attach the two differing files to this ticket so that we can see how they differ and if we can somehow resolve that difference.

[kencu (Ken)]

there are several aspects of gnulib that do not appear to be able to be built in one pass using multiple arch flags.

specifically, the macros that check for ssize_t and sys_types always seem to fail building universal on arm Macs.

If we could get those fixed, I think we could remove the muniversal PG in many places, but I am sorry that my knowledge is not sufficient to fix those macros properly.

The ssize_t one can be bypassed with a build argument, but the sys_types one I can't seem to bypass. (assuming that bypassing them is the right fix).

[ryandesign (Ryan Carsten Schmidt)]

Sure would be great to fix gnulib so that it does not have that problem.

[RobbieNutland (Robbie Nutland)]

With muniversal in Portfile, fails. Generated by: sudo port -d install groff +universal

[RobbieNutland (Robbie Nutland)]

Without muniversal in Portfile, succeeds. Generated by: sudo port -d install groff +universal

[RobbieNutland (Robbie Nutland)]

Replying to ryandesign:

Removing the muniversal portgroup would unfix #66631 so before we jump to that conclusion, please attach the two differing files to this ticket so that we can see how they differ and if we can somehow resolve that difference.

As kencu highlights, the aforementioned ticket relates to arm macs whereas I am using an intel chipset so it looks like we are targeting different architectures. Either way, I have attached the requested logs in the hopes it may be of some use.

[ryandesign (Ryan Carsten Schmidt)]

What I'm looking for is the two different versions of the file that cannot be merged:

• /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_groff/groff/work/destroot-i386/opt/local/share/doc/groff-1.22.4/pdf/automake.pdf
• /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_groff/groff/work/destroot-x86_64/opt/local/share/doc/groff-1.22.4/pdf/automake.pdf

Could you attach those? Then we can see how they differ and decide what we need to do about it.

[kencu (Ken)]

the PDFs differ?

Now that is odd.

[RobbieNutland (Robbie Nutland)]

From the 'destroot-i386' destdir.

[RobbieNutland (Robbie Nutland)]

From the 'destroot-x86_64' destdir.

[RobbieNutland (Robbie Nutland)]

Replying to ryandesign:

What I'm looking for is the two different versions of the file that cannot be merged:

• /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_groff/groff/work/destroot-i386/opt/local/share/doc/groff-1.22.4/pdf/automake.pdf
• /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_sysutils_groff/groff/work/destroot-x86_64/opt/local/share/doc/groff-1.22.4/pdf/automake.pdf

Could you attach those? Then we can see how they differ and decide what we need to do about it.

Ryan, I've uploaded the requested PDFs and made a backup of the work directory for the failed build in case you are interested in looking at anything further.

[kencu (Ken)]

your two PDF files differ slightly in creation date and modification date.

the question is why don't I see this issue when I build it universal...

[ryandesign (Ryan Carsten Schmidt)]

Replying to RobbieNutland:

I've uploaded the requested PDFs

Thanks!

Replying to kencu:

your two PDF files differ slightly in creation date and modification date.

Agreed. I haven't looked into how these are created but that should be easy enough to fix.

the question is why don't I see this issue when I build it universal...

Your computer is so fast that it completes both archs' destroot phases within one second?

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign:

Your computer is so fast that it completes both archs' destroot phases within one second?

No, it would be the build phase. Even less likely that you could complete both archs' build phases in one second.

On my system, with trace mode, automake.pdf and most of the others don't get made because for example:

troff: doc/automake.mom:56: can't transparently output node at top level

It must be using macOS troff which I guess is too old.

Without trace mode, they do get built because it finds the troff from the already-installed groff port.

[RobbieNutland (Robbie Nutland)]

Replying to kencu:

your two PDF files differ slightly in creation date and modification date.

the question is why don't I see this issue when I build it universal...

In advance of uploading these files, I manually made a copy of them from the work folder to my desktop and renamed them to clarify where they originated from.

Would it be worth me replacing these attachments with files uploaded directly from the backup I have taken of the whole work directory?

By backup, please be mindful that this is a desktop copy of the entire work tree following a failed build, and not the original created by macports (so that I can remain in a state where groff has installed sucessfully).

[ryandesign (Ryan Carsten Schmidt)]

Your attachments are fine. They show us how the files differ:

(a) automake vs. (b) automake(from

@@ -291 +291 @@
 >>
 endobj
 90 0 obj << /Author (Bertrand Garrigues,)
-/CreationDate (D:20230505203313+01'00')
+/CreationDate (D:20230505203436+01'00')
 /Creator (groff version 1.22.4)
-/ModDate (D:20230505203313+01'00')
+/ModDate (D:20230505203436+01'00')
 /Producer (gropdf version 1.22.4)
 >>
 endobj

We also have a plausible explanation for why the pdf files were built on your system but why they didn't build for Ken and thus he didn't see the problem when he switched the port to use the muniversal portgroup. So we have two things to fix: 1, make sure the pdf files always get built, and 2, make sure they get built identically for each arch. I'm looking into it now.