[MacPorts] #61868: libusb @1.0.24: cannot parse USB.h with mainline gcc versions due to variant pragma handling not accepted by gcc

MacPorts noreply at macports.org
Sun Oct 24 17:56:48 UTC 2021


#61868: libusb @1.0.24: cannot parse USB.h with mainline gcc versions due to
variant pragma handling not accepted by gcc
-----------------------------------+-----------------------
  Reporter:  dgonyier              |      Owner:  michaelld
      Type:  defect                |     Status:  reopened
  Priority:  Normal                |  Milestone:
 Component:  ports                 |    Version:  2.6.4
Resolution:                        |   Keywords:
      Port:  libusb, libusb-devel  |
-----------------------------------+-----------------------

Comment (by evanmiller):

 I was talking to some witches around a boiling cauldron last night and
 think we have come up with an elegant hack / workaround:

 {{{
 #pragma options align=power
 #pragma options align=power
 #pragma options align=power

 #include <IOKit/usb/USB.h>
 }}}

 The issue here is that {{{pack}}} and {{{options}}} maintain separate
 push/pop alignment stacks, and GCC doesn't like it when you mix and match
 the stacks and attempt to pop an empty {{{options}}} stack via
 {{{align=reset}}}.

 What we can do then is "pre-load" the {{{options}}} stack with three
 values of {{{power}}}, which corresponds to an alignment of 0 (i.e. the
 default). The three invocations correspond to the three {{{align=reset}}}
 values that later appear in the IOUSBLib.h file.

 Both {{{pack}}} and {{{options}}} are setting the same global variable
 internally ({{{maximum_field_alignment}}}), so this arrangement ends up
 having the desired effect: alignment starts as 0, is set to 1 when
 {{{#pragma pack(1)}}} is encountered, and then is set back to 0 when
 {{{#pragma options align=reset}}} shows up at the end of the packed
 struct.

 After the third {{{align=reset}}}, the stack is empty and the alignment
 state is back to where it was before the inclusion. Anway this logic seems
 to hold with GCC7.5, but testing will be needed with other GCC versions.

 If the solution is as simple as this then we have our options of directly
 patching the client ports with the magic incantation, or making a very
 simple LegacySupport header that adds the three pragmas just before
 {{{#include_next}}}.

-- 
Ticket URL: <https://trac.macports.org/ticket/61868#comment:46>
MacPorts <https://www.macports.org/>
Ports system for macOS


More information about the macports-tickets mailing list