Bug#654793: firebird2.5: Hardeneng flags not fully enabled
On 01/11/12 12:23, Damyan Ivanov wrote: -=| Alex Peshkoff, 11.01.2012 11:57:55 +0400 |=- On 01/10/12 21:17, Moritz Muehlenhoff wrote: On Tue, Jan 10, 2012 at 11:06:04AM +0200, Damyan Ivanov wrote: - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Most of the binaries suffer from this, and in the end the reason appears to be missing usage of CPPFLAGS when compiling C++ sources. That's correct. I've meant CPPFLAGS. CPreProcessorFLAGS when compiling C++ resources? I always use for it CXXFLAGS, which are taken into an account in firebird makefiles. http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make CPP can pre-process all kinds of sources, C, C++, Fortran... and we want all of them to have that _FORTIFY_SOURCE=2 define. I think this is the reason to put it in CPPFLAGS -- to have it when pre-processing I've added support for CPPFLAGS. Moreover, now I use it internally for regular posix build (http://tracker.firebirdsql.org/browse/CORE-3727). So I hope you should not have problems with _FORTIFY_SOURCE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
On 01/10/12 21:17, Moritz Muehlenhoff wrote: On Tue, Jan 10, 2012 at 11:06:04AM +0200, Damyan Ivanov wrote: - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Most of the binaries suffer from this, and in the end the reason appears to be missing usage of CPPFLAGS when compiling C++ sources. That's correct. I've meant CPPFLAGS. Cheers, Moritz CPreProcessorFLAGS when compiling C++ resources? I always use for it CXXFLAGS, which are taken into an account in firebird makefiles. http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
On 01/11/12 12:23, Damyan Ivanov wrote: -=| Alex Peshkoff, 11.01.2012 11:57:55 +0400 |=- On 01/10/12 21:17, Moritz Muehlenhoff wrote: On Tue, Jan 10, 2012 at 11:06:04AM +0200, Damyan Ivanov wrote: - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Most of the binaries suffer from this, and in the end the reason appears to be missing usage of CPPFLAGS when compiling C++ sources. That's correct. I've meant CPPFLAGS. CPreProcessorFLAGS when compiling C++ resources? I always use for it CXXFLAGS, which are taken into an account in firebird makefiles. http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make CPP can pre-process all kinds of sources, C, C++, Fortran... and we want all of them to have that _FORTIFY_SOURCE=2 define. I think this is the reason to put it in CPPFLAGS -- to have it when pre-processing all source files. As I understand it, CPPFLAGS is now taken into account when compiling plain C sources by pure luck -- the build system relies on the implicit rule for .c - .o compilation in 'make'. And since explicit rules are used for .cpp - .o compilation, CPPFLAGS integration is gone. From https://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Catalogue-of-Rules.html#Catalogue-of-Rules Compiling C programs n.o is made automatically from n.c with a recipe of the form ‘$(CC) $(CPPFLAGS) $(CFLAGS) -c’. Compiling C++ programs n.o is made automatically from n.cc, n.cpp, or n.C with a recipe of the form ‘$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c’. We encourage you to use the suffix ‘.cc’ for C++ source files instead of ‘.C’. Compiling Pascal programs n.o is made automatically from n.p with the recipe ‘$(PC) $(PFLAGS) -c’. Compiling Fortran and Ratfor programs n.o is made automatically from n.r, n.F or n.f by running the Fortran compiler. The precise recipe used is as follows: ‘.f’ ‘$(FC) $(FFLAGS) -c’. ‘.F’ ‘$(FC) $(FFLAGS) $(CPPFLAGS) -c’. ‘.r’ ‘$(FC) $(FFLAGS) $(RFLAGS) -c’. So using CPPFLAGS for C++ sources is the default, not some exotic :) Hopefully this makes the patch integrating CPPFLAGS acceptable. Not completely - but now I can see what do you want. I will fix the build. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626931: [Firebird-devel] [pkg-firebird-general] Bug#626931: Bug#626931: Bug#626931: FTBFS on GNU/Hurd
Hi, Marius! We need a new define for hurd Do you need help in creating prefix.hurd_i386 file? afther we undefine LINUX that part compiles but i hit another issues that i found it to be in haikuos too g++ -I../src/include/gen -I../src/include -I../src/vulcan -DNAMESPACE=Vulcan -gg db -p -Wall -Wno-switch -DLINUX -pipe -MMD -fPIC -DFB_SEND_FLAGS=MSG_NOSIGNAL -D A bit strange that I once again see -DLINUX here. DEV_BUILD -pthread -DBOOT_BUILD -pthread -fno-rtti -c ../src/jrd/os/posix/isc_ip c.cpp -o ../temp/boot/jrd/isc_ipc.o ../src/jrd/os/posix/isc_ipc.cpp: In function 'bool isc_signal2(int, FPTR_VOID, v oid*, ULONG)': ../src/jrd/os/posix/isc_ipc.cpp:187:31: error: 'SA_SIGINFO' was not declared in this scope ../src/jrd/os/posix/isc_ipc.cpp: In function 'void ISC_signal_cancel(int, FPTR_V OID_PTR, void*)': http://mapopa.blogspot.com/2010/06/firebird-database-porting-progress-on.html ps here is one kvm-linux, qemu image that can be used Sorry, now I do not have enough free time to experiment with hurd myself. But will always be glad to help with advice. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
