configure failure using devx_217.sfs

[swarnick]

I downloaded devx_217.sfs, placed it in /mnt/home, used the boot manager to load it.
All seemed to have gone well. The checksums match so I know I have a good download.

I see gcc, I can get the version, I can even compiile hello world. However, when I try to compile large projects that require ./configure, I always get a failure. The error says that the preprocessor isn´t sane.configure: creating cache
Here is the output from ./configure I am trying to compile vim 7.1 after expanding the tarball.

auto/config.cache
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... /lib/cpp
configure: error: C preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

I don't see stdio.h on the hard drive either. That is, if I say
cd /
find . -name stdio.h
I get versions from my windows disk, but I don't see stdio.h where I expect it, which is in
/usr/include

I think there are some of the wierd files around which are preventing gcc from seeing the libraries. It does find things in stdio.h because I can use puts and printf without trouble.

This trouble seems to have started with 2.16. I upgraded from 2.10 but I couln't get the migration to work so I made a new pup_save.2fs for the 2.16 installation. The upgrade to 2.16 to 2.17 went smoothly. However, devx_216.sfs under 2.16 and devx_217.sfs under 2.17 both exhibit the problem described above.

BTW, ALL of the problems I had with booting on this machine under 2.10 (hanging during "loading kernal modules" all just went away under 2.16. Great job, team! Now if I can only get gcc working I can happily give Bill Gates the boot. (I need to be able to compile the kernel to use the cisco vpn client under Linux. Right now that's the only reason I still boot WinXP.)

[John Doe]

I've had this behaviour before and found that deleting my save file and starting over fixed the problem.

Sorry I can't say exactly what it is, for a less drastic fix.

[hushpuppy]

I had a very similar problem, and it took me ages to figure it out, but eventually i did.

It's (probably) a problem with the squash file system, but theres an easy fix.

Reboot and enter this "puppy pfix=purge" when puppy pauses for a few seconds.

Backup your current pup_save file, and i always backup the files that purge places in the /tmp directory. All will become clear when you run the command.
If this works, please report back here, might help other users .

[John Doe]

thanks hushpuppy.

i'll try to remember to try 'purge' should i ever run across that again.

always good to find a more subtle solution.

[hushpuppy]

No problem.

It is a bit drastic as you can lose some settings (alsamixer is one) thats why i keep the temporary files (anything overwritten or deleted is saved in a directory under /tmp) for a while.

Not as drastic as having to create a save file from scratch though.

[Dougal]

If you have the file /initrd/pup_rw/usr/include/.wh.dir_opaque (or somethng like that) then it's the cause. (if you're using flash media it will be in /initrd/pup_ro1)

[muggins]

i've just booted into my 2.17 partition & stdio.h is definitely there, so either you're devx-217.sfs was corrupted, or those dreaded invisible opaque .wh files have gazumped your devx.

[swarnick]

I tried dougal''s trick with the dreaded .wh* file. Deleted the file he mentioned made stdio.h visible but configure sitll failed in the same way. I desparied of finding all of the masking files so I did the pfix=purge reboot. It was actually pretty painless. I lots some new icons from the desktop but the binaries were still there.

The compiler is doing a lot better now but I'm still not home free. I now get a message about a missing terminal library when I try to configure for a vim compile.

checking whether stack_t has an ss_base field... no
checking --with-tlib argument... empty: automatic terminal library selection
checking for tgetent in -lncurses... no
checking for tgetent in -ltermlib... no
checking for tgetent in -ltermcap... no
checking for tgetent in -lcurses... no
no terminal library found
checking for tgetent()... configure: error: NOT FOUND!
You need to install a terminal library; for example ncurses.
Or specify the name of the library with --with-tlib.
# which ncurses
# find / -name ncurses

I think ncurses has to be in puppy so this must be a problem with the vim tarball or the vim configuration file. Either that or ncurses may be obscured by a dreaded wh file.

Actually I'm all but sure the compiler is working because I did a make all and compiled all of the c files in vim. It won t link yet, but that could be the ncurses problem giving unresolvable dependencies.

Thanks to all who responded for the help so far.
I am going to try compiling something simpler (probably jed) and see if that will work.

[muggins]

i think the libncurses thing is a different situation to the .wh files problem. you should have libncurses.so.5.4 in /lib directory. since the program is looking for these in /usr/lib, just try symlinking these to libncurses.so.5.4

Code: Select all

ln -s /lib/libncurses.so.5.4 /usr/lib/libncurses.so
ln -s /lib/libncurses.so.5.4 /usr/lib/libcurses.so
ln -s /lib/libncurses.so.5.4 /usr/lib/libtermcap.so

that's what i had to do to get some older program, that needed libtermcap, to compile.

[Dougal]

I think ncurses has to be in puppy so this must be a problem with the vim tarball or the vim configuration file. Either that or ncurses may be obscured by a dreaded wh file.

I compiled Vim-7.0 a couple of weeks ago and it compiled fine (except for when I tried to compile it with ctl and perl support).

I think Muggins' solution might be what you need -- I remember having to do something similar a long time ago.

[swarnick]

I rebooted a couple of times after the pfix=purge boot and the ncurses problem went away. I should have rebooted before posting in the first place; apologies to those I dithered by asking the question prematurely.

Anyhow, I built vim and jed and they run OK. I'm not sure how, because I got a segmentation fault from ld during the make (for both) but I think that's showing up because of my machine's configuration and not due to anything amiss with puppy 2.17 or devx_217.sfs. Even though a segmentation fault was logged, ld seems to have produced good binaries for vim, jed and slang. Vim and jed run and other programs run after they complete so the memory allocation chain isn't adversely effected by running them. Strange; strange enough to keep me from trying to package up vim or jed as a dotpup until I get to the bottom of it.

For now I am just going to watch future C++ builds and see what happens. I have vim and jed now so my life is good (although I'm constrained from improving the lives of others for a little while).

Many thanks to all who helped.