* QA Notice: Files built without respecting CFLAGS have been detected * Please include the following list of files in your report: * /usr/bin/bsondump * /usr/bin/mongofiles * /usr/bin/mongotop * /usr/bin/mongorestore * /usr/bin/mongoexport * /usr/bin/mongoimport * /usr/bin/mongodump * /usr/bin/mongoreplay * /usr/bin/mongostat
I cannot reproduce, can you please @ultrabug?
Thanks @whissy for pointing this out (https://github.com/gentoo/portage/blob/master/bin/install-qa-check.d/10ignored-flags#L24) https://wiki.gentoo.org/wiki/Package_testing # CFLAGS should be reasonable CFLAGS="-march=native -O2 -pipe -frecord-gcc-switches" CXXFLAGS="${CFLAGS}" # Defining all four *FLAGS variables enables a portage QA check reporting when these variables are not respected FFLAGS="${CFLAGS}" FCFLAGS="${CFLAGS}" emerge =app-admin/mongo-tools-3.6.2: * QA Notice: Files built without respecting CFLAGS have been detected ...
Since mongo-tools is written in Go (cannot find any CGO) imho we cannot pass any CFLAGS to it since they are C specific. Let's see why this message was printed: ++ rm -f /var/tmp/portage/app-admin/mongo-tools-3.6.2-r1/temp/scanelf-ignored-CFLAGS.log +++ scanelf -qyRF '#k%p' -k '!.GCC.command.line' /var/tmp/portage/app-admin/mongo-tools-3.6.2-r1/image/ ++ for x in $(scanelf -qyRF '#k%p' -k '!.GCC.command.line' "${ED}") +++ file usr/bin/mongofiles ++ f='usr/bin/mongofiles: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with ... ++ [[ -f /var/tmp/portage/app-admin/mongo-tools-3.6.2-r1/temp/scanelf-ignored-CFLAGS.log ]] ++ '[' unset = unset ']' ++ sed -e 's#^usr/lib/debug/.*##' -e '/^$/d' -e 's#^#/#' -i /var/tmp/portage/app-admin/mongo-tools-3.6.2-r1/temp/scanelf-ignored-CFLAGS.log ++ [[ -n /usr/bin/mongofiles /usr/bin/mongofiles So the mongo binaries got into the scanelf-ignored-CFLAGS.log because `file` printed "ELF 64-bit LSB shared object". I think this is a false alarm, but I'm free to suggestions how to fix this if it's really a problem. Thank you.
I am not a Go expert. This is the first time that I have seen non-statically linked Go binaries, linked with non-Go libraries: > # file /usr/bin/mongodump > /usr/bin/mongodump: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped > # lddtree /usr/bin/mongodump > /usr/bin/mongodump (interpreter => /lib64/ld-linux-x86-64.so.2) > libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 > libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 > libdl.so.2 => /lib64/libdl.so.2 > libz.so.1 => /lib64/libz.so.1 > libpthread.so.0 => /lib64/libpthread.so.0 > libc.so.6 => /lib64/libc.so.6 I agree that the QA check will produce false-positives on normal Go binaries. I _guess_ that this is happening here as well. However, I don't see this ebuild linked to Go. I.e. a dev-lang/go update won't trigger a rebuild. I think this should be fixed. And while you are there, make the build process verbose.
(In reply to Thomas Deutschmann from comment #4) > However, I don't see this ebuild linked to Go. I.e. a dev-lang/go update > won't trigger a rebuild. I think this should be fixed. We have go in DEPEND (dev-lang/go:=): https://github.com/gentoo/gentoo/blob/master/app-admin/mongo-tools/mongo-tools-3.6.2.ebuild#L20 > And while you are there, make the build process verbose. Good point, I'll look into it, thanks.
Sorry, yes. I mixed RDEPEND/DEPEND.
(In reply to Thomas Deutschmann from comment #6) > Sorry, yes. I mixed RDEPEND/DEPEND. No problem :)
