Header only libraries do not build on Mac OS X

[bazelbuild]

Header only libraries do not build on Mac OS X

[damienmg]

Do you have a empty.c in tools/cpp ?

[trevorgray]

Yes. This was run from head with only running compile.sh and modifying examples/cpp/BUILD.

$ ls tools/cpp
BUILD       CROSSTOOL   empty.cc

[ulfjack]

The rules aren't quite compatible with the Mac tools - that's why we added
the empty.cc in a few places. I have an idea of how to change the rules to
make this go away, but the downside is that it would be technically
incompatible with our internal rules. Alternatively, we could add wrappers
around the Mac tools to make them handle that corner case in a way that's
compatible with the rules.

On Wed, Mar 25, 2015 at 8:20 PM Trevor Gray [email protected]
wrote:

Yes. This was run from head with only modifying examples/cpp/BUILD.

$ ls tools/cpp
BUILD CROSSTOOL empty.cc

—
Reply to this email directly or view it on GitHub
#61 (comment).

[ulfjack]

To clarify - the Mac tools don't allow static libraries (and maybe this
also applies to dynamic libraries) which are empty - i.e. which don't
contain any object files, while the Linux tools typically allow this. The
rules, however, have implicit .a and .so outputs which the rules
'guarantee' to always be created, even for empty libraries (the rules can't
determine during the loading phase if there are going to be .cc source
files or not).

On Wed, Mar 25, 2015 at 8:30 PM Ulf Adams [email protected] wrote:

The rules aren't quite compatible with the Mac tools - that's why we added
the empty.cc in a few places. I have an idea of how to change the rules to
make this go away, but the downside is that it would be technically
incompatible with our internal rules. Alternatively, we could add wrappers
around the Mac tools to make them handle that corner case in a way that's
compatible with the rules.

On Wed, Mar 25, 2015 at 8:20 PM Trevor Gray [email protected]
wrote:

Yes. This was run from head with only modifying examples/cpp/BUILD.

$ ls tools/cpp
BUILD CROSSTOOL empty.cc

—
Reply to this email directly or view it on GitHub
#61 (comment).

[damienmg]

I just introduced a wrapper around gcc for another bug (the library path one we discussed on monday), let just do another wrapper around otool for that.

[damienmg]

sorry I means around libtool

[damienmg]

Ulf, I let you handle this one when you are back.

[applmak]

Is

# libtool_wrapper.sh
set -eu

LIBTOOL="/usr/bin/libtool"
GCC="/usr/bin/gcc"

TOOLS_DIR="$PWD/tools/cpp"

# Ensure that we have an 'empty' .o
if [ ! -e $TOOLS_DIR/empty.o ]; then
  ${GCC} -o $TOOLS_DIR/empty.o -c $TOOLS_DIR/empty.cc
fi

# Call normal libtool with the addition empty .o
${LIBTOOL} "$@" $TOOLS_DIR/empty.o

the worse thing ever to fix this or only the second-worst thing?

[Sinn]

Installed bazel on May 24, cloned from github.

Mac OS X Yosemite, this issue is still present, even though there is an empty.cc on the bazel-project/tools/cpp/ dir. Any idea why?

[kayasoze]

I've encountered the same issue while trying to build Boost on OS X with Xcode 6.4. In that case, adding an empty.cc (with linkstatic = 1 to silence warnings) does not help.

[ulfjack]

I'm back now, and this seems like it's critical to fix. I've made some progress on a fix, which is going to be to remove the static / dynamic libraries if there aren't any object files. There's a chance that this breaks users who rely on the implicit output files <name>.a or <name>.so being available, but I don't expect that to be widely used.

For those using the workaround, the empty.cc file needs to be actually referenced in cc_library.srcs (and you'll still get warnings from the linker).

[kayasoze]

I will often wrap a genrule() built library (built, say, with autoconf) with a cc_library(); among other benefits, this allows me to specify the correct include paths for the library's headers and have them handled transitive-magically. If implicit output files are removed, will this trick still work?

[ulfjack]

Yes, that's not a problem. I only know a single use case for the .a or .so implicit outputs, and there's a workaround for that. I also had a quick look through our internal code base, and there are few, if any, places that rely on the 'old' behavior.