__udivti3 undefined when compiling with Apple LLVM v 6.0

[RafaelBaptista]

Apple has upgraded to a new version of clang - v6. But the __udivti3 issue persists. See this related issue:

#67

So the check for avoiding built-in 128 division should be updated to exclude clang 6 as well.

[mpg]

Thanks for reporting again. In the meantime I got an OS X (Mavericks) machine, and I can't seem to reproduce your issue here. Steps used: set my PATH to /usr/bin:/bin:/usr/sbin:/sbin in order to avoid any interference from locally installed software, then make clean all. Version used:

gcc --version                                         
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

Can you please tell me more about your setup?

[RafaelBaptista]

Here is the link error I get:

Linking [d] dh_server : dh_server.o libpolarssl.a
Undefined symbols for architecture x86_64:
"___udivti3", referenced from:
_mpi_div_mpi in libpolarssl.a(bignum.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)

This is the output of gcc --version:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix

This is on a machine that was rebuilt from scratch a week ago. ( e.g. the
current version of gcc is the only version ever installed on this machine )

I have polarSSL building with my own build system, so I'm not using the
makefiles that come with PolarSSL. But I think I'm doing things right. But
just to be sure here are the actual build commands for bignum.c:

gcc -g -c -W -Wall -Wno-unused-parameter -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-mmacosx-version-min=10.4
-arch x86_64 -Isrc -Ibin/darwin-x86_64/debug -DDARWIN -DPOSIX -D_DEBUG
-DDEBUG src/bignum.c -o bin/darwin-x86_64/debug/static/bignum.o

and a typical file that fails to link:

g++ -Lbin/darwin-x86_64/debug bin/darwin-x86_64/debug/static/pem2der.o
-lpolarssl -rdynamic -lpthread -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-mmacosx-version-min=10.4 -arch x86_64 -o bin/darwin-x86_64/debug/util

On Fri, Jan 23, 2015 at 4:38 PM, Manuel Pégourié-Gonnard <
[email protected]> wrote:

Thanks for reporting again. In the meantime I got an OS X (Mavericks)
machine, and I can't seem to reproduce your issue here. Steps used: set my
PATH to /usr/bin:/bin:/usr/sbin:/sbin in order to avoid any interference
from locally installed software, then make clean all. Version used:

gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix

Can you please tell me more about your setup?

—
Reply to this email directly or view it on GitHub
#144 (comment).

[mpg]

I see you're using -isysroot and I'm wondering if the chosen path contains a suitable version of libgcc.a, where the linker is supposed to find the definition of __udivti3. Maybe passing -Wl,--verbose to gcc would help shed some light on what's happening here.

Did you also try to build PolarSSL with our Makefiles, on the same machine? It would be a good way to know whether the issue is with your toolchain or with the way it's invoked.

[RafaelBaptista]

Ok. I downloaded and compiled polarssl 1.3.10, and built on my system with
the supplied "make", and it works perfectly.

So the error must be in my own build environment.

On Wed, Feb 11, 2015 at 10:25 AM, Manuel Pégourié-Gonnard <
[email protected]> wrote:

I see you're using -isysroot and I'm wondering if the chosen path contains
a suitable version of libgcc.a, where the linker is supposed to find the
definition of __udivti3. Maybe passing -Wl,--verbose to gcc would help
shed some light on what's happening here.

Did you also try to build PolarSSL with our Makefiles, on the same
machine? It would be a good way to know whether the issue is with your
toolchain or with the way it's invoked.

—
Reply to this email directly or view it on GitHub
#144 (comment).

[mpg]

Ok, so I this this issue can be closed. If/when you find out the issue, I'm curious the know what is was, if you feel like sharing.

[RafaelBaptista]

Yeah. After your email I noticed that -isysroot was pointing to the 10.9
SDK. I updated that to point to the newer 10.10 SDK. I thought for sure
that would solve it especially after seeing that your make file works
correctly. But strangely it didn't. When I find the source of the issue
I'll email you.

On Thu, Feb 12, 2015 at 4:34 AM, Manuel Pégourié-Gonnard <
[email protected]> wrote:

Ok, so I this this issue can be closed. If/when you find out the issue,
I'm curious the know what is was, if you feel like sharing.

—
Reply to this email directly or view it on GitHub
#144 (comment).