libpng: pngconf.h:366:52: error: token is not a valid binary operator in a preprocessor subexpression

[macports@…]

I have been having problems with my Macports installation. Just today, I removed everything in an attempt to replace webkit-gtk with webkit-gtl-2.0 per instructions from a failed build. Reinstallation of everything had been going smoothly until I tried installing gimp2. One of its dependencies is gegl.

I found no tickets for gegl problems with my local version @0.2.0_12.

I receive four log file errors of the form:

/opt/local/include/pngconf.h:366:52: error: token is not a valid binary operator in a preprocessor subexpression
#                       if !defined(PNG_USE_RESULT) && __has_attribute(__warn_unused_result__)

The other three tokens reported are PNG_NORETURN, PNG_ALLOCATED, and PNG_DEPRECATED with appropriate text in the __has_attribute( <VALUE> ) portion of the four lines. Each error also has a text pattern under the error with a circumflex pointing to the left-paren after the "__has_attribute" token.

There are also numerous warnings generated that appear to be of a similar form.

I run OSX 10.6.8 server on a several year old MacPro. Before I was instructed by a build error to replace webkit-gtk with webkit-gtk-2.0, gimp2 built cleanly. However, it had been some months since I had done a "selfupdate" on my macports installation. The errors could have crept in over the interval without weekly "selfupdate" executions.

I did run a "port clean gegl gimp2" and tried the gimp2 install again, but the error is repeated.

The log file generated will be attached to this ticket.

[macports@…]

main.log file from gegl build

[ryandesign (Ryan Carsten Schmidt)]

Actually this is a libpng problem (the error message refers to a libpng header). We fixed a similar error encountered with the new libpng headers in #42571 some months ago. The problem only occurred with older versions of clang. On Snow Leopard, usually the very old version of clang provided by its version of Xcode would not be used, but gegl is unusual in that it blacklists all the other compilers. You should be able to work around this by installing a newer version of clang and using that to compile gegl, for example:

sudo port clean gegl
sudo port install clang-3.4
sudo port install gegl configure.compiler=macports-clang-3.4

I will need to contact the libpng developers to see how we can fix these headers to let older versions of clang process them correctly.

[macports@…]

Replying to ryandesign@…: The steps you supplied (below) to work around the problem with clang worked.

Thank you for restating my clumsy problem description. I am again able to install gimp2 cleanly.

sudo port clean gegl
sudo port install clang-3.4
sudo port install gegl configure.compiler=macports-clang-3.4

<snip>

[dbevans (David B. Evans)]

gegl fixed to additionally blacklist clang < 300 in response to this report (r121508).

Please let me know if this works for you without having to manually specify macports-clang-3.4 as compiler.

Thanks.

[macports@…]

Replying to devans@…:

gegl fixed to additionally blacklist clang < 300 in response to this report (r121508).

Please let me know if this works for you without having to manually specify macports-clang-3.4 as compiler.

Thanks.

---

Thanks for the additional info. I have been busy of late and finally have time to try your suggestion.
Since gegl was present in my world for gimp2 and gimp-app functionality and all three were requested, I executed a port uninstall for clang-3.4@3.4.2 followed by uninstall requests for gimp2, gimp-app and gegl.
Unless I miss my guess, this should have removed all traces of the compiler version specification that was used to work around the problem earlier.

Then I executed a "port install gimp gimp-app gegl". This forced the reinstall of clang-3.4 followed by the remaining installs. I see no errors in the output. I have not tested the functionality of the entire result. That will occur later, but I see no reason to be aprehensive.

Thank you for all the support. I do apologize for letting this lie dormant for so long.

[dbevans (David B. Evans)]

Replying to macports@…:

Replying to devans@…:

gegl fixed to additionally blacklist clang < 300 in response to this report (r121508).

Please let me know if this works for you without having to manually specify macports-clang-3.4 as compiler.

Thanks.

---

Thanks for the additional info. I have been busy of late and finally have time to try your suggestion.
Since gegl was present in my world for gimp2 and gimp-app functionality and all three were requested, I executed a port uninstall for clang-3.4@3.4.2 followed by uninstall requests for gimp2, gimp-app and gegl.
Unless I miss my guess, this should have removed all traces of the compiler version specification that was used to work around the problem earlier.

