stun_build.o: requires dynamic R_X86_64_PC32 reloc against 'isascii' which may overflow at runtime; recompile with -fPIC

RESOLVED FIXED in mozilla23

Status

()

RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: smaug, Assigned: ekr)

Tracking

unspecified
mozilla23
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [WebRTC] [blocking-webrtc-] [qa-])

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
/usr/bin/ld: error: /home/smaug/mozilla/hg/inbound/ff_build/toolkit/library/../../media/mtransport/third_party/nICEr/nicer_nicer/src/stun/stun_build.o: requires dynamic R_X86_64_PC32 reloc against 'isascii' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: hidden symbol 'isascii' is not defined locally
/usr/bin/ld: error: hidden symbol 'isascii' is not defined locally
(Reporter)

Updated

6 years ago
Blocks: 786235
olli: for reference, OS and compiler/rev?
Assignee: nobody → ekr
Whiteboard: [WebRTC] [blocking-webrtc-]
Target Milestone: --- → mozilla23
(Reporter)

Comment 2

6 years ago
clang 3.2 + gold.

gcc 4.7 + gold seems to work
(Reporter)

Comment 3

6 years ago
64bit linux (Fedora 18)
Ok, that's odd, since we're including <ctype.h> (I thought we weren't but just checked and we are).  And while isascii() is rare in the tree, isdigit() is all over the place.  But isascii is a little different in <ctype.h>; it depends on stuff like:

if defined __USE_SVID || defined __USE_MISC || defined __USE_XOPEN

To decide whether to use internal impls (__isascii():
#define	__isascii(c)	(((c) & ~0x7f) == 0)	/* If C is a 7 bit value.  */
or an external impl, it appears.  My guess is clang somehow is using different #defines.  You might need to look at the preprocessor output.

glandium? ideas?
Flags: needinfo?(mh+mozilla)
Created attachment 735832 [details]
stun_build.i

As requested by glandium on #developers.
There is no declaration of isascii at all in the preprocessed file, so clang ends up using an implicit extern declaration of isascii, with visibility hidden because of -fvisibility=hidden. Which then fails to link against libc's isascii. gcc doesn't have the problem because it is either inlining an implementation, or using an implicit declaration with an explicit default visibility. That /might/ be a clang bug, especially if gcc is doing the latter, but the root problem is using isascii, which is an obsolete BSD extension.
Flags: needinfo?(mh+mozilla)
Note this breaks ASAN builds.
So, this is almost certainly due to none of 
#if defined __USE_SVID || defined __USE_MISC || defined __USE_XOPEN
being defined (per above), one of which apparently is for gcc.  (See /usr/include/ctype.h).

Apparently (hard to find hard info, but per MSFT) __isascii is a posix replacement for isascii().  I'll try that.
(In reply to Randell Jesup [:jesup] from comment #8)
> Apparently (hard to find hard info, but per MSFT) __isascii is a posix
> replacement for isascii().  I'll try that.

The is no mention of it I can find in POSIX.1-2008.
http://pubs.opengroup.org/onlinepubs/9699919799/
Can we just implement it ourselves?  Doesn't seem hard.

       isascii()
              checks whether c is a 7-bit unsigned char value that  fits  into
              the ASCII character set.

|c <= 0 && c <= 127| seems like it would do it, though I'd check it exhaustively against an existing isascii() implementation if I were to implement it myself.
(In reply to Nicholas Nethercote [:njn] from comment #10)
> |c <= 0 && c <= 127| seems like it would do it

See comment 4 for the __isascii implementation from ctype.h
Created attachment 736461 [details] [diff] [review]
use our own isascii() for sanitizing TURN passwords

https://tbpl.mozilla.org/?tree=Try&rev=0223de8a9b6e
Comment on attachment 736461 [details] [diff] [review]
use our own isascii() for sanitizing TURN passwords

I'll get rid of the tab.

Some platforms have __isascii(); mac (for one) does not.
Attachment #736461 - Flags: review?(mh+mozilla)
Attachment #736461 - Flags: review?(mh+mozilla) → review+
Local clang 3.2 builds are working again for me.  Thanks!
https://hg.mozilla.org/mozilla-central/rev/e41c1fc65901
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED

Updated

6 years ago
Whiteboard: [WebRTC] [blocking-webrtc-] → [WebRTC] [blocking-webrtc-] [qa-]

Comment 17

5 years ago
I built on my Ubuntu and got the following errors. Is there anyone having this problem?

 0:52.14 ../../../build/unix/gold/ld: error: /home/steven/workspace/b2g/mozilla-central/objdir-desktop-debug/toolkit/library/build/../../../content/media/webrtc/Unified_cpp_content_media_webrtc0.o: requires dynamic R_X86_64_PC32 reloc against 'mozilla::MediaEngine::DEFAULT_169_VIDEO_WIDTH' which may overflow at runtime; recompile with -fPIC
 0:52.14 ../../../build/unix/gold/ld: error: /home/steven/workspace/b2g/mozilla-central/objdir-desktop-debug/toolkit/library/build/../../../content/media/webrtc/Unified_cpp_content_media_webrtc0.o: requires dynamic R_X86_64_PC32 reloc against 'mozilla::MediaEngine::DEFAULT_169_VIDEO_HEIGHT' which may overflow at runtime; recompile with -fPIC
 0:52.14 ../../../build/unix/gold/ld: error: read-only segment has dynamic relocations
 0:52.14 /home/steven/workspace/b2g/mozilla-central/content/media/webrtc/MediaEngine.h:158: error: undefined reference to 'mozilla::MediaEngine::DEFAULT_169_VIDEO_WIDTH'
 0:52.14 /home/steven/workspace/b2g/mozilla-central/content/media/webrtc/MediaEngine.h:158: error: undefined reference to 'mozilla::MediaEngine::DEFAULT_43_VIDEO_WIDTH'
 0:52.14 /home/steven/workspace/b2g/mozilla-central/content/media/webrtc/MediaEngine.h:163: error: undefined reference to 'mozilla::MediaEngine::DEFAULT_169_VIDEO_HEIGHT'
 0:52.14 /home/steven/workspace/b2g/mozilla-central/content/media/webrtc/MediaEngine.h:163: error: undefined reference to 'mozilla::MediaEngine::DEFAULT_43_VIDEO_HEIGHT'11

Comment 18

5 years ago
Sorry, I posted the message on the wrong bug. I filed another bug for it.
You need to log in before you can comment on or make changes to this bug.