llvm-3.9 @3.9-r270400_0+assertions+debug build failure on snow leopard due to missing strnlen function - and fix

[kenneth.f.cunningham@…]

Sorry I haven't figured out the diff files just yet.

llvm-3.9 build fails at 12% and then at 98% with error strnlen function not found

to fix:

in this file

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/llvm-3.9/work/trunk/lib/ObjectYAML/MachOYAML.cpp

and in this file

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-3.9/llvm-3.9/work/trunk/tools/obj2yaml/macho2yaml.cpp

add this replacement function after <string.h> and build succeeds

(found an example in the cctools patches):

static size_t
strnlen(const char *s, size_t maxlen)
{
	size_t len;

	for (len = 0; len < maxlen; len++, s++) {
		if (!*s)
			break;
	}
	return (len);
}

[jeremyhu (Jeremy Huddleston Sequoia)]

Yep. I reported it upstream a couple weeks ago:

​https://llvm.org/bugs/show_bug.cgi?id=27714

I'm not sure how we want to handle this for a proper solution. The static one-off will get us building again, but there is a more general question about how to handle portability issues like this in general going forward in llvm's codebase.

[kenneth.f.cunningham@…]

I went through the process of installing LibcxxOnOlderSystems and then rebuilt clang-3.9, but this didn't fix the missing definition.

This issue seems to apply to other software as well, of course. <​http://stackoverflow.com/questions/32468480/strnlen-does-not-exist-in-gcc-4-2-1-on-mac-os-x-10-6-8-how-to-define-it>.

Given SL's market share, it may not be reasonable to expect all upstream authors to support systems without strnlen. What do you think of the idea of modifying /usr/include/string.h on snow leopard to static inline the rare missing functions in the header file? I realize it's not a purist approach -- probably first class of first day of computer science school tells you not to do that.

If that is not acceptable, there a way to override string.h, calling one in the /opt directory first that inlines the few missing functions after calling the original /usr/include/string.h. That at least leaves the factory distribution unmodified.

[jeremyhu (Jeremy Huddleston Sequoia)]

No, you should not be modifying your SDK to add a static inline version of strnlen. If we really wanted to go that route, we'd add -i${filesdir}/strnlen.h to CFLAGS, but I'm hoping to come up with a more general solution to this.

[jeremyhu (Jeremy Huddleston Sequoia)]

The issue also impacts older BSDs and other operating systems. While it has been around for a while, this function was only added to POSIX in SUSv4.

[mojca (Mojca Miklavec)]

I added clang-3.9 to the list of ports. Even though this is not exact, it's affected and users (me included) might search for open tickets for clang-3.9 without success (forgetting about existence of llvm).

[jeremyhu (Jeremy Huddleston Sequoia)]

In e5c93e65/macports-ports:

llvm-{3.9,devel}: Provide implementation of strnlen for pre-Lion

Fixes #51520

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@…>

[jeremyhu (Jeremy Huddleston Sequoia)]

In b9031fa3/macports-ports:

llvm-{3.9,devel}: Provide implementation of strnlen for pre-Lion

Fixes #51520

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@…>