Re: hosted, or not (Re: Renaming all symbols in libmp(3))

2009-02-28 Thread perryh
Roman Divacky freebsd.org!rdiva...@agora.rdrop.com wrote: On Thu, Feb 26, 2009 at 11:46:22PM -0800, per...@pluto.rain.com wrote: By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default ... ... it's invalid code to have

Re: hosted, or not (Re: Renaming all symbols in libmp(3))

2009-02-28 Thread Ed Schouten
* per...@pluto.rain.com per...@pluto.rain.com wrote: So perhaps one solution would be to compile libmp with -ffreestanding? And all applications that use mp.h. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpwD14uSm0Hj.pgp Description: PGP signature

Re: hosted, or not (Re: Renaming all symbols in libmp(3))

2009-02-28 Thread Roman Divacky
On Sat, Feb 28, 2009 at 10:24:56AM +0100, Ed Schouten wrote: * per...@pluto.rain.com per...@pluto.rain.com wrote: So perhaps one solution would be to compile libmp with -ffreestanding? And all applications that use mp.h. which is a nonsense... please move forward

hosted, or not (Re: Renaming all symbols in libmp(3))

2009-02-27 Thread perryh
By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default ... ... it's invalid code to have a function named pow() in a hosted environment which is not /The/ pow(). ^^^ I don't suppose LLVM supports a

Re: hosted, or not (Re: Renaming all symbols in libmp(3))

2009-02-27 Thread Roman Divacky
On Thu, Feb 26, 2009 at 11:46:22PM -0800, per...@pluto.rain.com wrote: By default, LLVM has a built-in prototype of pow(), similar to GCC. Unlike GCC, LLVM raises a compiler error by default ... ... it's invalid code to have a function named pow() in a hosted environment which is not

Renaming all symbols in libmp(3)

2009-02-26 Thread Ed Schouten
Hello all, As you may have read some days ago, work has started to make the FreeBSD base system compile better with clang, the BSD licensed C compiler from the LLVM project. One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv,

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread Daniel Eischen
On Thu, 26 Feb 2009, Ed Schouten wrote: Hello all, As you may have read some days ago, work has started to make the FreeBSD base system compile better with clang, the BSD licensed C compiler from the LLVM project. One of the reasons why we can't compile the base system yet, is because some

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread Ed Schouten
* Daniel Eischen deisc...@freebsd.org wrote: Why don't you add symbol versioning to libmp, so that old binaries will still work, but new ones will get the new symbols by default. Hmm, will that work without bumping SHLIB_MAJOR? You might want to play around with it and see. Well, even

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread Daniel Eischen
On Thu, 26 Feb 2009, Ed Schouten wrote: * Daniel Eischen deisc...@freebsd.org wrote: Why don't you add symbol versioning to libmp, so that old binaries will still work, but new ones will get the new symbols by default. Hmm, will that work without bumping SHLIB_MAJOR? You might want to play

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread Ed Schouten
* Daniel Eischen deisc...@freebsd.org wrote: Well, as long as you're in there, maybe you should add symbol versioning anyway, even after a library version bump. Seems like it would be easy since there aren't that many symbols. I assume I should just mark all symbols with version FBSD_1.1? If

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread David Schultz
On Thu, Feb 26, 2009, Ed Schouten wrote: One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has a function called pow(). By default, LLVM has a

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread Christoph Mallon
David Schultz schrieb: On Thu, Feb 26, 2009, Ed Schouten wrote: One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has a function called pow(). By

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread Christoph Mallon
Christoph Mallon schrieb: David Schultz schrieb: On Thu, Feb 26, 2009, Ed Schouten wrote: One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they depend (libmp)on has

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread Daniel Eischen
On Thu, 26 Feb 2009, Ed Schouten wrote: * Daniel Eischen deisc...@freebsd.org wrote: Well, as long as you're in there, maybe you should add symbol versioning anyway, even after a library version bump. Seems like it would be easy since there aren't that many symbols. I assume I should just

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread David Schultz
On Thu, Feb 26, 2009, Christoph Mallon wrote: David Schultz schrieb: On Thu, Feb 26, 2009, Ed Schouten wrote: One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile, because a library they

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread Christoph Mallon
David Schultz schrieb: On Thu, Feb 26, 2009, Christoph Mallon wrote: David Schultz schrieb: On Thu, Feb 26, 2009, Ed Schouten wrote: One of the reasons why we can't compile the base system yet, is because some applications in the base system (keyserv, newkey, chkey, libtelnet) won't compile,

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread David Schultz
On Thu, Feb 26, 2009, Christoph Mallon wrote: David Schultz schrieb: As for gcc's math builtins, most of them are buggy. They fail to respect the dynamic rounding mode, fail to generate exceptions where appropriate, fail to respect FENV_ACCESS and other pragmas, etc. Also, the complex

Re: Renaming all symbols in libmp(3)

2009-02-26 Thread Christoph Mallon
David Schultz schrieb: On Thu, Feb 26, 2009, Christoph Mallon wrote: David Schultz schrieb: As for gcc's math builtins, most of them are buggy. They fail to respect the dynamic rounding mode, fail to generate exceptions where appropriate, fail to respect FENV_ACCESS and other pragmas, etc.