917526 - [10.9] Various duplicate symbols error building tree with the 10.9 SDK

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Steven Michaud [:smichaud] (Retired)]

I get the following error building current trunk with --disable-optimize and the 10.9 SDK specified in my mozconfig file:

...
nsinstall_real
clang -o nsinstall_real -Qunused-arguments  -Qunused-arguments -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wsign-compare -Wno-unused -isysroot /Developer/SDKs/MacOSX10.9.sdk -std=gnu99 -fgnu89-inline -fno-common -fno-math-errno -pthread -pipe  -DNDEBUG -DTRIMMED -g -fno-omit-frame-pointer  -DXP_UNIX -DXP_MACOSX -DNO_X11  -DUNICODE -D_UNICODE -lobjc  -framework ExceptionHandling -Wl,-executable_path,../../../dist/bin host_nsinstall.o host_pathsub.o  
duplicate symbol ___sputc in:
    host_nsinstall.o
    host_pathsub.o
ld: 1 duplicate symbol for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
...

Comment 1

[Steven Michaud [:smichaud] (Retired)]

This happens building in the js/src/config directory.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

This may be a clang bug, but it involves subtleties about the behavior of the "inline" keyword (compiling with and without -fgnu89-inline) that are far beyond my knowledge.

__sputc() is defined as follows in the stdio.h that comes with Apple's current developer preview (DP8) of OS X 10.9:

__header_always_inline int __sputc(int _c, FILE *_p) {
        if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
                return (*_p->_p++ = _c);
        else
                return (__swbuf(_c, _p));
}

"__header_always_inline" ends up (I think) getting defined as follows in sys/cdefs.h:

inline __attribute__ ((__always_inline__))

This works just fine if we get rid of -fgnu89-inline here:

http://hg.mozilla.org/mozilla-central/annotate/e8bb95435a54/js/src/configure.in#l1064

But I doubt that's feasible in the general case.  And it's puzzling that "inline __attribute__ ((__always_inline__))" would fail to work properly (to force inlining in all cases) when we compile with -fgnu89-inline.

Ted, Jeff:  Any idea what's going on?

Comment 3

[Jeff Walden [:Waldo]]

(In reply to Steven Michaud from comment #2)
> This works just fine if we get rid of -fgnu89-inline here:
> 
> http://hg.mozilla.org/mozilla-central/annotate/e8bb95435a54/js/src/configure.
> in#l1064
> 
> But I doubt that's feasible in the general case.

Actually glandium claimed recently that it would be feasible, now that we've updated some tinderboxen, to drop that.  (And in the main configure.in.)  Maybe tryserver that change and see?

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Here's the output of "clang --version" on my system:

Apple LLVM version 5.0 (clang-500.1.74) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

Comment 5

[Steven Michaud [:smichaud] (Retired)]

> Maybe tryserver that change and see?

Will do.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

https://tbpl.mozilla.org/?tree=Try&rev=adeb8c7d19d6

Comment 7

[(not currently active) Ted Mielczarek]

Sorry, I don't have a clue here.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

> https://tbpl.mozilla.org/?tree=Try&rev=adeb8c7d19d6

There were no build failures, and no non-spurious failures of any kind.  So it might be worthwhile getting rid of -fgnu89-inline on the trunk, at least temporarily, to see what happens.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

Attachment: Possible workaround

Here's the patch I tested (successfully) on the tryservers.

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Attachment: Possible workaround rev1

Changed the comments to match the code changes.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 807290 [details] [diff] [review]
Possible workaround rev1

Glandium, what do you think of this?

If you think it also needs other reviewers, please add them.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 807290 [details] [diff] [review]
Possible workaround rev1

This patch also works around many more (different) duplicate symbol errors when --disable-optimize is not specified.

Comment 13

[Mike Hommey [:glandium]]

Comment on attachment 807290 [details] [diff] [review]
Possible workaround rev1

Review of attachment 807290 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +1233,5 @@
>  dnl GNU specific defaults
>  dnl ========================================================
>  if test "$GNU_CC"; then
> +    # Use C99 plus GNU extensions.  See bug 719659.
> +    CFLAGS="$CFLAGS -std=gnu99"

I'd rather keep -fgnu89-inline on non-osx systems.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

> I'd rather keep -fgnu89-inline on non-osx systems.

OK.  New patch coming up.

Comment 15

[Steven Michaud [:smichaud] (Retired)]

Attachment: Possible workaround rev2

How's this?

Comment 16

[Mike Hommey [:glandium]]

Comment on attachment 808042 [details] [diff] [review]
Possible workaround rev2

Review of attachment 808042 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +1240,5 @@
> +    if test "${OS_ARCH}" = Darwin; then
> +        CFLAGS="$CFLAGS -std=gnu99"
> +    else
> +        CFLAGS="$CFLAGS -std=gnu99 -fgnu89-inline"
> +    fi

CFLAGS="$CFLAGS -std=gnu99"
if test "${OS_ARCH}" != Darwin; then
    CFLAGS="$CFLAGS -fgnu89-inline"
fi

Comment 17

[Steven Michaud [:smichaud] (Retired)]

Attachment: Possible workaround rev3

Carrying forward glandium's r+.

Comment 18

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 808090 [details] [diff] [review]
Possible workaround rev3

Landed on mozilla-inbound:
https://hg.mozilla.org/integration/mozilla-inbound/rev/5e4d9cc03f15

Comment 19

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/5e4d9cc03f15

Comment 20

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/8f7b67049ddb
https://hg.mozilla.org/releases/mozilla-esr24/rev/cd95f0b51ca1