# build deps 13 messages from 2012-10-08 to 2012-10-16. Participants: Thiago Farina, Andrew Wong, Michael J Gruber, Junio C Hamano, David Aguilar. Thread: https://gitlist.dev/t/31748 ## Thiago Farina, 2012-10-08 00:39 Subject: build deps Message-ID: URL: https://gitlist.dev/e/CACnwZYe_vhH9Ui8W9D%3DM_8avgEugR%2BUvM1E%2BjH7fxr%2B8yk2UtQ%40mail.gmail.com ``` Hi, When trying to build from source but it's failing: $ sudo make prefix=/usr/local all LINK git-credential-store gcc: @CHARSET_LIB@: No such file or directory make: *** [git-credential-store] Error 1 I'm know I'm missing some dep and googling for it. But wouldn't be better if we have something like [1]? [1] http://git.chromium.org/gitweb/?p=chromium.git;a=blob;f=build/install-build-deps.sh;h=705d4c210455f36916be607d7fd0f32f0b472c70;hb=HEAD And yes, I'm following these instructions [2]. [2] http://git-scm.com/book/en/Getting-Started-Installing-Git ``` ## Andrew Wong, 2012-10-08 16:09 Subject: Re: build deps Message-ID: <5072FAD1.1000807@gmail.com> URL: https://gitlist.dev/e/5072FAD1.1000807%40gmail.com In-Reply-To: ``` On 10/07/12 20:39, Thiago Farina wrote: > When trying to build from source but it's failing: > > $ sudo make prefix=/usr/local all > LINK git-credential-store > gcc: @CHARSET_LIB@: No such file or directory > make: *** [git-credential-store] Error 1 Did you run the "configure" script? In the source folder, do you have either file "config.mak" or "config.mak.autogen" ? If you do, try removing them, and compile again. Which version are you compiling? Did you get the source files from tar? Or from git? ``` ## Thiago Farina, 2012-10-08 21:36 Subject: Re: build deps Message-ID: URL: https://gitlist.dev/e/CACnwZYeJ-FKXterxd697iu%2BU4HobqEaP0zx_p8CZDsPZx4hbHQ%40mail.gmail.com In-Reply-To: <5072FAD1.1000807@gmail.com> ``` On Mon, Oct 8, 2012 at 1:09 PM, Andrew Wong wrote: > On 10/07/12 20:39, Thiago Farina wrote: >> When trying to build from source but it's failing: >> >> $ sudo make prefix=/usr/local all >> LINK git-credential-store >> gcc: @CHARSET_LIB@: No such file or directory >> make: *** [git-credential-store] Error 1 > Did you run the "configure" script? Hum, I haven't. Now I did. > In the source folder, do you have either file "config.mak" or > "config.mak.autogen" ? After running ./configure, now I have. > If you do, try removing them, and compile again. > Which version are you compiling? $ cat GIT-VERSION-FILE GIT_VERSION = 1.7.12.84.gefa6462 > Did you get the source files from tar? > Or from git? From git (git://git.kernel.org/pub/scm/git/git.git). OK, after running ./configure I tried the make command again. CC credential-store.o /bin/sh: clang: not found make: *** [credential-store.o] Error 127 $ which clang /home/tfarina/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang $ clang --version clang version 3.2 (trunk 163674) Target: x86_64-unknown-linux-gnu Thread model: posix ``` ## Thiago Farina, 2012-10-08 21:37 Subject: Re: build deps Message-ID: URL: https://gitlist.dev/e/CACnwZYe5CR-1m4rfCcaLsh4rGDx_8kRNCPK31%3DAepqocG_Lwzg%40mail.gmail.com In-Reply-To: ``` On Mon, Oct 8, 2012 at 6:36 PM, Thiago Farina wrote: > On Mon, Oct 8, 2012 at 1:09 PM, Andrew Wong wrote: >> On 10/07/12 20:39, Thiago Farina wrote: >>> When trying to build from source but it's failing: >>> >>> $ sudo make prefix=/usr/local all >>> LINK git-credential-store >>> gcc: @CHARSET_LIB@: No such file or directory >>> make: *** [git-credential-store] Error 1 >> Did you run the "configure" script? > Hum, I haven't. > > Now I did. > > >> In the source folder, do you have either file "config.mak" or >> "config.mak.autogen" ? > After running ./configure, now I have. > >> If you do, try removing them, and compile again. >> Which version are you compiling? > $ cat GIT-VERSION-FILE > GIT_VERSION = 1.7.12.84.gefa6462 > >> Did you get the source files from tar? >> Or from git? > From git (git://git.kernel.org/pub/scm/git/git.git). > > OK, after running ./configure I tried the make command again. > > CC credential-store.o > /bin/sh: clang: not found > make: *** [credential-store.o] Error 127 > > $ which clang > /home/tfarina/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang > > $ clang --version > clang version 3.2 (trunk 163674) > Target: x86_64-unknown-linux-gnu > Thread model: posix Also: $ echo $CC clang -B/usr/local/gold/bin ``` ## Andrew Wong, 2012-10-08 22:52 Subject: Re: build deps Message-ID: <50735939.10604@gmail.com> URL: https://gitlist.dev/e/50735939.10604%40gmail.com In-Reply-To: ``` On 10/08/12 17:36, Thiago Farina wrote: > OK, after running ./configure I tried the make command again. > > CC credential-store.o > /bin/sh: clang: not found > make: *** [credential-store.o] Error 127 > > $ which clang > /home/tfarina/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang > > $ clang --version > clang version 3.2 (trunk 163674) > Target: x86_64-unknown-linux-gnu > Thread model: posix Looks like something went wrong with "make" setting PATH. I wonder if the "+" sign in your path is somehow messing things up. Are you trying to compile specifically with clang? If not, maybe try unsetting the CC env var, and run configure again? ``` ## Thiago Farina, 2012-10-11 20:54 Subject: Re: build deps Message-ID: URL: https://gitlist.dev/e/CACnwZYf56XkqW085HoWhAN2EnjCJd%3DVYHGAD8fZCCe6_FNhO2A%40mail.gmail.com In-Reply-To: <50735939.10604@gmail.com> ``` On Mon, Oct 8, 2012 at 7:52 PM, Andrew Wong wrote: > On 10/08/12 17:36, Thiago Farina wrote: >> OK, after running ./configure I tried the make command again. >> >> CC credential-store.o >> /bin/sh: clang: not found >> make: *** [credential-store.o] Error 127 >> >> $ which clang >> /home/tfarina/chromium/src/third_party/llvm-build/Release+Asserts/bin/clang >> >> $ clang --version >> clang version 3.2 (trunk 163674) >> Target: x86_64-unknown-linux-gnu >> Thread model: posix > Looks like something went wrong with "make" setting PATH. I wonder if > the "+" sign in your path is somehow messing things up. > Would be something that could be fixed in git? > Are you trying to compile specifically with clang? Nope, it just happen that I switched to clang because I use it to compile chromium and I need it to use the chrome_plugin[1]. > If not, maybe try > unsetting the CC env var, and run configure again? Just setting CC to gcc works for me. But still, I'd like to be able to build with clang (may be as you noted is just something with the + in my PATH). [1] http://git.chromium.org/gitweb/?p=chromium.git;a=tree;f=tools/clang/plugins;h=8e79d8f35d5ccfee82b6ab8f27ea8b5d820c772d;hb=HEAD ``` ## Andrew Wong, 2012-10-12 01:06 Subject: Re: build deps Message-ID: <50776D0D.9090306@gmail.com> URL: https://gitlist.dev/e/50776D0D.9090306%40gmail.com In-Reply-To: ``` On 10/11/12 16:54, Thiago Farina wrote: > Just setting CC to gcc works for me. But still, I'd like to be able to > build with clang (may be as you noted is just something with the + in > my PATH). Oh, I just realized you were using "sudo". The PATH environment was probably not inherited when you use sudo to run "make". So the subsequent shells statred by "make' were not able to find "clang". ``` ## Thiago Farina, 2012-10-12 04:08 Subject: Re: build deps Message-ID: URL: https://gitlist.dev/e/CACnwZYfmz1BTo6okzFh8jXbw%2B0MAV0sEanYXNzAnV7L4p7nY_g%40mail.gmail.com In-Reply-To: <50776D0D.9090306@gmail.com> ``` On Thu, Oct 11, 2012 at 10:06 PM, Andrew Wong wrote: > On 10/11/12 16:54, Thiago Farina wrote: >> Just setting CC to gcc works for me. But still, I'd like to be able to >> build with clang (may be as you noted is just something with the + in >> my PATH). > Oh, I just realized you were using "sudo". The PATH environment was > probably not inherited when you use sudo to run "make". So the > subsequent shells statred by "make' were not able to find "clang". Interesting, thank you for your observation. This worked for me now: $ git clone https://github.com/gitster/git $ cd git $ make configure $ ./configure $ make $ ./git version git version 1.8.0.rc2 clang reported this: combine-diff.c:1006:19: warning: adding 'int' to a string does not append to the string [-Wstring-plus-int] prefix = COLONS + offset; ~~~~~~~^~~~~~~~ combine-diff.c:1006:19: note: use array indexing to silence this warning prefix = COLONS + offset; ^ & [ ] 1 warning generated. grep.c:451:16: warning: comparison of unsigned enum expression < 0 is always false [-Wtautological-compare] if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field) ~~~~~~~~ ^ ~ 1 warning generated. ``` ## Michael J Gruber, 2012-10-15 15:44 Subject: Re: build deps Message-ID: <507C2F6E.9060100@drmicha.warpmail.net> URL: https://gitlist.dev/e/507C2F6E.9060100%40drmicha.warpmail.net In-Reply-To: ``` Thiago Farina venit, vidit, dixit 12.10.2012 06:08: > On Thu, Oct 11, 2012 at 10:06 PM, Andrew Wong > wrote: >> On 10/11/12 16:54, Thiago Farina wrote: >>> Just setting CC to gcc works for me. But still, I'd like to be able to >>> build with clang (may be as you noted is just something with the + in >>> my PATH). >> Oh, I just realized you were using "sudo". The PATH environment was >> probably not inherited when you use sudo to run "make". So the >> subsequent shells statred by "make' were not able to find "clang". > > Interesting, thank you for your observation. > > This worked for me now: > > $ git clone https://github.com/gitster/git > $ cd git > $ make configure > $ ./configure > $ make > $ ./git version > git version 1.8.0.rc2 > > clang reported this: > combine-diff.c:1006:19: warning: adding 'int' to a string does not > append to the string [-Wstring-plus-int] > prefix = COLONS + offset; > ~~~~~~~^~~~~~~~ > combine-diff.c:1006:19: note: use array indexing to silence this > warning > prefix = COLONS + offset; > ^ > & [ ] > 1 warning generated. Does &COLONS[offset] silence that? > grep.c:451:16: warning: comparison of unsigned enum expression < 0 is > always false [-Wtautological-compare] > if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field) > ~~~~~~~~ ^ ~ > 1 warning generated. > Right, that enum type starts at 0. Junio, you last touched this area. Can we just dump the first comparison or did you have something else in mind? Michael ``` ## Thiago Farina, 2012-10-15 17:51 Subject: Re: build deps Message-ID: URL: https://gitlist.dev/e/CACnwZYdpuju4VtvRxNDRSTwnCCFYK4j_f%3Dh9eCoLPBWHKF7LsA%40mail.gmail.com In-Reply-To: <507C2F6E.9060100@drmicha.warpmail.net> ``` On Mon, Oct 15, 2012 at 12:44 PM, Michael J Gruber wrote: >> clang reported this: >> combine-diff.c:1006:19: warning: adding 'int' to a string does not >> append to the string [-Wstring-plus-int] >> prefix = COLONS + offset; >> ~~~~~~~^~~~~~~~ >> combine-diff.c:1006:19: note: use array indexing to silence this >> warning >> prefix = COLONS + offset; >> ^ >> & [ ] >> 1 warning generated. > > Does > > &COLONS[offset] > > silence that? > Yes. ``` ## Junio C Hamano, 2012-10-15 20:53 Subject: Re: build deps Message-ID: <7vd30jwj7v.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vd30jwj7v.fsf%40alter.siamese.dyndns.org In-Reply-To: <507C2F6E.9060100@drmicha.warpmail.net> ``` Michael J Gruber writes: >> grep.c:451:16: warning: comparison of unsigned enum expression < 0 is >> always false [-Wtautological-compare] >> if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field) >> ~~~~~~~~ ^ ~ >> 1 warning generated. > > Right, that enum type starts at 0. Junio, you last touched this area. > Can we just dump the first comparison or did you have something else in > mind? I think it was a leftover from the very first implementation that defensively said "this has to be one of these known ones", and tried to bound it from both sides of the range, regaredless of the actual type of the field (these GREP_HEADER_WHAT things may have been simple integers with #define'd values). Dropping the "negative" comparison is perfectly fine. ``` ## David Aguilar, 2012-10-16 01:39 Subject: Re: build deps Message-ID: URL: https://gitlist.dev/e/CAJDDKr5QaByGg0wW_fwFErRyMA6hbg2kHskxOqY4Z_rLoo1maQ%40mail.gmail.com In-Reply-To: <7vd30jwj7v.fsf@alter.siamese.dyndns.org> ``` On Mon, Oct 15, 2012 at 1:53 PM, Junio C Hamano wrote: > Michael J Gruber writes: > >>> grep.c:451:16: warning: comparison of unsigned enum expression < 0 is >>> always false [-Wtautological-compare] >>> if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field) >>> ~~~~~~~~ ^ ~ >>> 1 warning generated. >> >> Right, that enum type starts at 0. Junio, you last touched this area. >> Can we just dump the first comparison or did you have something else in >> mind? > > I think it was a leftover from the very first implementation that > defensively said "this has to be one of these known ones", and tried > to bound it from both sides of the range, regaredless of the actual > type of the field (these GREP_HEADER_WHAT things may have been > simple integers with #define'd values). Dropping the "negative" > comparison is perfectly fine. This snippet of code came up before: http://thread.gmane.org/gmane.comp.version-control.git/184908/focus=185014 There seemed to be good reasons to keep the check at the time. Was this same snippet not also touched when Nguyen Thai Ngoc Duy worked on the "even if I'm drunk" patch?: http://thread.gmane.org/gmane.comp.version-control.git/206413/focus=206539 With the "drunk" patch then we wouldn't need the check at all, which is really nice. I hope that helps jog folks' memories. I'm not sure if the above discussions are relevant anymore, but I figured it'd be good to provide some more context. cheers, -- David ``` ## Michael J Gruber, 2012-10-16 07:37 Subject: Re: build deps Message-ID: <507D0EC5.4030206@drmicha.warpmail.net> URL: https://gitlist.dev/e/507D0EC5.4030206%40drmicha.warpmail.net In-Reply-To: ``` David Aguilar venit, vidit, dixit 16.10.2012 03:39: > On Mon, Oct 15, 2012 at 1:53 PM, Junio C Hamano wrote: >> Michael J Gruber writes: >> >>>> grep.c:451:16: warning: comparison of unsigned enum expression < 0 is >>>> always false [-Wtautological-compare] >>>> if (p->field < 0 || GREP_HEADER_FIELD_MAX <= p->field) >>>> ~~~~~~~~ ^ ~ >>>> 1 warning generated. >>> >>> Right, that enum type starts at 0. Junio, you last touched this area. >>> Can we just dump the first comparison or did you have something else in >>> mind? >> >> I think it was a leftover from the very first implementation that >> defensively said "this has to be one of these known ones", and tried >> to bound it from both sides of the range, regaredless of the actual >> type of the field (these GREP_HEADER_WHAT things may have been >> simple integers with #define'd values). Dropping the "negative" >> comparison is perfectly fine. > > This snippet of code came up before: > > http://thread.gmane.org/gmane.comp.version-control.git/184908/focus=185014 > > There seemed to be good reasons to keep the check at the time. > > Was this same snippet not also touched when Nguyen Thai Ngoc Duy > worked on the "even if I'm drunk" patch?: > > http://thread.gmane.org/gmane.comp.version-control.git/206413/focus=206539 > > With the "drunk" patch then we wouldn't need the check at all, > which is really nice. > > I hope that helps jog folks' memories. > I'm not sure if the above discussions are relevant anymore, > but I figured it'd be good to provide some more context. > > cheers, The drunk patch, cheers ;) That's very valuable context that you are giving. So it's either avoiding the warning and relying and enum unsignedness (or human/static analysis) or playing it safe and keeping the warning. How is if (/* p->field < 0 || */ GREP_HEADER_FIELD_MAX <= p->field) to remind any reader that the first condition should be granted? One could take this further and use a macro but that seems overkill. Michael ```