Opened 18 months ago
Last modified 17 months ago
#67373 accepted defect
groff @1.22.4 +universal: automake.pdf differs and cannot be merged
Reported by: | RobbieNutland (Robbie Nutland) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | ||
Port: | groff |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
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.
Attachments (4)
Change History (16)
comment:1 follow-up: 4 Changed 18 months ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|
comment:2 Changed 18 months ago by 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).
comment:3 Changed 18 months ago by ryandesign (Ryan Carsten Schmidt)
Sure would be great to fix gnulib so that it does not have that problem.
Changed 17 months ago by RobbieNutland (Robbie Nutland)
Attachment: | main(with-muniversal, fails).log added |
---|
With muniversal in Portfile, fails. Generated by: sudo port -d install groff +universal
Changed 17 months ago by RobbieNutland (Robbie Nutland)
Attachment: | main(without-muniversal, succeeds).log added |
---|
Without muniversal in Portfile, succeeds. Generated by: sudo port -d install groff +universal
comment:4 Changed 17 months ago by 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.
comment:5 follow-up: 7 Changed 17 months ago by 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.
Changed 17 months ago by RobbieNutland (Robbie Nutland)
Attachment: | automake(from destroot-i386).pdf added |
---|
From the 'destroot-i386' destdir.
Changed 17 months ago by RobbieNutland (Robbie Nutland)
Attachment: | automake (from destroot-x86_64).pdf added |
---|
From the 'destroot-x86_64' destdir.
comment:7 Changed 17 months ago by 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.
comment:8 follow-ups: 9 11 Changed 17 months ago by 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...
comment:9 follow-up: 10 Changed 17 months ago by 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?
comment:10 Changed 17 months ago by 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.
comment:11 Changed 17 months ago by 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, pleae 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).
comment:12 Changed 17 months ago by ryandesign (Ryan Carsten Schmidt)
Owner: | set to ryandesign |
---|---|
Status: | new → accepted |
Summary: | Building groff v1.22.4 with the '+universal' variant → groff @1.22.4 +universal: automake.pdf differs and cannot be merged |
Your attachments are fine. They show us how the files differ:
-
(a) automake vs. (b) automake(from
a b 291 291 >> 292 292 endobj 293 293 90 0 obj << /Author (Bertrand Garrigues,) 294 /CreationDate (D:20230505203 313+01'00')294 /CreationDate (D:20230505203436+01'00') 295 295 /Creator (groff version 1.22.4) 296 /ModDate (D:20230505203 313+01'00')296 /ModDate (D:20230505203436+01'00') 297 297 /Producer (gropdf version 1.22.4) 298 298 >> 299 299 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.
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.