gobject-introspection @1.34.1.1_0 +universal Build failure - missing symbol in Python shared object

[cooljeanius (Eric Gallager)]

I was considering re-opening #36725 for this, but it turns out that this is a different error message, so I'm opening a separate ticket. Here's the relevant part of my main.log:

:info:build env PATH=.libs:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./g-ir-compiler --includedir=. --includedir=./gir --includedir=. --includedir=. --includedir=. gir/fontconfig-2.0.gir -o gir/fontconfig-2.0.typelib
:info:build env PATH=.libs:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./g-ir-compiler --includedir=. --includedir=./gir --includedir=. --includedir=. --includedir=. gir/freetype2-2.0.gir -o gir/freetype2-2.0.typelib
:info:build env PATH=.libs:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./g-ir-compiler --includedir=. --includedir=./gir --includedir=. --includedir=. --includedir=. gir/GL-1.0.gir -o gir/GL-1.0.typelib
:info:build env PATH=.libs:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./g-ir-compiler --includedir=. --includedir=./gir --includedir=. --includedir=. --includedir=. gir/libxml2-2.0.gir -o gir/libxml2-2.0.typelib
:info:build env PATH=.libs:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./g-ir-compiler --includedir=. --includedir=./gir --includedir=. --includedir=. --includedir=. gir/xft-2.0.gir -o gir/xft-2.0.typelib
:info:build env PATH=.libs:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./g-ir-compiler --includedir=. --includedir=./gir --includedir=. --includedir=. --includedir=. gir/xlib-2.0.gir -o gir/xlib-2.0.typelib
:info:build env PATH=.libs:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./g-ir-compiler --includedir=. --includedir=./gir --includedir=. --includedir=. --includedir=. gir/xfixes-4.0.gir -o gir/xfixes-4.0.typelib
:info:build env PATH=.libs:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./g-ir-compiler --includedir=. --includedir=./gir --includedir=. --includedir=. --includedir=. gir/xrandr-1.3.gir -o gir/xrandr-1.3.typelib
:info:build env PATH=.libs:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin ./g-ir-compiler --includedir=. --includedir=./gir --includedir=. --includedir=. --includedir=. gir/cairo-1.0.gir -o gir/cairo-1.0.typelib
:info:build Traceback (most recent call last):
:info:build   File "./g-ir-scanner", line 44, in <module>
:info:build     from giscanner.scannermain import scanner_main
:info:build   File "./giscanner/scannermain.py", line 34, in <module>
:info:build     from giscanner.dumper import compile_introspection_binary
:info:build   File "./giscanner/dumper.py", line 28, in <module>
:info:build     from .gdumpparser import IntrospectionBinary
:info:build   File "./giscanner/gdumpparser.py", line 31, in <module>
:info:build     from .transformer import TransformerException
:info:build   File "./giscanner/transformer.py", line 27, in <module>
:info:build     from .girparser import GIRParser
:info:build   File "./giscanner/girparser.py", line 26, in <module>
:info:build     from .girwriter import COMPATIBLE_GIR_VERSION
:info:build   File "./giscanner/girwriter.py", line 25, in <module>
:info:build     from .xmlwriter import XMLWriter
:info:build   File "./giscanner/xmlwriter.py", line 74, in <module>
:info:build     from _giscanner import collect_attributes
:info:build   File "./giscanner/libtoolimporter.py", line 66, in load_module
:info:build     mod = imp.load_module(name, open(realpath), realpath, (extension, 'rb', 3))
:info:build ImportError: dlopen(./.libs/_giscanner.so, 2): Symbol not found: _getmntent
:info:build   Referenced from: /opt/local/lib/libgio-2.0.0.dylib
:info:build   Expected in: flat namespace
:info:build  in /opt/local/lib/libgio-2.0.0.dylib
:info:build make[2]: *** [GLib-2.0.gir] Error 1
:info:build make[2]: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1" && /usr/bin/make -j2 -w all CC="/usr/bin/gcc-4.2 -arch x86_64" V=1 
:info:build Exit code: 2
:error:build org.macports.build for port gobject-introspection returned: command execution failed
:debug:build Error code: CHILDSTATUS 18536 2
:debug:build Backtrace: command execution failed
    while executing
"system -nice 0 $fullcmdstring"
    ("eval" body line 1)
    invoked from within
"eval system $notty $nice \$fullcmdstring"
    invoked from within
"command_exec build"
    (procedure "portbuild::build_main" line 8)
    invoked from within
"$procedure $targetname"
:info:build Warning: targets not executed for gobject-introspection: org.macports.install org.macports.build org.macports.destroot

