Re: 7.0.2 on Solaris
От | pgsql-hackers@thewrittenword.com |
---|---|
Тема | Re: 7.0.2 on Solaris |
Дата | |
Msg-id | 200006281919.OAA09088@postal.thewrittenword.com обсуждение исходный текст |
Ответ на | Re: 7.0.2 on Solaris (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Wed, Jun 28, 2000 at 01:56:49AM -0400, Tom Lane wrote: > pgsql-hackers@thewrittenword.com writes: > > 1. I'm curious why src/template/solaris_sparc_cc contains: > > -DDISABLE_COMPLEX_MACRO > > Presumably because the Solaris Sparc compiler was once broken. > Dunno how long ago that was, but I have no objection to removing > the -D switch if it seems to work on not-too-ancient copies. > How recent is your Solaris? We're runnig 5.0 with the latest set of patches. 6.0 just came out but we don't have our copy yet. > > The reason for this is because nocachegetattr becomes a function when > > DISABLE_COMPLEX_MACRO is defined (nocachegetattr is defined in > > src/backend/access/common/heaptuple.c). > > > The first patch below removes this macro from > > src/templates/solaris_sparc_cc. > > It's broken all right, but that's no fix --- it just masks the problem > on your platform. The breakage is that somebody decided a static > function definition in an include file is a cool idea. Not when the > include file is included by non-backend modules ... the non-macro > definition of fastgetattr() needs to be made a plain extern routine. Understood. We took the easy way out. Considering noone else has reported a problem and that 5.0 has been out for awhile (though I imagine some people might still be using 4.2), it should be safe to remove. > > 3. Why is NAN defined in src/include/solaris_i386.h as: > > #define NAN (*(__const double *) __nan) > > #endif /* GCC. */ > > if the compiler is not GCC? The Solaris C compiler does not like this. > > I removed it and the compilation succeeded. > > Hmm, I think this needs more investigation. Removing a definition of > NAN that's inside "#ifndef NAN" cannot cause things to work unless there > is an order dependency with another definition of NAN. Perhaps we need > to be rearranging header includes or some such. Again, it seems like > the true issue might affect more than just solaris. Note that Solaris/SPARC doesn't have this #ifndef NAN stuff. Why be specific to Solaris/Intel? Solaris CC does not have __const so if left in it doesn't compile. The reason the compile succeeds when the #else section is removed is because of the following in src/include/utils/timestamp.h: #ifdef NAN #define DT_INVALID (NAN) #else #define DT_INVALID (DBL_MIN+DBL_MIN) #endif So, DBL_MIN+DBL_MIN is used rather than NAN. Dunno if this is a "good thing". There are other places, like src/backend/utils/adt/numeric.c, that: #ifndef NAN #define NAN (0.0/0.0) #endif Again, I don't know if this is a "good thing" (and if NAN is defined to be this here, why not similarly for src/include/utils/timestamp.h above?). > > 4. I moved some of the information out of > > src/interfaces/libpq++/Makefile.in into src/Makefile.shlib where it > > belongs. Assuming that CXXFLAGS should take on the shared library > > flags for CFLAGS_SL is wrong though. > > Nope, try again. Your change breaks things for all non-C++ shared libs, > because it changes AR and LD to C++-suitable definitions for *all* shlib > modules not just C++ modules. That might happen to work on your > installation but it's a recipe for trouble. The reason that the C++ > info is in src/interfaces/libpq++/Makefile.in is that that's where it > belongs, to avoid messing up non-C++ modules. (If we had more than one > C++ shlib I'd be more excited about figuring out how to keep the info in > Makefile.shlib, but as things stand I think leaving it out is the path > of least resistance.) Ok. I now understand why it was in the Makefile in libpq++. I've attached a patch to add my Makefile.shlib changes to src/interfaces/libpq++/Makefile.in. > > > b) Added --with-readline=DIR to check for readline in DIR. > > What for? We have --with-includes and --with-libs; shall we now > add a custom "--with-libfoo" option for every single library we > depend on? This seems like useless clutter. I think so. Makes it easier when running ./configure to figure out what extra 3rd-party modules are being used. It also means every submodule does not necessary have to -L everything in --with-libs and -I everything in --with-includes. Can you guarantee that this will always be safe? > regards, tom lane -- albert chin (china@thewrittenword.com) -- snip snip --- src/interfaces/libpq++/Makefile.in.orig Tue Jun 20 17:55:36 2000 +++ src/interfaces/libpq++/Makefile.in Wed Jun 28 08:55:30 2000 @@ -39,22 +39,38 @@SHLIB_LINK= $(LIBPQ)endif -# For CC on IRIX, must use CC as linker/archiver of C++ librariesifeq ($(PORTNAME), irix5) + # if archiving or linking C++ objects, must use CC (according to CC(1)) ifeq ($(CXX), CC) - AR = CC - AROPT = -ar -o - LD = CC + AR := CC + AROPT := -ar -o + LD := CC + endif +endif + +ifeq ($(PORTNAME), solaris_i386) + # if archiving or linking C++ objects, must use CC (according to CC(1)) + ifeq ($(CXX), CC) + AR := CC + AROPT := -xar -o + LD := CC + endif +enfi + +ifeq ($(PORTNAME), solaris_sparc) + # if linking C++ objects, must use CC (according to CC(1)) + ifeq ($(CXX), CC) + AR := CC + AROPT := -xar -o + LD := CC endifendif# Shared library stuff, also default 'all' targetinclude $(SRCDIR)/Makefile.shlib - -# Pull shared-lib CFLAGS into CXXFLAGS +# Pull shared-lib CFLAGS into CXXFLAGS CXXFLAGS+= $(CFLAGS_SL) -.PHONY: examplesexamples:
В списке pgsql-hackers по дате отправления:
Предыдущее
От: "Stephan Szabo"Дата:
Сообщение: Re: AW: Proposal: More flexible backup/restore via pg_dump