if test -z "$AR_FLAGS"; then
GNU ar documents the 'T' flag like so:
T Make the specified archive a thin archive. If it already exists and is a regular archive, the existing
members must be present in the same directory as archive.
FreeBSD ar documents the 'T' flag like so:
-T Use only the first fifteen characters of the archive member name
or command line file name argument when naming archive members.
This fragment of Source/WebKit2/GNUmakefile.am:
$(AM_V_at)$(shell rm -f $@)
$(AM_V_at)$(shell find . -name "*.o" > objects_list)
$(AM_V_at)$(foreach archive, $(webcore_layer_gtk2_archives), $(shell $(AR) t $(archive) | xargs -n1 basename | xargs -I obj_file grep -F obj_file objects_list | xargs -n50 $(AR) $(AR_FLAGS) $@))
$(AM_V_at)$(shell rm -f objects_list)
results in a bunch of arguments like './Source/WebCore/platform/graphics/libPlatform_la-FloatRect.o' being passed to 'ar'.
Of course, most of those arguments will share the same first 15 characters, and as a result, a large number of files are not included in the archive.
Webkit should not use 'ar T' on systems with a non-GNU toolchain, or it should explicitly require a GNU toolchain and make sure it uses that.
Created attachment 223846 [details]
SetupLibtool.m4: use 'ar T' only on GNU ar
Created attachment 223848 [details]
The patch looks fine, here's the updated one with the changelog entry.
Committed r163954: <http://trac.webkit.org/changeset/163954>
I know this has been fixed/commited, but as it was already sort-of fixed in https://bugs.webkit.org/show_bug.cgi?id=118732, couldnt you set AR_FLAGS=cru in the build environment to avoid having to patch autohell this way ?
I don't think it should be expected to have to set an environment variable to prevent it from containing non-POSIX values...
If anything, it should be the other way around.
I think having this check can make everyone happy.
(In reply to comment #5)
> I don't think it should be expected to have to set an environment variable to prevent it from containing non-POSIX values...
> If anything, it should be the other way around.
> I think having this check can make everyone happy.
I totally agree (and i'm happy with the check for OpenBSD too!), was just wondering about the reasoning - usually it's not so easy to get non-linux fixes in :)
(In reply to comment #6)
> I totally agree (and i'm happy with the check for OpenBSD too!), was
> just wondering about the reasoning - usually it's not so easy to get
> non-linux fixes in :)
The solution proposed by Ryan looked just fine to me. And I've been
pushing non-linux fixes for a long time btw :)