Other potentially useful info:

Local-Admins-MacBook-Pro:~ ericgallager$ port -v installed glib2
The following ports are currently installed:
  glib2 @2.34.2_0+universal (active) platform='darwin 10' archs='i386 x86_64'
Local-Admins-MacBook-Pro:~ ericgallager$ port -v installed glib2-devel
The following ports are currently installed:
  glib2-devel @2.35.1_0+universal (active) platform='darwin 10' archs='i386 x86_64'

Local-Admins-MacBook-Pro:~ ericgallager$ which xcodebuild
/Developer/usr/bin/xcodebuild
Local-Admins-MacBook-Pro:~ ericgallager$ `which xcodebuild` -version
Xcode 3.2.6
Component versions: DevToolsCore-1809.0; DevToolsSupport-1806.0
BuildVersion: 10M2518

Local-Admins-MacBook-Pro:~ ericgallager$ which clang
/Developer/usr/bin/clang
Local-Admins-MacBook-Pro:~ ericgallager$ `which clang` --version
Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)
Target: x86_64-apple-darwin10
Thread model: posix

Local-Admins-MacBook-Pro:~ ericgallager$ which gcc
/Developer/usr/bin/gcc
Local-Admins-MacBook-Pro:~ ericgallager$ `which gcc` --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Local-Admins-MacBook-Pro:~ ericgallager$ which python
/Library/Frameworks/Python.framework/Versions/Current/bin/python
Local-Admins-MacBook-Pro:~ ericgallager$ `which python` --version
Python 2.7.2

Local-Admins-MacBook-Pro:~ ericgallager$ which ccache
/opt/local/bin/ccache
Local-Admins-MacBook-Pro:~ ericgallager$ `which ccache` --version
ccache version 3.1.8

Copyright (C) 2002-2007 Andrew Tridgell
Copyright (C) 2009-2011 Joel Rosdahl

This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 3 of the License, or (at your option) any later
version.

[cooljeanius (Eric Gallager)]

The main.log file for the failed port

[ryandesign (Ryan Carsten Schmidt)]

Replying to egall@…:

Local-Admins-MacBook-Pro:~ ericgallager$ port -v installed glib2
The following ports are currently installed:
  glib2 @2.34.2_0+universal (active) platform='darwin 10' archs='i386 x86_64'
Local-Admins-MacBook-Pro:~ ericgallager$ port -v installed glib2-devel
The following ports are currently installed:
  glib2-devel @2.35.1_0+universal (active) platform='darwin 10' archs='i386 x86_64'

Is this accurate? It should not be possible for you to have both glib2 and glib2-devel active at the same time, because they conflict with one another; you would have had to force the activation to make this happen. Please deactivate both glib2 and glib2-devel forcibly, then activate the one that you want, which, unless you have a specific need to test features of the latest development version of glib, I suggest should be glib2:

sudo port -f deactivate glib2 glib2-devel
sudo port activate glib2

Local-Admins-MacBook-Pro:~ ericgallager$ which python
/Library/Frameworks/Python.framework/Versions/Current/bin/python

Where did /Library/Frameworks/Python.framework come from? That's not a location where MacPorts would normally install files, nor would Apple have put any files there. Having any frameworks installed in /Library/Frameworks can be problematic for some MacPorts ports so we recommend you remove them.

[cooljeanius (Eric Gallager)]

Is this accurate? It should not be possible for you to have both glib2 and glib2-devel active at the same time, because they conflict with one another; you would have had to force the activation to make this happen.

I often use the -f flag so that's probably what happened. Anyway I deactivated glib2-devel per your instructions and this error still happens.

Where did /Library/Frameworks/Python.framework come from? That's not a location where MacPorts would normally install files, nor would Apple have put any files there. Having any frameworks installed in /Library/Frameworks can be problematic for some MacPorts ports so we recommend you remove them.

I had installed python 2.7 with the installer from the ​Python website before I installed MacPorts. Coincidentally that's also where all my easy_install eggs and stuff end up. I'd rather keep it there so when easy_install-ing stuff, it doesn't get in my MacPorts prefix.

[ryandesign (Ryan Carsten Schmidt)]

Replying to egall@…:

Is this accurate? It should not be possible for you to have both glib2 and glib2-devel active at the same time, because they conflict with one another; you would have had to force the activation to make this happen.

I often use the -f flag so that's probably what happened. Anyway I deactivated glib2-devel per your instructions and this error still happens.

You'll need to deactivate glib2-devel and glib2, then reactivate glib2. Otherwise we don't know whether the active files were put there by glib2 or glib2-devel.

