libfaketime

[wolf@…]

Portfile for libfaketime - ​https://github.com/wolfcw/libfaketime

libfaketime intercepts various system calls that applications use to retrieve the current date and time. It can then report user-specified faked dates and times to these applications. This allows us to modify the system time an application sees without having to change the time system-wide.

[cooljeanius (Eric Gallager)]

If it's hosted on GitHub, try using the GitHub PortGroup​, which automatically sets a bunch of stuff for you. Also since you're skipping configuring, be sure that you're UsingTheRightCompiler and stuff.

[cooljeanius (Eric Gallager)]

Cc Me!

[wolf@…]

Thanks for your advice! I've updated the Portfile with PortGroup, github.setup, and configure.compiler statements.

[larryv (Lawrence Velázquez)]

Replying to wolf@…:

Thanks for your advice! I've updated the Portfile with PortGroup, github.setup

If you use the github-1.0 PortGroup, you shouldn’t set fetch.type or git.* anymore. The PortGroup downloads a tarball. See the fakeroot Portfile​ for a usage example. You’ll have to add checksums, and the exact way you use versions/committishes depends on your specific repository. Feel free to ask for help on macports-dev if you need it.

and configure.compiler statements

That’s not quite the point of UsingTheRightCompiler. The idea is not to force a certain compiler (unless you have to); it’s to make sure that the build respects whichever compiler MacPorts tries to use. Since this port does not use a configure phase, you will have to pass the compiler and any build flags to your makefile manually, either using the environment (build.env) or arguments (build.args). Again, ask on macports-dev for help.

[wolf@…]

If you use the github-1.0 PortGroup, you shouldn’t set fetch.type or git.* anymore. The PortGroup downloads a tarball. See the fakeroot Portfile​ for a usage example. You’ll have to add checksums, and the exact way you use versions/committishes depends on your specific repository. Feel free to ask for help on macports-dev if you need it.

My bad, sorry. I fixed the github.setup line, added checksums, and removed the other fetch.*/git.* lines.

and configure.compiler statements

That’s not quite the point of UsingTheRightCompiler. The idea is not to force a certain compiler (unless you have to); it’s to make sure that the build respects whichever compiler MacPorts tries to use. Since this port does not use a configure phase, you will have to pass the compiler and any build flags to your makefile manually, either using the environment (build.env) or arguments (build.args). Again, ask on macports-dev for help.

