Opened 12 years ago
Closed 12 years ago
#35358 closed defect (fixed)
libsndfile build error on OS X 10.8 with old /Developer dir present
Reported by: | benedikt@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.2 |
Keywords: | mountainlion | Cc: | g@…, thomas@…, adam@…, andreas@… |
Port: | libsndfile |
Description
After the upgrade to mountain lion and Xcode 4.4 two days ago MacPorts started rebuilding all my installed ports. Everything went fine ( except for some minor tweaks), but it fails building libsndfile. I already found the #include bug it had a couple of years ago, but that was fixed. This one look's the same to me.
sudo port upgrade outdated dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid ---> Computing dependencies for libsndfile ---> Building libsndfile Error: org.macports.build for port libsndfile returned: command execution failed Please see the log file for port libsndfile for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_audio_libsndfile/libsndfile/main.log Error: Problem while installing libsndfile To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets
I've also attached to log file in which one can see what i mean.
I tried to uninstall libsndfile and it simply does nothing, even with the -f option. Clang build libsndfile just fine when I download it and compile it by hand, but not from within MacPorts
Attachments (2)
Change History (30)
Changed 12 years ago by benedikt@…
comment:2 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | benedikt@… removed |
---|---|
Keywords: | mountainlion added; build fail libsndfile removed |
This log was not from a clean build attempt. Please "sudo port clean libsndfile", then try again, then attach the new main.log to this ticket if it fails again.
comment:3 Changed 12 years ago by benedikt@…
Sry I did so many build that I forgot to clean it before. Here is the fresh one.
Changed 12 years ago by benedikt@…
comment:4 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
It builds fine for me on Mountain Lion 10.8.0 and Xcode 4.4.
Your log says:
:info:build /System/Library/Frameworks/CoreFoundation.framework/Headers/CFArray.h:49:1: error: unknown type name 'CF_IMPLICIT_BRIDGING_ENABLED'
I haven't seen this before, and there's only one Google result for "CF_IMPLICIT_BRIDGING_ENABLED" which wasn't helpful.
comment:6 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | g@… added |
---|
Has duplicate #35383.
comment:7 Changed 12 years ago by ks+macports@…
Something (prolly CFArray.h or sndfile-play.c) needs to #include "CFBase.h". IMO, CFArray.h is broken, but that's Apple's problem.
> grep -rsn CF_IMPLICIT_BRIDGING_ENABLED /System/Library/Frameworks/*/Headers ... /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:297:#ifndef CF_IMPLICIT_BRIDGING_ENABLED /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:299:#define CF_IMPLICIT_BRIDGING_ENABLED _Pragma("clang arc_cf_code_audited begin") /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:301:#define CF_IMPLICIT_BRIDGING_ENABLED ...
comment:8 Changed 12 years ago by ks+macports@…
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:146 eventually includes /System/Library/Frameworks/CoreFoundation.framework/Headers/CFArray.h before it defines CF_IMPLICIT_BRIDGING_ENABLED at line 297. Looks like a broken CoreFoundation header. Try to force -DCF_IMPLICIT_BRIDGING_ENABLED on the cc line?
:info:build CC sndfile-play.o :info:build In file included from sndfile-play.c:61: :info:build In file included from /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:83: :info:build In file included from /System/Library/Frameworks/CoreAudio.framework/Headers/CoreAudioTypes.h:28: :info:build In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:146: :info:build In file included from /Developer/Headers/FlatCarbon/MacTypes.h:1: :info:build In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:18: :info:build In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20: :info:build In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:18: :info:build In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:39: :info:build /System/Library/Frameworks/CoreFoundation.framework/Headers/CFArray.h:49:1: error: unknown type name 'CF_IMPLICIT_BRIDGING_ENABLED' :info:build CF_IMPLICIT_BRIDGING_ENABLED :info:build ^ :info:build /System/Library/Frameworks/CoreFoundation.framework/Headers/CFArray.h:50:18: error: expected ';' after top level declarator
comment:9 follow-up: 10 Changed 12 years ago by benedikt@…
How do I force it? I'd like to test that.
comment:10 Changed 12 years ago by ks+macports@…
Replying to benedikt@…:
How do I force it? I'd like to test that.
Maybe:
CFLAGS='-DCF_IMPLICIT_BRIDGING_ENABLED' port install libsndfile
I haven't tried it.
comment:14 Changed 12 years ago by seancd91@…
I had the same issue, too. However, I noticed that the log files referenced "/Developer/Headers/FlatCarbon/MacTypes.h" (line 472 on main1.log), which is from Xcode 4.2. I later placed my /Developer directory in the trash, cleaned and reinstalled libsndfile, and it compiled successfully. Maybe it was an issue with the configuration file or autotools.
Hope this helps.
comment:16 Changed 12 years ago by mf2k (Frank Schima)
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:17 Changed 12 years ago by g@…
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Why can I delete the /Developer directory? Is it useless at all? If this is not the case: why do we close this one?
comment:18 Changed 12 years ago by benedikt@…
It's useless for Xcode > 4.4, because Xcode then keeps everything inside the Xcode App. So as long as you don't use an SDK not supported by Xcode 4.4 you can delete the /Developer directory. I didn't do that, because I didn't trust the switch to the new directory and I didn't think of any problems this might cause. So by deleting the /Developer folder the issue was fixed and the bugreport can be closed since I'm using Xcode 4.4 and Mountain Lion.
comment:19 Changed 12 years ago by mf2k (Frank Schima)
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
comment:20 Changed 12 years ago by adam@…
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
"worksforme?" That's a crap answer for a problem that's biting a lot of users.
Look at how many duplicates of this bug are in the database. It's a real problem that's causing real headaches for people, and the fact that it can be hacked around by those in the know does nothing to mitigate its severity. Doing a "port upgrade outdated" should just work for users, even if they've just installed XCode 4.4, even if they had an earlier version of XCode installed before that.
Sure, removing the /Developer directory lets the whole process complete -- assuming users don't have any real reason to keep XCode 4.2 around. But it's an ugly workaround, and it's really hard to find. Do we honestly expect everyone to end up finding and reading through this particular bug report? No. And for those users, ports will just be broken.
This is a make system issue that should be trivial to fix for anyone familiar with how the whole ports build setup works. Unfortunately, I'm not in that camp or I'd send in a patch.
comment:26 Changed 12 years ago by jmroot (Joshua Root)
Summary: | libsndfile build error OS X 10.8 and Xcode 4.4 → libsndfile build error on OS X 10.8 with old /Developer dir present |
---|
comment:27 Changed 12 years ago by jmroot (Joshua Root)
Try after r98107. If that works, please report it upstream (as the port has no maintainer).
comment:28 Changed 12 years ago by jmroot (Joshua Root)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Assuming fixed since nobody has said otherwise.
build log