Full_Name: Vladim.r &#268;un.t Version: 0.9.22 (lmdb) OS: Linux (NixOS) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.255.168.34) Some parts of the LMDB Makefile hardcode gcc, seemingly unnecessarily. Please apply the following patch or some similar fix. commit 029031a68873bc3784a8561bd8e049efbd34f9d0 (HEAD) Author: Vladim�r Čun�t <vcunat@gmail.com> Date: Sun Apr 1 11:05:31 2018 +0200 make: gcc -> $(CC) diff --git a/libraries/liblmdb/Makefile b/libraries/liblmdb/Makefile index f254511..612484e 100644 --- a/libraries/liblmdb/Makefile +++ b/libraries/liblmdb/Makefile @@ -102,13 +102,13 @@ COV_OBJS=xmdb.o xmidl.o coverage: xmtest for i in mtest*.c [0-9]*.c; do j=`basename \$$i .c`; $(MAKE) $$j.o; \ - gcc -o x$$j $$j.o $(COV_OBJS) -pthread $(COV_FLAGS); \ + $(CC) -o x$$j $$j.o $(COV_OBJS) -pthread $(COV_FLAGS); \ rm -rf testdb; mkdir testdb; ./x$$j; done gcov xmdb.c gcov xmidl.c xmtest: mtest.o xmdb.o xmidl.o - gcc -o xmtest mtest.o xmdb.o xmidl.o -pthread $(COV_FLAGS) + $(CC) -o xmtest mtest.o xmdb.o xmidl.o -pthread $(COV_FLAGS) xmdb.o: mdb.c lmdb.h midl.h $(CC) $(CFLAGS) -fPIC $(CPPFLAGS) -O0 $(COV_FLAGS) -c mdb.c -o $@
vcunat@gmail.com wrote: > Full_Name: Vladim.r &#268;un.t > Version: 0.9.22 (lmdb) > OS: Linux (NixOS) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (178.255.168.34) > > > Some parts of the LMDB Makefile hardcode gcc, seemingly unnecessarily. Please > apply the following patch or some similar fix. The coverage flags have only been tested with gcc. What compiler are you using that also provides code coverage with these flags? > > commit 029031a68873bc3784a8561bd8e049efbd34f9d0 (HEAD) > Author: Vladimír Čunát <vcunat@gmail.com> > Date: Sun Apr 1 11:05:31 2018 +0200 > > make: gcc -> $(CC) > > diff --git a/libraries/liblmdb/Makefile b/libraries/liblmdb/Makefile > index f254511..612484e 100644 > --- a/libraries/liblmdb/Makefile > +++ b/libraries/liblmdb/Makefile > @@ -102,13 +102,13 @@ COV_OBJS=xmdb.o xmidl.o > > coverage: xmtest > for i in mtest*.c [0-9]*.c; do j=`basename \$$i .c`; $(MAKE) $$j.o; \ > - gcc -o x$$j $$j.o $(COV_OBJS) -pthread $(COV_FLAGS); \ > + $(CC) -o x$$j $$j.o $(COV_OBJS) -pthread $(COV_FLAGS); \ > rm -rf testdb; mkdir testdb; ./x$$j; done > gcov xmdb.c > gcov xmidl.c > > xmtest: mtest.o xmdb.o xmidl.o > - gcc -o xmtest mtest.o xmdb.o xmidl.o -pthread $(COV_FLAGS) > + $(CC) -o xmtest mtest.o xmdb.o xmidl.o -pthread $(COV_FLAGS) > > xmdb.o: mdb.c lmdb.h midl.h > $(CC) $(CFLAGS) -fPIC $(CPPFLAGS) -O0 $(COV_FLAGS) -c mdb.c -o $@ > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 04/01/2018 11:53 AM, Howard Chu wrote: > The coverage flags have only been tested with gcc. What compiler are you > using that also provides code coverage with these flags? This is clang on osx, kind of. NixOS.org is packaging lmdb for various "platforms", including osx. And we run `make test` to be more confident about the result. That's what now broke when we attempt lmdb: 0.9.21 -> 0.9.22 - and this patch fixed the build (though I didn't really check anything; I don't really have any osx machine myself). My experience in general is that clang tries to be compatible with gcc.
vcunat@gmail.com wrote: > On 04/01/2018 11:53 AM, Howard Chu wrote: >> The coverage flags have only been tested with gcc. What compiler are you >> using that also provides code coverage with these flags? > > This is clang on osx, kind of. > > NixOS.org is packaging lmdb for various "platforms", including osx. And > we run `make test` to be more confident about the result. That's what > now broke when we attempt lmdb: 0.9.21 -> 0.9.22 - and this patch fixed > the build (though I didn't really check anything; I don't really have > any osx machine myself). > > My experience in general is that clang tries to be compatible with gcc. The rules you patched are only for generating gcov-compatible binaries. They aren't even invoked by "make test" so I don't see why this has any impact on your build at all. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 04/01/2018 12:12 PM, Howard Chu wrote: > The rules you patched are only for generating gcov-compatible binaries. > They aren't even invoked by "make test" so I don't see why this has any > impact on your build at all. > The build looks like this: ... running tests ar rs liblmdb.a mdb.o midl.o gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat make: gcc: Command not found
vcunat@gmail.com wrote: > On 04/01/2018 12:12 PM, Howard Chu wrote: >> The rules you patched are only for generating gcov-compatible binaries. >> They aren't even invoked by "make test" so I don't see why this has any >> impact on your build at all. >> > > The build looks like this: > ... > running tests > ar rs liblmdb.a mdb.o midl.o > gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast > -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat > make: gcc: Command not found What's the actual command line you used to invoke this? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 04/01/2018 12:37 PM, Howard Chu wrote: > vcunat@gmail.com wrote: >> On 04/01/2018 12:12 PM, Howard Chu wrote: >>> The rules you patched are only for generating gcov-compatible binaries. >>> They aren't even invoked by "make test" so I don't see why this has any >>> impact on your build at all. >>> >> >> The build looks like this: >> ... >> running tests >> ar rs liblmdb.a mdb.o midl.o >> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast >> -Wuninitialized mdb_stat.o liblmdb.a -o mdb_stat >> make: gcc: Command not found > > What's the actual command line you used to invoke this? It should be basically `make` before that part and `make test` in the "running tests" part. Some build flags were passed, too. Hmm, weird, I can't see why make decided to do this, and it doesn't happen with Linux+clang locally (I have no direct access to osx now). Maybe I'm just tired ATM. Possibly the full failed build log will shed light on this? https://logs.nix.ci/?key=nixos/nixpkgs.38289&attempt_id=e3767f8e-8c1e-4404-93b1-d23d9fe429ee If you can't see why, I'll try to revisit this weirdness to avoid potential surprises in future.
vcunat@gmail.com wrote: > On 04/01/2018 12:37 PM, Howard Chu wrote: >> vcunat@gmail.com wrote: >>> On 04/01/2018 12:12 PM, Howard Chu wrote: >>>> The rules you patched are only for generating gcov-compatible binaries. >>>> They aren't even invoked by "make test" so I don't see why this has any >>>> impact on your build at all. >>>> >>> >>> The build looks like this: >>> ... >>> running tests >>> ar rs liblmdb.a mdb.o midl.o >>> gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast >>> -Wuninitialized  mdb_stat.o liblmdb.a -o mdb_stat >>> make: gcc: Command not found >> >> What's the actual command line you used to invoke this? > > It should be basically `make` before that part and `make test` in the > "running tests" part. Some build flags were passed, too. > > Hmm, weird, I can't see why make decided to do this, and it doesn't > happen with Linux+clang locally (I have no direct access to osx now). > Maybe I'm just tired ATM. Possibly the full failed build log will shed > light on this? > https://logs.nix.ci/?key=nixos/nixpkgs.38289&attempt_id=e3767f8e-8c1e-4404-93b1-d23d9fe429ee > > If you can't see why, I'll try to revisit this weirdness to avoid > potential surprises in future. The log doesn't show the actual command invocations. Most likely your "make test" isn't setting CC=gcc. It's probably also doing something else weird since it's building liblmdb.a twice. Regardless, there is no bug in the LMDB Makefile, your build invocations are broken. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed state Open to Closed