curlftpfs on macbook pro 2,1

[faruk.tuefekli@…]

--->  Computing dependencies for curlftpfs
--->  Building curlftpfs
Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_fuse_curlftpfs/work/curlftpfs-0.9.1" && /usr/bin/make -j2 all " returned error 2
Command output: /usr/bin/make  all-recursive
Making all in compat
make[2]: Nothing to be done for `all'.
Making all in doc
make[2]: Nothing to be done for `all'.
if /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I. -I.  -DFUSE_USE_VERSION=25 -I/opt/local/include  -O2 -arch x86_64 -Wall -W -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include   -D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64 -I/opt/local/include/fuse   -I/opt/local/include -MT ftpfs-ls.o -MD -MP -MF ".deps/ftpfs-ls.Tpo" -c -o ftpfs-ls.o ftpfs-ls.c; \
	then mv -f ".deps/ftpfs-ls.Tpo" ".deps/ftpfs-ls.Po"; else rm -f ".deps/ftpfs-ls.Tpo"; exit 1; fi
if /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I. -I.  -DFUSE_USE_VERSION=25 -I/opt/local/include  -O2 -arch x86_64 -Wall -W -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include   -D__FreeBSD__=10 -D_FILE_OFFSET_BITS=64 -I/opt/local/include/fuse   -I/opt/local/include -MT charset_utils.o -MD -MP -MF ".deps/charset_utils.Tpo" -c -o charset_utils.o charset_utils.c; \
	then mv -f ".deps/charset_utils.Tpo" ".deps/charset_utils.Po"; else rm -f ".deps/charset_utils.Tpo"; exit 1; fi
In file included from ftpfs.h:12,
                 from charset_utils.c:17:
/opt/local/include/curl/curl.h:52:23: error: osreldate.h: No such file or directory
In file included from ftpfs.h:12,
                 from ftpfs-ls.c:24:
/opt/local/include/curl/curl.h:52:23: error: osreldate.h: No such file or directory
make[2]: *** [charset_utils.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [ftpfs-ls.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Error: Status 1 encountered during processing.
Before reporting a bug, first run the command again with the -d flag to get complete output.

[jmroot (Joshua Root)]

Please remember to preview and use WikiFormatting, fill in the Port field, and cc the maintainer.

[darenzana@…]

quick hack to make it work

[darenzana@…]

Hi, the problem seem to be in the interaction between macfuse and curl:

The macfuse port installs /opt/local/lib/pkgconfig/fuse.pc , which has the effect to define __FreeBSD__ when you use libfuse. The curl port installs /opt/local/lib/curl/curl.h , needed by curlftpfs. In this file, there is an instruction to #include <osreldate.h> when __FreeBSD__ is defined. However, this file does not exist on Mac OS X.

I have attached a patch against /opt/local/lib/curl/curl.h, which disables this. I don't really know the consequences of not including <osreldate.h>, and I am not sure this is the universal solution for all fuse ports, but it makes curlftpfs compile and run.

[faruk.tuefekli@…]

thank you.. that worked for me too

greets

[ggles.fi@…]

The patch allowed me to install curlftpfs, but, I, too am concerned about disabling osreldate.h

[ryandesign (Ryan Carsten Schmidt)]

It doesn't seem right to me that MacFUSE would define __FreeBSD__ when we are not on FreeBSD; I would think this is a bug in MacFUSE that should be fixed in MacFUSE rather than worked around in other ports.

[ericmoret]

Cc Me!

[andrewberry@…]

Cc Me!

[julienb@…]

Cc Me!

[pinguin@…]

improved patch (using apple macro)

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #27541.

[drkp (Dan Ports)]

It looks like MacFUSE #defines __FreeBSD__ to 10 (for Mac OS "10") to indicate that it's running on a Mac. This is a really awful hack that lets it use #ifdef __FreeBSD__ to detect OS X or FreeBSD and #if (__FreeBSD__ >= 10) to detect OS X specifically. Unfortunately, it does that in the header files too so ports that use fuse have to #define it too, causing problems like this.

This really needs to be fixed in MacFUSE, but it'd be a pretty large change so I'm not sure if having the port try to patch it is a good idea. There might also be backwards-compatibility issues...

[ryandesign (Ryan Carsten Schmidt)]

The patch above by pinguin looks simple enough; I intend to test it shortly.

[drkp (Dan Ports)]

Replying to ryandesign@…:

The patch above by pinguin looks simple enough; I intend to test it shortly.

Yes, something like that seems best for now (assuming it works; I haven't tried it)

[ryandesign (Ryan Carsten Schmidt)]

Committed pinguin's patch in r74063.

[ryandesign (Ryan Carsten Schmidt)]

This was fixed upstream — see ​https://github.com/osxfuse/osxfuse/issues/17 — so we can remove the patch.