Portfile for megatools

[s.cloherty@…]

Megatools (​http://megatools.megous.com/) is a collection of command line tools for accessing Mega cloud services at mega.co.nz. Megatools allows you to upload or download individual files as well as entire directory trees.

The attached Portfile builds and installs megatools-1.9.91. I have tested it with success on OS X 10.6.8 using Macports 2.1.3.

[s.cloherty@…]

Portfile for megatools.

[cooljeanius (Eric Gallager)]

Why is the depends_lib on glib-networking commented out?

[s.cloherty@…]

glib-networking doesn't seem to be required to build megatools, but is required at run time. My understanding is that this is what depends_run is for. I initially used depends_lib, but switched it to depends_run when testing (commenting out the depends_lib line). The commented depends_lib on glib-networking should have been removed before I attached the Portfile.

[cooljeanius (Eric Gallager)]

port lint --nitpick has some minor whitespace nitpicks:

Warning: Line 13 has trailing whitespace before newline
Warning: Line 23 has trailing whitespace before newline

Also the revision starts at 0 and can actually be entirely left out if it's 0.

Edit: I made a few changes to the portfile, such as adding a build dependency on pkgconfig, and adding --disable-silent-rules to configure.args, and I ran into this error:

libtool: link: ccache /usr/bin/gcc-4.2 -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I./libtools -I.. -D_FILE_OFFSET_BITS=64 -D_DARWIN_USE_64_BIT_INODE -I/opt/local/include/fuse -pipe -O2 -arch x86_64 -arch i386 -Wno-pointer-sign -Wno-unused-variable -arch x86_64 -arch i386 -o .libs/megafs megafs-fs.o -pthread  -L/opt/local/lib -L/opt/local/lib/db46 ./.libs/libtools.a ../mega/.libs/libmega.dylib /opt/local/lib/libgio-2.0.dylib /opt/local/lib/libgmodule-2.0.dylib /opt/local/lib/libgobject-2.0.dylib /opt/local/lib/libffi.dylib /opt/local/lib/libglib-2.0.dylib /opt/local/lib/libcurl.dylib /opt/local/lib/libcares.dylib /opt/local/lib/libidn.dylib /opt/local/lib/libintl.dylib -lc /opt/local/lib/libssh2.dylib /opt/local/lib/libldap.dylib /opt/local/lib/liblber.dylib -lfetch -lcom_err /opt/local/lib/libsasl2.dylib -ldl -lresolv -lpam -lz -lssl -lcrypto /opt/local/lib/libfuse.dylib /opt/local/lib/libiconv.dylib -framework CoreFoundation -pthread
ld: warning: in /opt/local/lib/libfuse.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols for architecture i386:
  "_fuse_main_real", referenced from:
      _main in megafs-fs.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//ccYSBoXL.out (No such file or directory)
gnumake[2]: *** [megafs] Error 1
gnumake[1]: *** [all-recursive] Error 1
gnumake: *** [all] Error 2
gnumake: Leaving directory `/opt/local/var/macports/build.build/_opt_local_var_macports_sources_LocalPorts_net_megatools/megatools/work/megatools-1.9.91'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_LocalPorts_net_megatools/megatools/work/megatools-1.9.91" && /usr/bin/gnumake -j2 -w all 
Exit code: 2
Error: org.macports.build for port megatools returned: command execution failed

It looks like it's trying to opportunistically link against /opt/local/lib/libfuse.dylib, which comes from fuse4x:

Local-Admins-MacBook-Pro:megatools ericgallager$ port provides /opt/local/lib/libfuse.dylib
/opt/local/lib/libfuse.dylib is provided by: fuse4x

megatools doesn't declare a dependency on fuse4x, so that means that they can end up with different architectures, which is what is causing the build failure here. MacPorts is in the process of replacing fuse4x with OSXFUSE; see #39456 and #37744 for more on this.

[s.cloherty@…]

Revised Portfile for megatools

[cooljeanius (Eric Gallager)]

I've updated my previous comment since you submitted your new portfile...

[larryv (Lawrence Velázquez)]

Replying to egall@…:

I've updated my previous comment since you submitted your new portfile...

Please refrain from editing comments to add substantial content; comment edits do not trigger notifications to macports-tickets. If you have more to say, just write a new comment.

[s.cloherty@…]

Ok, what is the way forward here? Since OSXFuse is not yet in macports, can we add a depends_lib on fuse4x in the interim?

[ryandesign (Ryan Carsten Schmidt)]

Yes, if megatools needs or benefits significantly from FUSE. Otherwise, you could add directives to prevent megatools from using FUSE.

[s.cloherty@…]

Revised Portfile for megatools... inc. depends_lib on fuse4x

[cooljeanius (Eric Gallager)]

Replying to larryv@…:

Replying to egall@…:

I've updated my previous comment since you submitted your new portfile...

Please refrain from editing comments to add substantial content;

Sorry, I didn't realize my edit was going to be substantial when I started writing it.

Anyway, I've installed it, and here are the MacPorts-provided libraries it links against:

Local-Admins-MacBook-Pro:megatools ericgallager$ port -q contents megatools | xargs file | grep Mach-O | cut -d\: -f1 | cut -d\  -f1 | uniq | xargs otool -L | grep "\ version\ " | grep "/opt/local" | sort | uniq | cut -d\  -f1 | xargs port -q provides 
/opt/local/lib/libcares.2.dylib is provided by: c-ares
/opt/local/lib/libcom_err.1.1.dylib is provided by: libcomerr
/opt/local/lib/libcrypto.1.0.0.dylib is provided by: openssl
/opt/local/lib/libcurl.4.dylib is provided by: curl
/opt/local/lib/libfetch.5.dylib is provided by: libfetch
/opt/local/lib/libffi.6.dylib is provided by: libffi
/opt/local/lib/libfuse.2.dylib is provided by: fuse4x
/opt/local/lib/libgio-2.0.0.dylib is provided by: glib2
/opt/local/lib/libglib-2.0.0.dylib is provided by: glib2
/opt/local/lib/libgmodule-2.0.0.dylib is provided by: glib2
/opt/local/lib/libgobject-2.0.0.dylib is provided by: glib2
/opt/local/lib/libiconv.2.dylib is provided by: libiconv
/opt/local/lib/libidn.11.dylib is provided by: libidn
/opt/local/lib/libintl.8.dylib is provided by: gettext
/opt/local/lib/liblber-2.4.2.dylib is provided by: openldap
/opt/local/lib/libldap-2.4.2.dylib is provided by: openldap
/opt/local/lib/libmega.0.dylib is provided by: megatools
/opt/local/lib/libsasl2.2.dylib is provided by: cyrus-sasl2
/opt/local/lib/libssh2.1.dylib is provided by: libssh2
/opt/local/lib/libssl.1.0.0.dylib is provided by: openssl
/opt/local/lib/libz.1.dylib is provided by: zlib

OP, you'll probably want to add these as library dependencies.

[cooljeanius (Eric Gallager)]

Cc Me!

[s.cloherty@…]

I see a reduced set of linked libraries on my system...

bash-3.2# port -q contents megatools | xargs file | grep Mach-O | cut -d\: -f1 | cut -d\  -f1 | uniq | xargs otool -L | grep "\ version\ " | grep "/opt/local" | sort | uniq | cut -d\  -f1 | xargs port -q provides
/opt/local/lib/libcrypto.1.0.0.dylib is provided by: openssl
/opt/local/lib/libcurl.4.dylib is provided by: curl
/opt/local/lib/libffi.6.dylib is provided by: libffi
/opt/local/lib/libfuse.2.dylib is provided by: fuse4x
/opt/local/lib/libgio-2.0.0.dylib is provided by: glib2
/opt/local/lib/libglib-2.0.0.dylib is provided by: glib2
/opt/local/lib/libgmodule-2.0.0.dylib is provided by: glib2
/opt/local/lib/libgobject-2.0.0.dylib is provided by: glib2
/opt/local/lib/libiconv.2.dylib is provided by: libiconv
/opt/local/lib/libidn.11.dylib is provided by: libidn
/opt/local/lib/libintl.8.dylib is provided by: gettext
/opt/local/lib/libmega.0.dylib is provided by: megatools
/opt/local/lib/libssl.1.0.0.dylib is provided by: openssl
/opt/local/lib/libz.1.dylib is provided by: zlib
bash-3.2# 

Looking at the source code, I see plenty of #includes for files provided by openssl, fuse4x and glib2, and a couple for files provided by curl. Suggesting that direct dependencies are at least: openssl, fuse4x, glib2 and curl.

I can add library dependencies for those.

I'm not sure what to do with the remainder: libffi, libiconv, libidn, gettext and zlib. Of those also listed on your list, c-ares, libcomerr, libfetch, cyrus-sasl2 and libssh2, I have only libcomerr (@1.42.7_2) installed, but it doesn't seem to be linked by megatools.

Any advice?

[cooljeanius (Eric Gallager)]

Replying to s.cloherty@…:

I'm not sure what to do with the remainder: libffi, libiconv, libidn, gettext and zlib.

Those ones are probably the ones pulled in by libtool overlinking:

Local-Admins-MacBook-Pro:hfsexplorer-0_21-src root# port contents glib2 | grep \\.la | tee /dev/tty | xargs cat | grep depend
  /opt/local/lib/libgio-2.0.la
  /opt/local/lib/libglib-2.0.la
  /opt/local/lib/libgmodule-2.0.la
  /opt/local/lib/libgobject-2.0.la
  /opt/local/lib/libgthread-2.0.la
# Linker flags that can not go in dependency_libs.
# Libraries that this one depends upon.
dependency_libs=' -R/opt/local/lib -L/opt/local/lib /opt/local/lib/libgobject-2.0.la /opt/local/lib/libffi.la /opt/local/lib/libgmodule-2.0.la /opt/local/lib/libglib-2.0.la -lresolv -lz /opt/local/lib/libintl.la /opt/local/lib/libiconv.la -lc'
# Linker flags that can not go in dependency_libs.
# Libraries that this one depends upon.
dependency_libs=' -R/opt/local/lib -L/opt/local/lib -lresolv /opt/local/lib/libintl.la /opt/local/lib/libiconv.la -lc'
# Linker flags that can not go in dependency_libs.
# Libraries that this one depends upon.
dependency_libs=' -R/opt/local/lib -L/opt/local/lib /opt/local/lib/libglib-2.0.la -lresolv /opt/local/lib/libintl.la /opt/local/lib/libiconv.la -lc'
# Linker flags that can not go in dependency_libs.
# Libraries that this one depends upon.
dependency_libs=' -R/opt/local/lib -L/opt/local/lib /opt/local/lib/libglib-2.0.la -lresolv /opt/local/lib/libffi.la /opt/local/lib/libintl.la /opt/local/lib/libiconv.la -lc'
# Linker flags that can not go in dependency_libs.
# Libraries that this one depends upon.
dependency_libs=' -R/opt/local/lib -L/opt/local/lib /opt/local/lib/libglib-2.0.la -lresolv /opt/local/lib/libintl.la /opt/local/lib/libiconv.la -lc'

They should already be pulled in via glib2's recursive dependencies:

Local-Admins-MacBook-Pro:hfsexplorer-0_21-src root# port rdeps glib2
The following ports are dependencies of glib2 @2.36.3_2+universal:
  xz
    libiconv
      gperf
    gettext
      expat
      ncurses
  zlib
  libffi
  perl5
    perl5.12
      gdbm

Thus, it might not be necessary to add them as direct dependencies (unless you want to; I normally like to do so anyways).

Of those also listed on your list, c-ares, libcomerr, libfetch, cyrus-sasl2 and libssh2, I have only libcomerr (@1.42.7_2) installed, but it doesn't seem to be linked by megatools.

That's probably because of the variants that I have curl installed with:

Local-Admins-MacBook-Pro:hfsexplorer-0_21-src root# port installed curl
The following ports are currently installed:
  curl @7.30.0_0+ares+openldap+sftp_scp+ssl+universal (active)

[larryv (Lawrence Velázquez)]

Replying to egall@…:

Thus, it might not be necessary to add them as direct dependencies (unless you want to; I normally like to do so anyways).

Dependencies should only be declared if they are actually used. This is not a matter of personal taste. Use nm(1) to inspect the binaries to see if they actually use symbols from the libraries in question.

[cooljeanius (Eric Gallager)]

Replying to larryv@…:

Replying to egall@…:

Thus, it might not be necessary to add them as direct dependencies (unless you want to; I normally like to do so anyways).

Dependencies should only be declared if they are actually used. This is not a matter of personal taste. Use nm(1) to inspect the binaries to see if they actually use symbols from the libraries in question.

I thought if otool -L said that a library is linked against, that that means that it uses symbols from that library though? Is that not actually the case? Previously I've only ever seen people on here use otool -L to decide if a library needs to be declared as a dependency, I hadn't ever heard of this policy of also needing to check with nm, too...

[larryv (Lawrence Velázquez)]

Replying to egall@…:

I thought if otool -L said that a library is linked against, that that means that it uses symbols from that library though? Is that not actually the case?

No, a binary can link against a library without actually using any of that library’s symbols. That’s what the whole ​Libtool fiasco was about.

Previously I've only ever seen people on here use otool -L to decide if a library needs to be declared as a dependency, I hadn't ever heard of this policy of also needing to check with nm, too...

It doesn’t matter which tools you use; the salient question is whether the library in question is required or not. If a dependency is determined to actually be unused, it should be removed. End of story.

Conversely, if a dependency is required, it should be declared directly by the port and not brought in indirectly through other dependencies.

Sane builds won’t link libraries that the software in question does not need, so otool(1) usually suffices. But not all builds are sane. If there’s any doubt, use nm(1); it requires a little more work but can provide a more accurate picture.

[cooljeanius (Eric Gallager)]

Replying to s.cloherty@…:

Ok, what is the way forward here? Since OSXFuse is not yet in macports, can we add a depends_lib on fuse4x in the interim?

OSXFuse is actually in macports now, btw, and it has replaced fuse4x. I already mentioned ticket #39456 previously in this thread, but it is worth checking again now that the transition to OSXFuse is further along

[mf2k (Frank Schima)]

Added in r120531 with the following changes:

• Depends on osxfuse
• Removed the revision line
• Use only modern checksums