privoxy fail to build with macports 2.0: "can not open CC_PRINT_OPTIONS_FILE"

[nicolas.private@…]

I am using 10.7 and trying to install privoxy from clean macports install (2.0).

Here is the log :

debug:configure changing euid/egid - current euid: 0 - current egid: 0
:debug:configure egid changed to: 503
:debug:configure euid changed to: 504
:debug:build build phase started at Sun Jul 24 19:49:20 CEST 2011
:notice:build --->  Building privoxy
:debug:build Executing org.macports.build (privoxy)
:debug:build Environment: CPATH='/opt/local/include' CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_privoxy/privoxy/work/.CC_PRINT_OPTIONS' LIBRARY_PATH='/opt/local/lib' CC_PRINT_OPTIONS='YES' MACOSX_DEPLOYMENT_TARGET='10.7'
:debug:build Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_privoxy/privoxy/work/privoxy-3.0.17-stable" && /usr/bin/make -j2 -w all'
:debug:build Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_privoxy/privoxy/work/privoxy-3.0.17-stable" && /usr/bin/make -j2 -w all 
:info:build make: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_privoxy/privoxy/work/privoxy-3.0.17-stable'
:info:build /Developer/usr/bin/llvm-gcc-4.2 -c -pipe -pipe -O2 -arch x86_64 -I/opt/local/include  -Dunix -Wall   actions.c -o actions.o
:info:build /Developer/usr/bin/llvm-gcc-4.2 -c -pipe -pipe -O2 -arch x86_64 -I/opt/local/include  -Dunix -Wall   cgi.c -o cgi.o
:info:build can not open CC_PRINT_OPTIONS_FILE /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_privoxy/privoxy/work/.CC_PRINT_OPTIONS
:info:build can not open CC_PRINT_OPTIONS_FILE /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_privoxy/privoxy/work/.CC_PRINT_OPTIONS
:info:build make: *** [actions.o] Error 1
:info:build make: *** Waiting for unfinished jobs....
:info:build make: *** [cgi.o] Error 1

It seems that there is a problem between uid/gid change (503/504) and CC_PRINT_OPTIONS_FILE permissions.

To fix the problem I just change permission on CC_PRINT_OPTIONS_FILE file to 777 :

sudo chmod 777 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_www_privoxy/privoxy/work/.CC_PRINT_OPTIONS

Regards, Nicolas.

[ryandesign (Ryan Carsten Schmidt)]

Perhaps you began the build using MacPorts 1.9.2, interrupted it, upgraded to MacPorts 2.0.0, and are now trying to continue the same build? That would not be recommended. Did you try just cleaning the port first?

sudo port clean privoxy

[crispy1975@…]

I had this exact same error. I have cleaned out the port many times and tried to reinstall. After altering the permissions of CC_PRINT_OPTIONS_FILE to 777 the install worked as expected.

[mfeiri]

This problem occurs on 10.6 too. It is an issue with the new privilege dropping feature in macports 2.0. The CC_PRINT_OPTIONS_FILE gets created during the configure phase. When macports proceeds to the build phase the privileges get dropped and the compiler can not write to the CC_PRINT_OPTIONS_FILE any more. I can add a small "file delete ${workpath}/.CC_PRINT_OPTIONS" in post-configure as a workaround, but I would classify this as a bug in macports 2.0.

[ryandesign (Ryan Carsten Schmidt)]

Replying to mfeiri@…:

The CC_PRINT_OPTIONS_FILE gets created during the configure phase. When macports proceeds to the build phase the privileges get dropped and the compiler can not write to the CC_PRINT_OPTIONS_FILE any more.

Why would MacPorts' ability to write to the .CC_PRINT_OPTIONS file be any different during the build phase than it is during the configure phase?

Why would this issue affect only the privoxy port?

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #30996.

[mfeiri]

Don't know why this is happening, but it is happening. Added workaround in r84392.