Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Jan 2014 18:27:42 +0100
From:      Niclas Zeising <zeising+freebsd@daemonic.se>
To:        Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>
Cc:        freebsd-toolchain@freebsd.org, Dimitry Andric <dim@FreeBSD.org>
Subject:   Re: [CFT] Update to clang 3.4
Message-ID:  <52DFFF8E.70000@daemonic.se>
In-Reply-To: <52DFFF20.9000809@kbh.biglobe.ne.jp>
References:  <541C998A-071A-4917-9D91-DD00CB0E2689@FreeBSD.org> <63BD3165-A62E-4FE7-9817-4A2692584916@bsdimp.com> <264FAA6E-871A-48AF-A8D9-EC431A537195@FreeBSD.org> <F3FF55CD-4F78-4107-A595-BA6D91F0AFD3@FreeBSD.org> <6766B735-98CB-4F1D-B3B5-A43D81BB558A@FreeBSD.org> <52D286BE.7000102@kbh.biglobe.ne.jp> <50EAAC3C-2D38-4409-B525-2608D39BFE70@FreeBSD.org> <52DFCCFF.8080002@daemonic.se> <52DFFF20.9000809@kbh.biglobe.ne.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
On 01/22/14 18:25, Yamaya Takashi wrote:
> On 2014/01/22 22:51, Niclas Zeising wrote:
>> On 01/12/14 17:21, Dimitry Andric wrote:
>>> On 12 Jan 2014, at 13:12, Yamaya Takashi <yamayan@kbh.biglobe.ne.jp> wrote:
>>>> buildworld is failed when WITH_LLDB=
>>> Yes, this is a known issue. I discussed it with Ed Maste.  Clang 3.4
>>> will have to be imported first, afterwards we can fix lldb.  
>>>
>>>
>>>> some ports cannot build.
>>>>
>>>> reason1: clang cannot handle some options.
>>>> (libmad build)
>>>> cc: error: unknown argument: '-fforce-addr'
>>>> cc: error: unknown argument: '-fthread-jumps'
>>>> cc: error: unknown argument: '-fcse-follow-jumps'
>>>> cc: error: unknown argument: '-fcse-skip-blocks'
>>>> cc: error: unknown argument: '-fregmove'
>>>> cc: error: unknown argument: '-fschedule-insns2'
>>>> (libtheora build)
>>>> cc: error: unknown argument: '-fforce-addr'
>>>> (poppler build)
>>>> c++: error: unknown argument: '-fno-check-new'
>>>> (py27-sqlite build)
>>>> cc: error: unknown argument: '-R/usr/local/lib'
>>>> (tbb build)
>>>> c++: error: unknown argument: '-fno-schedule-insns2'
>>>> (gstreamer-ffmpeg build)
>>>> cc: error: unknown argument: '-fno-force-addr'
>>> Indeed, this is likely the most troublesome aspect of the upgrade.
>>>
>>> Most of the above options, like "-fcse-follow-jumps", "-fno-check-new",
>>> etc are gcc-specific, and will never be supported by clang.  These
>>> options will have to be removed, or made conditional on the compiler.
>>>
>>> The -R option is not a compiler option, but an ld option, and is also
>>> ambiguous: ld interprets it as --just-symbols when it is followed by the
>>> name of a file, but as -rpath when it is followed by the name of a
>>> directory.  In all cases, this should be replaced with -Wl,-rpath.
>>>
>>>
>>>> reason2: c++ -std=c++11 detect bad c++ code which older clang cannot detect.
>>>> (libproxy build)
>>>> /usr/ports/net/libproxy/work/libproxy-0.4.6/libproxy/modules/wpad_dns_alias.cpp:30:23:
>>>> error: cannot initialize return object of type 'libproxy::url *' with an
>>>> rvalue of type 'bool'
>>>>                if (lasturl) return false;
>>>>                                    ^~~~~
>>>> (liveMedia build)
>>> I have not looked in detail at this one, but this looks like a simple
>>> bug.  The code should not return a boolean when the return type of the
>>> function is a libproxy::url pointer.  Should be easy to fix.
>>>
>>> The new C++11 rules make it possible to avoid 'casting' a false value to
>>> a NULL pointer, and clang 3.4 detects this.
>>>
>>>
>>>> c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include
>>>> -I. -DBSD=1 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1
>>>> -D_FILE_OFFSET_BITS=64 -DHAVE_SOCKADDR_LEN=1 -Wall -DBSD=1  -O2 -pipe
>>>> -Qunused-arguments -march=native -fPIC -fno-strict-aliasing -std=c++11
>>>> -Wno-c++11-narrowing -stdlib=libc++ -Wno-deprecated RTSPRegisterSender.cpp
>>>> RTSPClient.cpp:916:25: error: comparison between pointer and integer
>>>> ('const char *' and 'int')
>>>>  if (&line[paramIndex] == '\0') return False; // the header is assumed
>>>> to be bad if it has no parameters
>>>>      ~~~~~~~~~~~~~~~~~ ^  ~~~~
>>>> (mp4v2 build)
>>> This looks like an incorrect comparison: a pointer is compared with a
>>> literal character.  Should be easy to fix.
>>>
>>>
>>>> c++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -O2
>>>> -pipe -Qunused-arguments -march=native -fno-strict-aliasing -std=c++11 
>>>> -Wno-c++11-narrowing -stdlib=libc++ -fvisibility=hidden -c
>>>> src/mp4container.cpp  -fPIC -DPIC -o src/.libs/mp4container.o
>>>> src/mp4.cpp:679:20: error: cannot initialize return object of type
>>>> 'mp4v2_ismacrypParams *' (aka 'mp4v2_ismacryp_session_params *') with an
>>>> rvalue of type 'MP4TrackId' (aka 'unsigned int')
>>>>            return MP4_INVALID_TRACK_ID;
>>>>                   ^~~~~~~~~~~~~~~~~~~~
>>>> ./include/mp4v2/general.h:45:33: note: expanded from macro
>>>> 'MP4_INVALID_TRACK_ID'
>>>> #define MP4_INVALID_TRACK_ID    ((MP4TrackId)0)       /**< Constant:
>>>> invalid MP4TrackId. */
>>>>                                ^~~~~~~~~~~~~~~
>>>> (thunderbird build)
>>> Again, an attempt is made to use an incorrect type for the return value
>>> of a function.  Either the value should be explicitly cast to the
>>> correct type (mp4v2_ismacrypParams *), or the MP4_INVALID_TRACK_ID
>>> define should be fixed to be of the correct type.
>>>
>>>
>>>> clang++ -o jsoptparse.o -c  -I../../../dist/system_wrappers_js -include
>>>> /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/config/gcc_hidden.h
>>>> -DEXPORT_JS_API -DIMPL_MFBT -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT
>>>> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src -I..
>>>> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell -I.
>>>> -I../../../dist/include  -I/usr/local/include/nspr       -fPIC
>>>> -Qunused-arguments -isystem/usr/local/include  -Qunused-arguments -Wall
>>>> -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits
>>>> -Wempty-body -Werror=conversion-null -Wsign-compare
>>>> -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof
>>>> -Wno-unknown-warning-option -Wno-return-type-c-linkage
>>>> -Wno-mismatched-tags -O2 -pipe -Qunused-arguments -march=native -O3
>>>> -fno-strict-aliasing -std=c++11 -Wno-c++11-narrowing -stdlib=libc++
>>>> -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pipe 
>>>> -DNDEBUG -DTRIMMED -O2 -O3 -fomit-frame-pointer  -Qunused-arguments
>>>> -isystem/usr/local/include  -DMOZILLA_CLIENT -include ../js-confdefs.h
>>>> -MD -MP -MF .deps/jsoptparse.o.pp  /usr/ports/mail/thunderbir
>>>> d/work/comm-esr24/mozilla/js/src/shell/jsoptparse.cpp
>>>> /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell/jsoptparse.cpp:256:22:
>>>> error: comparison between pointer and integer ('char *' and 'int')
>>>>        if (value[0] == '\0')
>>>>            ~~~~~~~~ ^  ~~~~
>>> Like the mp4v2 build, this is probably a simple bug.  The code should
>>> not compare a pointer to an integer.  Most likely, the right side was
>>> supposed to be NULL instead?
>>>
>> I'm probably late to the party, as always... But, have you or Yamaya
>> Takashi tried to punt these issues to the respective port managers for
>> investigation?
>> Regards!
> I have patches for libproxy, liveMedia, mp4v2 and thunderbird.
> 
> 

Send them to the respective maintainer.  I've already sent a patch for
thunderbird though, since I found one in their bugzilla.
Regards!
-- 
Niclas



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52DFFF8E.70000>