I ran into a difference between the system and ports gcc. When using
-fstack-protector the system gcc passes -lssp_nonshared to the linker
and ports gcc doesn't, which causes the undefined reference below:
% cat test.c
int
main( void ) {
return( 0 );
}
% gcc46 -o test test.c -fstack-protector-
On 11-09-2012 16:10, Dimitry Andric wrote:
> On 2012-09-11 15:24, Steve Kargl wrote:
>> What is important is whether software built with clang functions
>> correctly. See for example,
>>
>> http://math-atlas.sourceforge.net/errata.html#WhatComp
>
> Yes, maths support, specifically precision, is a
On 15-09-2012 03:06, Steve Kargl wrote:
> On Fri, Sep 14, 2012 at 05:18:08PM -0700, Steve Kargl wrote:
>>
>> A third class of failure appears to be that clang emits
>> i387 fpu instructions for at least sinf and cosf instead
>> of calls to the library routines. AFAIK, the library
>> routines are
On 15-09-2012 14:48, Roman Divacky wrote:
> Fwiw, this seems to have been fixed as of a few minutes ago.
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html
>
> Steve, can you please test llvm/clang from (their) svn and report
> back? We can import a newer snapsho
On 15-09-2012 16:09, Roman Divacky wrote:
> Is this correct?
>
> lev ~$ ./cos 1.23456789e20
> 6.031937e-01
> -9.629173e-02
> 2.814722e-01
Yes, that's what the libm call returns.
signature.asc
Description: OpenPGP digital signature
On 15-09-2012 17:39, Mehmet Erol Sanliturk wrote:
> On Sat, Sep 15, 2012 at 7:30 AM, Tijl Coosemans wrote:
>> On 15-09-2012 16:09, Roman Divacky wrote:
>>> Is this correct?
>>>
>>> lev ~$ ./cos 1.23456789e20
>>> 6.031937e-01
>>> -9.629173e-02
Whatever the command line arguments, running c89 almost always results in
the following output. Anyone else seeing this?
c89: illegal option -- 1
usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] ...
[-o outfile] [-U name] ... operand ...
where operand
On 2013-03-07 20:28, Dimitry Andric wrote:
> On 2013-03-07 18:24, Tijl Coosemans wrote:
>> Whatever the command line arguments, running c89 almost always results in
>> the following output. Anyone else seeing this?
>>
>> c89: illegal option -- 1
>> usage: c89 [
On 2013-03-07 22:36, Warner Losh wrote:
> On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote:
>> On 2013-03-07 21:22, Tijl Coosemans wrote:
>> ...
>>> Because it's the practical thing to do? Old code/makefiles can't possibly
>>> be expected to know about
On 2013-03-08 04:07, Eitan Adler wrote:
> On 7 March 2013 18:03, Tijl Coosemans wrote:
>> On 2013-03-07 22:36, Warner Losh wrote:
>>> On Mar 7, 2013, at 2:28 PM, Dimitry Andric wrote:
>>>> On 2013-03-07 21:22, Tijl Coosemans wrote:
>>>> ...
>>>
On 2013-07-09 00:05, Andriy Gapon wrote:
> Seems like the problem boils down to this:
>
> $ make -V MAKEFILE
> /usr/ports/security/vpnc/Makefile
> $ fmake -V MAKEFILE
> Makefile
>
> The only explicit assignments of MAKEFILE that I could find in ports
> infrastructure are these:
> /usr/ports/Mk/bs
On 2013-07-10 20:32, O. Hartmann wrote:
> On Wed, 10 Jul 2013 18:04:16 +0100
> David Chisnall wrote:
>
>> On 10 Jul 2013, at 17:33, "O. Hartmann"
>> wrote:
>>
>>> Hi David,
>>>
>>> thanks for the fast response.
>>>
>>> The code I was told to check with is this:
>>>
>>> #include
>>> #include
>>
On 2013-07-11 06:21, Bruce Evans wrote:
> On Wed, 10 Jul 2013, Garrett Wollman wrote:
>> < said:
>>> I think isnan(double) and isinf(double) in math.h should only be
>>> visible if (_BSD_VISIBLE || _XSI_VISIBLE) && __ISO_C_VISIBLE < 1999.
>>> For C99 and higher there should only be the isnan/isinf
Hi,
I was trying to build multimedia/x264 using clang as follows:
In the Makefile remove USE_GCC=any.
In option dialog on leave PGO on.
It ends in the following linker error:
cc -o x264 x264.o input/input.o input/timecode.o input/raw.o input/y4m.o
output/raw.o output/matroska.o output/matroska
Hi,
I've attached a small test program extracted from multimedia/gstreamer-ffmpeg
(libavcodec/h264_cabac.c:ff_h264_init_cabac_states(H264Context *h)).
When you compile and run it like this on FreeBSD/i386, it results in a
SIGBUS:
% cc -o paddd paddd.c -O3 -msse2 -fPIE -fomit-frame-pointer
% ./p
On Tue, 10 Sep 2013 18:16:01 +0200 Tijl Coosemans wrote:
> I've attached a small test program extracted from multimedia/gstreamer-ffmpeg
> (libavcodec/h264_cabac.c:ff_h264_init_cabac_states(H264Context *h)).
>
> When you compile and run it like this on FreeBSD/i386, it resu
On Wed, 18 Sep 2013 23:13:26 +0200 Dimitry Andric wrote:
> On Sep 10, 2013, at 18:34, Tijl Coosemans wrote:
>> On Tue, 10 Sep 2013 18:16:01 +0200 Tijl Coosemans wrote:
>>> I've attached a small test program extracted from
>>> multimedia/
Hi,
With -fms-extensions clang 3.4 seems to define a built-in type named
__wchar_t. This conflicts with __wchar_t in /usr/include/machine/_types.h
% cat test.c
#include
% cc -c test.c -fms-extensions
In file included from test.c:1:
In file included from /usr/include/sys/types.h:44:
In file in
On Tue, 18 Mar 2014 18:47:18 +0100 Dimitry Andric wrote:
> On 18 Mar 2014, at 16:38, Tijl Coosemans wrote:
>> With -fms-extensions clang 3.4 seems to define a built-in type named
>> __wchar_t. This conflicts with __wchar_t in /usr/include/machine/_types.h
>>
>>
&
On Sat, 17 Jan 2015 05:05:48 +1100 Dewayne Geraghty
wrote:
> I would appreciate advise on the best approach to install openssl that
> has been built with gcc48 without needing to install gcc and binutils
> into the target machine?
>
> Background
> Attempting to run sshd or openssl resulted in
>
On Wed, 8 Jun 2016 19:21:16 -0400 Jung-uk Kim wrote:
> On 06/ 8/16 07:09 PM, Dimitry Andric wrote:
>> On 09 Jun 2016, at 00:30, Jung-uk Kim wrote:
>>> On 06/ 8/16 06:16 PM, Dimitry Andric wrote:
On 08 Jun 2016, at 23:54, Jung-uk Kim wrote:
> On 06/ 8/16 05:15 PM, Dimitry Andric wr
On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl
wrote:
> On Sun, Aug 14, 2016 at 07:34:30PM -0400, Diane Bruce wrote:
>> On Sun, Aug 14, 2016 at 04:03:51PM -0700, Steve Kargl wrote:
>>> Freebsd-ports could also use a wrapper:
>>> % cat ~/bin/gfc7
>>> #! /bin/sh
>>> DIR=`id -P sgk | sed 's/\:/\ /
On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric wrote:
> On 18 Aug 2016, at 11:15, Tijl Coosemans wrote:
>> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl
>> wrote:
>>> % gfortran6 -o z foo.f90 && ./z
>>> /lib/libgcc_s.so.1: version GCC_4.
On Fri, 19 Aug 2016 10:28:14 +0300 Konstantin Belousov
wrote:
> The option which would fix all this mess is:
> 1. add rpath for gcc lib/ directory into spec file
> and
> 2. make ports collection use its own compiler instead of fighting with
>the base.
That still doesn't cover all cases, e.g.
On Thu, 27 Jul 2017 21:42:01 + pkg-fall...@freebsd.org wrote:
> You are receiving this mail as a port that you maintain
> is failing to build on the FreeBSD package build server.
> Please investigate the failure and submit a PR to fix
> build.
>
> Maintainer: t...@freebsd.org
> Last commit
On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric wrote:
> On 28 Jul 2017, at 13:55, Tijl Coosemans wrote:
>>
>> On Thu, 27 Jul 2017 21:42:01 + pkg-fall...@freebsd.org wrote:
> ...
>>> In file included from squirrel/squirrel/sqvm.cc:5:
>>> In file incl
On Sat, 29 Jul 2017 00:34:39 -0700 Mark Millard wrote:
> On 2017-Jul-28, at 4:59 PM, Tijl Coosemans wrote:
>> On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric
>> wrote:
>>> On 28 Jul 2017, at 13:55, Tijl Coosemans wrote:
>>>>
>>>
On Sat, 29 Jul 2017 12:43:59 -0700 Mark Millard wrote:
> On 2017-Jul-29, at 12:27 PM, Tijl Coosemans wrote:
>> On Sat, 29 Jul 2017 00:34:39 -0700 Mark Millard
>> wrote:
>>> On 2017-Jul-28, at 4:59 PM, Tijl Coosemans wrote:
>>>> On Fri, 28 Ju
On Sat, 29 Jul 2017 22:16:46 -0700 Mark Millard wrote:
> On 2017-Jul-29, at 3:24 PM, Mark Millard wrote:
>> On 2017-Jul-29, at 2:06 PM, Tijl Coosemans wrote:
>>> - Adding -std=c++98 still fails to compile with the same errors.
>>>
>>> - The compiler defau
29 matches
Mail list logo