Specifying the compiler on the command line as you did originally is only effective for the life of that one command so this was a bit excessive. It would have been sufficient to use

sudo port -n upgrade --force gegl

to test the gegl build

Then I executed a "port install gimp gimp-app gegl". This forced the reinstall of clang-3.4 followed by the remaining installs. I see no errors in the output. I have not tested the functionality of the entire result. That will occur later, but I see no reason to be aprehensive.

Thank you for all the support. I do apologize for letting this lie dormant for so long.

Glad its working for you and thanks for the verification.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

I will need to contact the libpng developers to see how we can fix these headers to let older versions of clang process them correctly.

I did contact the developers; they put a fix into libpng 1.6.12rc03. The libpng port is at version 1.6.12 so it should include this fix, so it should be safe to revert r121508 now.

[dbevans (David B. Evans)]

Replying to ryandesign@…:

Replying to ryandesign@…:

I will need to contact the libpng developers to see how we can fix these headers to let older versions of clang process them correctly.

I did contact the developers; they put a fix into libpng 1.6.12rc03. The libpng port is at version 1.6.12 so it should include this fix, so it should be safe to revert r121508 now.

Not sure this is worth the effort since clang < 300 is known to be a problem in general and I can't confirm the results locally. Can you confirm that the port now builds correctly on SL with the clang < 300 blacklist term removed?

[ryandesign (Ryan Carsten Schmidt)]

Actually I'm not able to reproduce the original gegl build failure (on Mac OS X 10.6.8, with Xcode 3.2.6, with libpng downgraded to 1.6.10, with r121508 reverted from gegl).

Daniel (I think?), it looks like we never asked you what version of Xcode and clang you're using. Could you let us know? Run "clang -v" to get the clang version; get info on the Xcode application in the Applications folder in the Developer folder to get the Xcode version. Thanks.

[dbevans (David B. Evans)]

Yes, even before r121508 it built on the SL buildbot (which is why I asked him to use -s when rebuilding). So I'm guessing this is on a 32 bit platform. Knowing Xcode and clang version would be helpful to understand the situation.

[ryandesign (Ryan Carsten Schmidt)]

He said "MacPro", all of which are 64-bit. I'm guessing he has an older version of Xcode, with an older version of clang, before they added support for __has_attribute. I can try installing an older Xcode on my Snow Leopard machine.

[dbevans (David B. Evans)]

OK, if you have nothing better to do and if you can narrow the version of clang that is failing, go ahead and update the blacklist clang version. However, as things stand, the problem has been fixed so I would just call it fixed and get on with other things.

[macports@…]

I have Xcode 3.2.3 (1688) installed and "clang -v" shows the following

.....:.....$ clang -v
Apple clang version 1.5 (tags/Apple/clang-60)
Target: x86_64-apple-darwin10
Thread model: posix
.....:.....$

The following versions of clang are installed:

.....:.....$ port installed clang*
The following ports are currently installed:
  clang-3.3 @3.3_5+analyzer+python27 (active)
  clang-3.4 @3.4_4+analyzer
  clang-3.4 @3.4.2_1+analyzer (active)
  clang_select @1.0_0 (active)
.....:.....$

I do have a MacPro v1.1 that runs 64bit Intel apps as well as older PowerPC processor emulation for scanner & financial data.

Fwiw, some of the browser versions I use do not run as 64-bit. Crome & Opera run as 32bit while Safari & Firefox run as 64bit.

All are upgraded to the most recent levels available for my platform. FYI, Firefox is a memory hog. The others, not as much.
Again, thanks for the help. I did not understand that the compiler specification had no permanence.

Is there a newer version of Xcode I can use in my environment?

Thanks for any info you can provide.
D

[ryandesign (Ryan Carsten Schmidt)]

Yes, Xcode 3.2.6 is available for Snow Leopard, and you should upgrade to that version. See ​https://guide.macports.org/#installing.xcode.snowleopard

I guess __has_attribute got added to clang after version 1.5, but by version 1.7. I've just installed Xcode 3.2 which comes with clang 1.0 and I'll see if I can replicate the problem there.

[ryandesign (Ryan Carsten Schmidt)]

Confirmed issue with clang 1.0, and that libpng 1.6.12 fixed it.

Removed blacklisting for old clang from gegl in r122152.