Opened 11 years ago

Closed 10 years ago

#25989 closed defect (fixed)

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

Reported by: jwhowse4 Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.9.1
Keywords: Cc: ryandesign (Ryan Schmidt), bgrupe27, soehn@…, nerdling (Jeremy Lavergne), michaelld (Michael Dickens)
Port: akonadi

Description

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?

Attachments (1)

akonadi_log.txt (468.5 KB) - added by jwhowse4 11 years ago.
debug log for akonadi build

Download all attachments as: .zip

Change History (21)

Changed 11 years ago by jwhowse4

Attachment: akonadi_log.txt added

debug log for akonadi build

comment:1 Changed 11 years ago by jmroot (Joshua Root)

Port: akonadi added

Please remember to fill in the Port field.

comment:2 Changed 11 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added
Summary: Akonadi build fails on upgradeakonadi build fails due to presence of include/utils.h

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.

comment:3 Changed 11 years ago by bgrupe27

Cc: bgrupe@… added

Cc Me!

comment:4 Changed 11 years ago by bgrupe27

I recently stumbled upon the same issue.

The mentioned utils.h is provided by cdparanoia

comment:5 Changed 11 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: newclosed

Thanks, fixed in r70374.

comment:6 Changed 11 years ago by ryandesign (Ryan Schmidt)

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

comment:7 Changed 10 years ago by dsdale24@…

Resolution: fixed
Status: closedreopened

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

comment:8 Changed 10 years ago by soehn@…

Cc: soehn@… added

Cc Me!

comment:9 Changed 10 years ago by nerdling (Jeremy Lavergne)

Cc: snc@… added

Cc Me!

comment:10 Changed 10 years ago by jmroot (Joshua Root)

Cc: michaelld@… added

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.

comment:11 Changed 10 years ago by michaelld (Michael Dickens)

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).

comment:12 Changed 10 years ago by nerdling (Jeremy Lavergne)

After installing cdparanoia, the latest akonadi built for me.

comment:13 Changed 10 years ago by nerdling (Jeremy Lavergne)

It similarly builds after r74250.

comment:14 Changed 10 years ago by michaelld (Michael Dickens)

Should now also work if cdparanoia is not installed :)

comment:15 Changed 10 years ago by nerdling (Jeremy Lavergne)

Should I check?

comment:16 Changed 10 years ago by michaelld (Michael Dickens)

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

comment:17 Changed 10 years ago by nerdling (Jeremy Lavergne)

Resolution: fixed
Status: reopenedclosed

And tested: it builds without cdparanoia.

comment:18 Changed 10 years ago by dsdale24@…

Resolution: fixed
Status: closedreopened

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?

comment:19 Changed 10 years ago by michaelld (Michael Dickens)

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.

comment:20 Changed 10 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.