Please don't get in the habit of using the -f flag. Use it only in very limited circumstances where you understand all the side effects. If you're unsure of the side effects, feel free to ask on the mailing list.

Where did /Library/Frameworks/Python.framework come from? That's not a location where MacPorts would normally install files, nor would Apple have put any files there. Having any frameworks installed in /Library/Frameworks can be problematic for some MacPorts ports so we recommend you remove them.

I had installed python 2.7 with the installer from the ​Python website before I installed MacPorts. Coincidentally that's also where all my easy_install eggs and stuff end up. I'd rather keep it there so when easy_install-ing stuff, it doesn't get in my MacPorts prefix.

It will probably interfere with MacPorts, so we would really appreciate it if you removed it, or else don't be surprised when MacPorts things start breaking or installing files in the wrong location.

I don't write python code myself and I'm not familiar with easy_install, but you should be able to use MacPorts python and install any python modules you need using the corresponding ports. If a port doesn't exist for a module you need, it could be an opportunity for you to write a port for it, or else file a port request ticket and perhaps someone else can help do so.

[cooljeanius (Eric Gallager)]

You'll need to deactivate glib2-devel and glib2, then reactivate glib2. Otherwise we don't know whether the active files were put there by glib2 or glib2-devel.

That's what I meant I did when I said that I deactivated glib2-devel per your instructions.

It will probably interfere with MacPorts, so we would really appreciate it if you removed it, or else don't be surprised when MacPorts things start breaking or installing files in the wrong location.

OK, I moved it aside (which python now gives /usr/bin/python), but this error is still occurring.

[jmroot (Joshua Root)]

Replying to ryandesign@…:

I don't write python code myself and I'm not familiar with easy_install, but you should be able to use MacPorts python and install any python modules you need using the corresponding ports. If a port doesn't exist for a module you need, it could be an opportunity for you to write a port for it, or else file a port request ticket and perhaps someone else can help do so.

Providing ports for every python module is not a good use of our time. We only need to offer those that are depended on by a port or depend on something from a port. For everything else, pip or easy_install in a virtualenv are fine.

[cooljeanius (Eric Gallager)]

Just an update: I just updated to the latest glib, so port installed glib2 now gives:

$ port -v installed glib2
The following ports are currently installed:
  glib2 @2.34.3_0+universal (active) platform='darwin 10' archs='i386 x86_64'

And gobject-introspection is still broken after this.

[neverpanic (Clemens Lang)]

I'm attaching a patch. Can you put it in $(port dir gobject-introspection)/files, add its file name to the patchfiles directive in the Portfile, clean gobject-introspection, re-try and attach the new main.log? I'm hoping some debug info will confirm my guess on my this happens.

[neverpanic (Clemens Lang)]

patch against the failing location to print some debug info

[cooljeanius (Eric Gallager)]

