On 01/12/14 17:21, Dimitry Andric wrote:
> On 12 Jan 2014, at 13:12, Yamaya Takashi <yama...@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!
--
Niclas
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
