[MacPorts] #24505: testdisk 6.11: cannot analyse GPT volumes (GPT: invalid header size) (was: testdisk-6.11 Reports wrong bigendian architecture)

MacPorts noreply at macports.org
Thu Apr 15 19:52:51 PDT 2010


#24505: testdisk 6.11: cannot analyse GPT volumes (GPT: invalid header size)
--------------------------------------+-------------------------------------
  Reporter:  wickedguitar6@…          |       Owner:  snc@…           
      Type:  defect                   |      Status:  closed          
  Priority:  Normal                   |   Milestone:                  
 Component:  ports                    |     Version:  1.8.2           
Resolution:  fixed                    |    Keywords:  haspatch, endian
      Port:  testdisk                 |  
--------------------------------------+-------------------------------------
Changes (by ryandesign@…):

  * keywords:  haspatch => haspatch, endian
 * cc: ryandesign@… (added)
  * port:  testdisk-6.11 => testdisk


Comment:

 Replying to [ticket:24505 wickedguitar6@…]:
 > testdisk-6.11 has a fault bigendian architecture detection in its
 configure file. Therefore if there is in the environment a "CFLAGS=-arch
 ...." argument, it assumes that the bigendian arch is universal (e.g. even
 if "CFLAGS=-arch i386"). This results in that the program cannot correctly
 analyse GPT volumes (fails with GPT: invalid header size).
 >
 > I patched the configure file so that bigendian is true only if "-arch"
 contains "ppc" or "ppc64". I also patched the Portfile.

 The autoconf variable ac_cv_c_bigendian is not being set to the value
 "true" or "false" at this point in the configure script; it is being set
 to the value "universal", whatever that means to autoconf. This "feature"
 of autoconf has never made sense to me, and your fix for it concerns me in
 that I doubt the problems experienced are specific to testdisk; it seems
 logical to me that every software package using endian detection via
 autoconf would also be affected (at least in MacPorts, where we always
 supply -arch flags, even when building for a single architecture, which is
 the situation the developers of autoconf seem not to have anticipated).
 Would you be willing to bring this issue to the attention of the
 developers of autoconf yet again and work with them towards a solution?
 IMHO the solution is to delete the ability for autoconf to detect
 endianness, since that is not the business of a configuration script but
 the business of defines in the sourcefiles. That's obviously not a
 workable solution since so much software out there already uses this
 flawed autoconf capability, but the solution they've developed so far is
 clearly not workable either, and detecting and fixing the problem in each
 individual affected port is not an effective use of anybody's time.

-- 
Ticket URL: <http://trac.macports.org/ticket/24505#comment:4>
MacPorts <http://www.macports.org/>
Ports system for Mac OS


More information about the macports-tickets mailing list