Closed
Bug 860222
Opened 12 years ago
Closed 12 years ago
stun_build.o: requires dynamic R_X86_64_PC32 reloc against 'isascii' which may overflow at runtime; recompile with -fPIC
Categories
(Core :: WebRTC, defect)
Tracking
()
RESOLVED
FIXED
mozilla23
People
(Reporter: smaug, Assigned: ekr)
References
Details
(Whiteboard: [WebRTC] [blocking-webrtc-] [qa-])
Attachments
(2 files)
413.27 KB,
text/plain
|
Details | |
1.58 KB,
patch
|
glandium
:
review+
|
Details | Diff | Splinter Review |
/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
Comment 1•12 years ago
|
||
olli: for reference, OS and compiler/rev?
Assignee: nobody → ekr
Whiteboard: [WebRTC] [blocking-webrtc-]
Target Milestone: --- → mozilla23
Reporter | ||
Comment 2•12 years ago
|
||
clang 3.2 + gold.
gcc 4.7 + gold seems to work
Reporter | ||
Comment 3•12 years ago
|
||
64bit linux (Fedora 18)
Comment 4•12 years ago
|
||
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)
Comment 5•12 years ago
|
||
As requested by glandium on #developers.
Comment 6•12 years ago
|
||
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)
Comment 7•12 years ago
|
||
Note this breaks ASAN builds.
Comment 8•12 years ago
|
||
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.
Comment 9•12 years ago
|
||
(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/
![]() |
||
Comment 10•12 years ago
|
||
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.
Comment 11•12 years ago
|
||
(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
Comment 12•12 years ago
|
||
Comment 13•12 years ago
|
||
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)
Updated•12 years ago
|
Attachment #736461 -
Flags: review?(mh+mozilla) → review+
Comment 14•12 years ago
|
||
![]() |
||
Comment 15•12 years ago
|
||
Local clang 3.2 builds are working again for me. Thanks!
Comment 16•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Whiteboard: [WebRTC] [blocking-webrtc-] → [WebRTC] [blocking-webrtc-] [qa-]
Comment 17•11 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•11 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.
Description
•