akonadi build fails due to presence of cdparanoia's include/utils.h

[jwhowse4@…]

On an Intel Mac running Snow Leopard 10.6.4 and XCode 3.2.3, the akonadi build fails when upgrading from 1.3.1 to 1.4.0. The debug log is attached. It appears that the build does not find the system copy of tclIndex which is one level down in Scripts compared to where the build process is looking. However I can not seem to find where tclIndex is being called from during the build. Any suggestions?

[jwhowse4@…]

debug log for akonadi build

[jmr@…]

Please remember to fill in the Port field.

[ryandesign@…]

You are referring to these lines late in the log:

DEBUG: couldn't open "/System/Library/Frameworks/Tcl.framework/Versions/8.5/Resources/tclIndex": no such file or directory
    while executing
"open [file join $dir tclIndex]"

I don't know what tclIndex is or why MacPorts is looking for it but that is not the reason akonadi failed to build. The actual reason is further back in the log:

In file included from /opt/macports/var/macports/build/_opt_macports_var_macports_sources_rsync.macports.org_release_ports_devel_akonadi/work/akonadi-1.4.0/server/src/handler/fetchhelper.cpp:38:
/opt/macports/include/utils.h: In function 'char* copystring(const char*)':
/opt/macports/include/utils.h:90: error: invalid conversion from 'void*' to 'char*'

This in turn is probably because akonadi is trying to include the utils.h that is in its source directory in server/src/utils.h but it instead finding a copy globally installed in /opt/macports/include/utils.h. Where did that file come from? I don't have it on my system. You can use "port provides /opt/macports/include/utils.h" to find out.

[bgrupe@…]

Cc Me!

[bgrupe@…]

I recently stumbled upon the same issue.

The mentioned utils.h is provided by cdparanoia

[ryandesign@…]

Thanks, fixed in r70374.

[dsdale24@…]

I don't think r70374 fixed the problem everywhere:

:info:build In file included from /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_akonadi/work/akonadi-1.4.0/server/src/handler/fetchhelper.cpp:38:
:info:build /opt/local/include/utils.h: In function 'char* copystring(const char*)':
:info:build /opt/local/include/utils.h:90: error: invalid conversion from 'void*' to 'char*'
:info:build /opt/local/include/utils.h: In function 'char* catstring(char*, const char*)':
:info:build /opt/local/include/utils.h:100: error: invalid conversion from 'void*' to 'char*'
:info:build /opt/local/include/utils.h:102: error: invalid conversion from 'void*' to 'char*'

$ port provides /opt/local/include/utils.h 
/opt/local/include/utils.h is provided by: cdparanoia

[soehn@…]

Cc Me!

[snc@…]

Cc Me!

[jmr@…]

Confirmed. If this started happening again around 6 weeks ago (when comment:7 was posted), the change to the new KDE portgroup may have something to do with it.

[michaelld@…]

Should be fixed in r74249. Please do:

sudo port clean akonadi
sudo port selfupdate
sudo port install akonadi

and see if it works (it does for me, and didn't before with the same conflict).

[snc@…]

After installing cdparanoia, the latest akonadi built for me.

[snc@…]

It similarly builds after r74250.

[michaelld@…]

Should now also work if cdparanoia is not installed :)

[snc@…]

Should I check?

[michaelld@…]

if you want you can check w/o cdparanoia; the more important test is with since that's when the conflict was arising.

[snc@…]

And tested: it builds without cdparanoia.

[dsdale24@…]

I have cdparanoia installed, and I still have to temporarily move /opt/local/include/utils.h in order to build akonadi. This occurred this morning when I upgraded to akonadi-1.4.3. "port provides /opt/local/include/utils.h" says that file is provided by cdparanoia. Is there something I need to fix on my system, or is this still an issue that needs to be addressed upstream?

[michaelld@…]

The upgrade to 1.4.3 added some more files that #include "utils.h", and my patch targeted just those in the previous version that did so. I'm moving to use "fs-traverse" and searching -every- file. I'm compiling right now & will check in the change once it works.

[michaelld@…]

re-fixed in r74981, in a generic manner so-as to hopefully include future versions too.