The distfile includes an OSX-specific Makefile, which needs to be used instead of the default Makefile, and currently the whole thing only works with clang (not gcc or others; that's a limitation of the software, not related to building it via macports). I changed configure.compiler to macports-clang (therefore supporting port select).

However, setting build.cmd to "make -f Makefile.OSX" was my only successful way of getting it to work, modifying other build.* settings did not pass "-f Makefile.OSX" to the make command.

[cooljeanius (Eric Gallager)]

Replying to wolf@…:

The distfile includes an OSX-specific Makefile, which needs to be used instead of the default Makefile, and currently the whole thing only works with clang (not gcc or others; that's a limitation of the software, not related to building it via macports). I changed configure.compiler to macports-clang (therefore supporting port select).

That still misses the point. That isn't just supporting port select, it requires that port select be used. If a version of clang has to be used, consider using compiler.blacklist on all of the different GCCs instead.

[wolf@…]

OK, "configure.compiler" removed; added "compiler.blacklist *cc* *dragonegg*" instead -- this should leave no other option than one of the clangs available.

[ryandesign (Ryan Carsten Schmidt)]

But the build.env or build.args or something still need to transfer the configure.cc and configure.cxx variables to the build system somehow.

[wolf@…]

sysutils/libfaketime/Portfile

[wolf@…]

Replying to ryandesign@…:

But the build.env or build.args or something still need to transfer the configure.cc and configure.cxx variables to the build system somehow.

Good point, thanks!

Based on some other Portfiles I looked at and how the software's Makefile.OSX handles things, I added the following lines to the Portfile:

build.args          CC="${configure.cc} ${archflags}" PREFIX=${prefix}
build.env           ${configure.env}

In there, archflags is assembled like you did in the detex Portfile.

[ryandesign (Ryan Carsten Schmidt)]

Thanks. Looking good. I noticed a few more things:

• For any given version, revision should start at 0, which can be accomplished by removing the revision line.
• The homepage line is unnecessary; the github portgroup adds it for you.
• The license line should be more specific if possible: what version(s) of the GPL is this under?
• To have any effect, the compiler.blacklist line must occur before configure.cc variable is accessed.
• The archflags don't need to be assembled manually; the get_canonical_archflags procedure does it for you.

[ryandesign (Ryan Carsten Schmidt)]

And the line "build.env ${configure.env}" doesn't do anything because you haven't put anything in configure.env.

Now that I've tried to install it, I see it installs a library called libfaketime.dylib.1:

$ port contents libfaketime
Port libfaketime contains:
  /opt/local/bin/faketime
  /opt/local/lib/faketime/libfaketime.dylib.1
  /opt/local/share/doc/faketime/NEWS
  /opt/local/share/doc/faketime/README
  /opt/local/share/man/man1/faketime.1.gz

That's not how libraries are named on OS X; it should be libfaketime.1.dylib. And the library's install_name is wrong:

$ otool -L /opt/local/lib/faketime/libfaketime.dylib.1
/opt/local/lib/faketime/libfaketime.dylib.1:
	libfaketime.dylib.1 (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

It needs to be the full installed path to the library, e.g. /opt/local/lib/libfaketime.1.dylib.

I also wish the upstream repository contained a tag for version 0.9.5rc2 that we could use instead of needing to specify a commit hash.

[ryandesign (Ryan Carsten Schmidt)]

And the library's version numbers haven't been set.

[ryandesign (Ryan Carsten Schmidt)]

The license appears to be GPL version 2, but I cannot tell if it's GPL 2 only (license field should be "GPL-2") or GPL 2 or later (license field should be "GPL-2+").

src/Makefile.OSX hardcodes -arch i386 -arch x86_64 which means the port will build universal for i386 and x86_64 even when not requested, and of course will not work on e.g. PowerPC systems; this must be fixed.

Why does OS X need a separate Makefile from everyone else? That seems like a great way for the OS X build system to get out of sync with other platforms.

[ryandesign (Ryan Carsten Schmidt)]

I've committed the port with changes in r112062 to fix the above. It would be great to get some of the patches committed upstream so we don't have to maintain them indefinitely.

[ryandesign (Ryan Carsten Schmidt)]

Build fails on Snow Leopard buildbot:

libfaketime.c:93:1: error: thread-local storage is unsupported for the current target

I thought perhaps Xcode 3.2.6's very old version of clang was not sufficient, so I blacklisted it in r112063, but that didn't help. Perhaps thread-local storage is an OS feature that Snow Leopard and earlier do not support. We have seen this error before in rethinkdb in #38493 and povray in #36172. Solutions welcome.

[wolf@…]

Ryan, thanks for the work you've put into this, I really appreciate your efforts!

Here's a few updates and clarifications:

• The license is GPL v2 only (_not_ v2 or later), so the current "license" line in the Portfile should be fine.

• Your patches (and related changes to some of the source files and the documentation) have been included upstream.

• This updated version of the upstream Github repository has been tagged v0.9.5rc3 . The final "v0.9.5" release is scheduled for later this month, but there should be enough flexibility to include more changes for a clean Portfile support if we need more time.

• The thread-local-storage compiler error can, as far as libfaketime development is concerned, most likely only be fixed by using pthreads instead of compiler-supported per-thread variables, which has some other ramifications. It's on the "we probably want to have it in the future" list, but it will, as of today, not be done for v0.9.5. libfaketime documentation recommends using v0.9.1 on SL and before.

• I agree the separate Makefile for OSX is not ideal, but for now we're stuck with it. The build/installation process on Linux varies quite a bit (different libs for single/multi-thread; multiarch/multilib support; Linux-specific features regarding timers enabled by default; and so on) and the currently ./configure-less approach would most likely lead to a cluttered complex Makefile. Going for autoconf will change packaging for all Linux distributions, so that's also something for beyond v0.9.5. Your comment is actually a good motivating input for libfaketime developers to spend some time on that. :-)

• Library version numbers are now set by passing more default LIB_LDFLAGS in src/Makefile.OSX.

[ryandesign (Ryan Carsten Schmidt)]

Ok great. Would you like to supply a portfile patch to update the port or should I work on it? The port currently indicates that you would like to be the sole maintainer. If you'd like to allow others to commit updates to the port, we can add "openmaintainer" to the maintainers line. If you have an update for the port, please file a new ticket and attach it.