Thread: Problems updating to 8.3.5
I have a Slackware 10.2.0 machine which has been happily serving files, Apache, Pg, etc. across my home network for some time. I had no problem installing pg 8.2.1 on it. But now when I try to install 8.3.5, configure dies complaining that gcc can't build an executable. Looking at the log, it says crt1.o does not exist. I looked, and sure enough, it doesn't exist. Apart from sounding like a DOS run time package, why does the new version need it while 8.2 didn't? Where do I get or make a copy so I can build the latest engine? Bob McConnell N2SPP
Bob McConnell <rmcconne@lightlink.com> writes: > I have a Slackware 10.2.0 machine which has been happily serving files, > Apache, Pg, etc. across my home network for some time. I had no problem > installing pg 8.2.1 on it. But now when I try to install 8.3.5, > configure dies complaining that gcc can't build an executable. Looking > at the log, it says crt1.o does not exist. I looked, and sure enough, it > doesn't exist. Well, you changed something else on that machine since installing 8.2.1 ... assuming you built 8.2.1 from source there; are you sure you didn't install a prepackaged build? This error says you've got a fundamentally broken or incomplete C compilation environment, and that's not exactly postgres' fault. I don't know how Slackware divvies up this stuff, but you might need to install packages labeled "C development tools" or some such if you want to build PG from source. regards, tom lane
Tom Lane wrote: > Bob McConnell <rmcconne@lightlink.com> writes: >> I have a Slackware 10.2.0 machine which has been happily serving files, >> Apache, Pg, etc. across my home network for some time. I had no problem >> installing pg 8.2.1 on it. But now when I try to install 8.3.5, >> configure dies complaining that gcc can't build an executable. Looking >> at the log, it says crt1.o does not exist. I looked, and sure enough, it >> doesn't exist. > > Well, you changed something else on that machine since installing 8.2.1 > ... assuming you built 8.2.1 from source there; are you sure you didn't > install a prepackaged build? This error says you've got a fundamentally > broken or incomplete C compilation environment, and that's not exactly > postgres' fault. > > I don't know how Slackware divvies up this stuff, but you might need to > install packages labeled "C development tools" or some such if you want > to build PG from source. > > regards, tom lane Hi Tom, I installed 8.2.1 from source,using gcc 3.2.2. I still have the config.log for that, dated Feb 3, 2007. I installed PHP 4.4.0 from source earlier this year, along with Apache 1.3.33. The prepackaged kits for those did not have any of the options I wanted, since the maintainers are hung up on MySQL. That box now has gcc 3.3.6 and GNU make 3.80. I didn't see anything about a minimum version of GCC, etc. in the documents. But was there a library change that requires a newer compiler? I don't like the idea of upgrading that box to a newer version of Slackware, but that's probably the cleanest way to get everything back in sync. It's only a 450 MHz P-II, and rebuilding everything will take all weekend. I also have to remove two of the disk drives and put an optical drive back in. But if I have to, that's probably the next step. Thanks, Bob McConnell N2SPP
Bob McConnell <rmcconne@lightlink.com> writes: > Tom Lane wrote: >> Bob McConnell <rmcconne@lightlink.com> writes: >>> I have a Slackware 10.2.0 machine which has been happily serving files, >>> Apache, Pg, etc. across my home network for some time. I had no problem >>> installing pg 8.2.1 on it. But now when I try to install 8.3.5, >>> configure dies complaining that gcc can't build an executable. Looking >>> at the log, it says crt1.o does not exist. I looked, and sure enough, it >>> doesn't exist. > I installed 8.2.1 from source,using gcc 3.2.2. I still have the > config.log for that, dated Feb 3, 2007. Hmm. Well, something else to ask is whether you're sure you identified the relevant error message in config.log. In some cases errors like that might be expected failures that configure can recover from. regards, tom lane