New main.log (doesn't look any different to me...)

[cooljeanius (Eric Gallager)]

Still broken even after the recent revbump in r100619...

[neverpanic (Clemens Lang)]

The wording of the commit message was unfortunate, since the revbump wasn't meant to fix this problem.

I recently read a similar log message that was apparently caused by a missing architecture in some file. Can you provide the output of file /opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1/.libs/_giscanner.so and file /opt/local/lib/libgio-2.0.0.dylib? The output should contain the architecture of the files (if it doesn't, try lipo -info instead).

[cooljeanius (Eric Gallager)]

What the heck, here's both:

sh-3.2# file /opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1/.libs/_giscanner.so
/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1/.libs/_giscanner.so: Mach-O universal binary with 2 architectures
/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1/.libs/_giscanner.so (for architecture x86_64):	Mach-O 64-bit bundle x86_64
/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1/.libs/_giscanner.so (for architecture i386):	Mach-O bundle i386
sh-3.2# file /opt/local/lib/libgio-2.0.0.dylib
/opt/local/lib/libgio-2.0.0.dylib: Mach-O universal binary with 2 architectures
/opt/local/lib/libgio-2.0.0.dylib (for architecture x86_64):	Mach-O 64-bit dynamically linked shared library x86_64
/opt/local/lib/libgio-2.0.0.dylib (for architecture i386):	Mach-O dynamically linked shared library i386
sh-3.2# lipo -info /opt/local/lib/libgio-2.0.0.dylib
Architectures in the fat file: /opt/local/lib/libgio-2.0.0.dylib are: x86_64 i386 
sh-3.2# lipo -info /opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1/.libs/_giscanner.so
Architectures in the fat file: /opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1/.libs/_giscanner.so are: x86_64 i386 

And just to triple-check, here's some otool -f output as well:

sh-3.2# otool -f /opt/local/lib/libgio-2.0.0.dylib
Fat headers
fat_magic 0xcafebabe
nfat_arch 2
architecture 0
    cputype 16777223
    cpusubtype 3
    capabilities 0x0
    offset 4096
    size 1594272
    align 2^12 (4096)
architecture 1
    cputype 7
    cpusubtype 3
    capabilities 0x0
    offset 1601536
    size 1377812
    align 2^12 (4096)
sh-3.2# otool -f /opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_gnome_gobject-introspection/gobject-introspection/work/gobject-introspection-1.34.1.1/.libs/_giscanner.so
Fat headers
fat_magic 0xcafebabe
nfat_arch 2
architecture 0
    cputype 16777223
    cpusubtype 3
    capabilities 0x0
    offset 4096
    size 90696
    align 2^12 (4096)
architecture 1
    cputype 7
    cpusubtype 3
    capabilities 0x0
    offset 98304
    size 81492
    align 2^12 (4096)

[cooljeanius (Eric Gallager)]

Actually I get this same issue when trying to install gobject-introspection with Homebrew on a different hard drive so I'm thinking this might be an upstream issue...

[cooljeanius (Eric Gallager)]

gobject-introspection's config.log

[cooljeanius (Eric Gallager)]

I realized I never added my config.log to go with my main.log. Even though it wasn't the configure step that it failed during, I figured it still might have some useful information in it.

[cooljeanius (Eric Gallager)]

the config.log from my most recent attempt to rebuild and reinstall glib2

[cooljeanius (Eric Gallager)]

Upstream said that I should try rebuilding and reinstalling my copy of glib2, so I did so and still got the same error. I figured I should attach my config.log from this most recent attempt here, too.

[cooljeanius (Eric Gallager)]

Upstream said that glib's configure script was picking up a header named mntent.h by mistake, so I this is pretty clearly actually a glib issue now. Could someone add "glib2" to the "port" field for this ticket?

[ryandesign (Ryan Carsten Schmidt)]

I don't have a "mntent.h" on my system. Where is it on your system and how did it get there?

[cooljeanius (Eric Gallager)]

I don't have a "mntent.h" on my system. Where is it on your system and how did it get there?

Somehow some Cygwin headers got into my /usr/include, and unfortunately I don't seem to be able to remove them: ​http://www.reddit.com/r/applehelp/comments/169awx/why_might_sudo_rm_f_fail/

Still, regardless of all that though, if "mntent.h" is a header that shouldn't exist on OS X, glib2's configure script shouldn't pick it up on this platform, right? Actually just a sec, let me whip up a patch...

[cooljeanius (Eric Gallager)]

patch to apply to glib2's configure.in file (which really should be renamed to "configure.ac")

[cooljeanius (Eric Gallager)]

Would something like that patch I just added work? If so, could you add the keyword "haspatch" please? I'd test it myself but unfortunately I don't have access to my development computer this semester...

[ryandesign (Ryan Carsten Schmidt)]

I would prefer you work with the developers of glib to determine whether that's an appropriate change, and if so, to have it applied directly to the upstream sources, from which it will make its way into MacPorts as we updated to newer versions. It's of course completely unsupported for you to have headers of Cygwin (a Linux-like environment for Windows) anywhere near an OS X box.

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

It's of course completely unsupported for you to have headers of Cygwin (a Linux-like environment for Windows) anywhere near an OS X box.

Yeah, I know that (I'm still confused about how they got from my school's Windows boxes to my home machine myself... I think it might have had something to do with GNUStep and Migration Assistant, but I'm not sure...). Anyway the school computers I'm working on now don't experience this issue like my home computer did, so feel free to close this issue as "wontfix" or "invalid" for now... if, once I get back to my home machine, I'm still experiencing this issue, and upstream won't apply this patch, I'll reopen this issue then.

[cooljeanius (Eric Gallager)]

Back on my broken Snow Leopard machine at home, and I'm seeing this issue with libgphoto2, too:

:info:build Making all in .
:info:build make[4]: Entering directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libgphoto2/libgphoto2/work/libgphoto2-2.5.1.1/libgphoto2_port'
:info:build /bin/sh ./libtool  --tag=CC   --mode=link ccache /usr/bin/gcc-4.2 -pipe -O2 -arch x86_64 -arch i386 -pipe -O2 -arch x86_64 -arch i386 -module -no-undefined -avoid-version -export-dynamic -export-symbols ./iolib.sym -rpath '/opt/local/lib/libgphoto2_port/0.10.0' -arch x86_64 -arch i386 -o disk.la  disk_la-disk.lo ./libgphoto2_port/libgphoto2_port.la -L/opt/local/lib -lintl -liconv -lc  -lintl -lpthread 
:info:build libtool: link: sed -e 's,^,_,' < ./iolib.sym > .libs/disk-symbols.expsym
:info:build libtool: link: ccache /usr/bin/gcc-4.2  -o .libs/disk.so -bundle  .libs/disk_la-disk.o   ./libgphoto2_port/.libs/libgphoto2_port.dylib -L/opt/local/lib /opt/local/lib/libltdl.dylib /opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib -lc -lpthread  -O2 -arch x86_64 -arch i386 -O2 -arch x86_64 -arch i386 -arch x86_64 -arch i386   -Wl,-exported_symbols_list,.libs/disk-symbols.expsym
:info:build Undefined symbols for architecture x86_64:
:info:build   "_getmntent", referenced from:
:info:build       _gp_port_library_list in disk_la-disk.o
:info:build       _gp_port_library_list in disk_la-disk.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build collect2: ld returned 1 exit status
:info:build Undefined symbols for architecture i386:
:info:build   "_getmntent", referenced from:
:info:build       _gp_port_library_list in disk_la-disk.o
:info:build       _gp_port_library_list in disk_la-disk.o
:info:build ld: symbol(s) not found for architecture i386
:info:build collect2: ld returned 1 exit status
:info:build lipo: can't open input file: /var/tmp//cctjDlYi.out (No such file or directory)
:info:build make[4]: *** [disk.la] Error 1
:info:build make[4]: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libgphoto2/libgphoto2/work/libgphoto2-2.5.1.1/libgphoto2_port'
:info:build make[3]: *** [all-recursive] Error 1
:info:build make[3]: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libgphoto2/libgphoto2/work/libgphoto2-2.5.1.1/libgphoto2_port'
:info:build make[2]: *** [all] Error 2
:info:build make[2]: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libgphoto2/libgphoto2/work/libgphoto2-2.5.1.1/libgphoto2_port'
:info:build make[1]: *** [all-recursive] Error 1
:info:build make[1]: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libgphoto2/libgphoto2/work/libgphoto2-2.5.1.1'
:info:build make: *** [all] Error 2
:info:build make: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libgphoto2/libgphoto2/work/libgphoto2-2.5.1.1'
:info:build Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_libgphoto2/libgphoto2/work/libgphoto2-2.5.1.1" && /usr/bin/make -j2 -w all 

I wish that mntent.h header would just let me delete it... although I read somewhere that files not completely finished being copied during afp file transfers via Finder can end up being undeletable, and I think that's what I might have been doing when it got on my computer, so maybe that's why I can't delete it...

[ryandesign (Ryan Carsten Schmidt)]

Replying to egall@…:

I wish that mntent.h header would just let me delete it...

How can you not delete a file?

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

Replying to egall@…:

I wish that mntent.h header would just let me delete it...

How can you not delete a file?

See the edit, and also the link I included in comment:16

[ryandesign (Ryan Carsten Schmidt)]

I've never encountered any undeletable files before. I might try booting to single user mode (hold down Command-S as you reboot), then mount the disk read/write as the instructions will tell you how to do, then try deleting the file. You can type shutdown -r now to reboot or shutdown -h now to shut down. If that doesn't work, boot into target disk mode (hold down Command-T as you reboot) and attach this Mac to another Mac via a FireWire or Thunderbolt cable (or: boot this Mac from an external hard drive); then try deleting the file from the internal drive (which will now show up as a secondary drive). If it still doesn't let you, Get Info on the internal drive and enable the "Ignore ownership on this volume" checkbox (you may need to click the padlock and provide an administrator password to do that), then try again to delete it; disable "Ignore ownership" again afterward.

[larryv (Lawrence Velázquez)]

Replying to egall@…:

Replying to ryandesign@…:

It's of course completely unsupported for you to have headers of Cygwin (a Linux-like environment for Windows) anywhere near an OS X box.

Yeah, I know that (I'm still confused about how they got from my school's Windows boxes to my home machine myself... I think it might have had something to do with GNUStep and Migration Assistant, but I'm not sure...). Anyway the school computers I'm working on now don't experience this issue like my home computer did, so feel free to close this issue as "wontfix" or "invalid" for now... if, once I get back to my home machine, I'm still experiencing this issue, and upstream won't apply this patch, I'll reopen this issue then.

Closing then.