Looking at the log file, the portion of the file between the Platform tag and the Core tests tag is the configure command trying to determine the nature of machine you are using, and where to look for commands. It's effectively asking, is your machine 32-bit, is it 64-bit, should it look in /bin for commands, should it look in /usr/bin, etc. It then goes on to look for various commands and alternates for them, that it can use to do it's job, like some form of awk.

When it comes to creating a compiler itself, like gcc, there are different types of compilers. There are so called semi-compilers and full compilers. AFAIK, gcc is a semi-compiler, it generally doesn't produce object modules itself directly. Instead it produces assembly language code, and then tries to call the assembler "as" to produce the object modules.

Seemingly it wasn't able to execute the assembler, as indicated by this message:

AFAIK, the "-V" option relates to the version of gcc that is to be run, and together with the "-b" option which relates to the type of machine, determines the specific executable name to be run to do compiling. So this message:

would appear to have been generated because the configure command may not have been able to determine enough about the type of platform on which it was running, as evidenced by all the "unknown" indicators in the Platform section of the log.

For example if run on my machine, either "uname -p" or "arch" will output "x86_64" because the machine uses a CPU that's compatible with a 64-bit Intel *8*6 CPU.

The getsysinfo command exists on my system, but it's not in /usr/convex, instead it's /usr/sbin.

You might want to make sure that you're running as root, since you'll likely need to be to install cups, and you might either need to adjust the path to help configure find the right commands, provide some options to configure, or hard code some values to tell it what to do, for example, about the type of machine you have.

Often there's a "-h" or "--help" on various forms of configure that's a good place to start.

I know that's not very specific. I'll have to think about a bit more to be more specific.

OK. So, installed SLITAZ. Ending up getting the version on the swiss mirror, so this is what was installed:

I also downloaded the packages ISO.

Poked around, installed cups 1.3.10, that seemed to go OK.

Got cups-1.4.3 source from cups site. Looked at the INSTALL.txt file and started from there.

It was tough going at first using the tazpkg text-based command. I happened upon the tazpkgbox GUI with which I made much better progress, much more easily.

In order to follow the instructions in INSTALL.txt, I found I needed to install these packages:

Then I was able to use the autoconf command to generate a new configure command, as seemed to be mentioned in the INSTALL.txt file. The newly generated configure command seemingly ran pretty much OK. I was then able to run the make command to build cups. make did flag some gzipped manual pages with the phrase "unknown", but just the same seemingly uncompressed all the manual pages.

As you have a somewhat different version of SLITAZ, your situation may be somewhat different. But given that various things did appear to be missing in your situation, you might want to give these packages a shot, as far as their general names are concerned. You might get different versions, since your OS version is different. But some of these packages definitely contain some of the things you were missing.

I found myself more than once having to search for a command on which a package logically depended, but which the package manager did not install along with the package I asked it to install. It appears that either the dependencies weren't set in the packages, or the package manager has some bugs. The tazpkgbox GUI seems pretty decent when it comes to searching for things. It may be as with some package management GUI's, that the GUI actually uses the text based command to do the real work. But the presentation and features of the GUI were very helpful just the same!

Cheers.

And about to give up. Which is sad
Too many holes to fill.

I uninstalled gcc 4 and tried to install gcc 3.
What happens? gcc4 is installed. Still no 'as'

We learn something everyday. gcc apparently is described as a "front end" for several compilers.
Can't work out how to get a gcc version which does have a builtin compiler & assembler.

On both Ubuntu OSs this problem doesn't appear. Both churn out an executable.

'uname' on this OS is a symlink to busybox which doesn't provide -p or -X options.

autoconf fails due to a missing depend autom4te which is not in tazpkg packages.

I tried to find your version 2.6 without success.
All I managed to find (on the swiss mirror) was http://mirror.switch.ch/ftp/mirror/slitaz/iso/2.0/
or is this actually V2.6?

First, I am sorry about your frustration, and I'm sorry if I've misunderstood something.

But I thought you started this thread because you were having problems installing cups on SLITAZ.

So in principle, the goal of the thread was to get cups installed on SLITAZ. You solved that problem yourself, when you changed mother boards. You succeeded, you have installed cups on SLITAZ, yes?

Initially when you asked about going to a later version of cups, I thought you were talking about a packaged binary that the SLITAZ folks had already blessed and packaged for use with SLITAZ, and so should install for you without problems.

When you started compiling the source, I thought you were just doing it for fun. I didn't think you needed to do it.

So unless there are features in the newer version of cups that you require, you do not have to install a newer version of cups. Is that correct?

Hopefully you don't need any newer features in the newer version of cups, and you can continue on to other issues. But in case you are going to continue to work with SLITAZ, or if you actually need to continue to try to compile and install the newer version of cups, you might want the other issues you've raised, to be addressed. I'll try to do that step by step.

I've worked with Slackware, SuSE/Novell, RedHat, gentoo, various distros, and AFAIK, it works the same way just about anywhere you find it. But in those other environments, the things on which it logically depends have been installed.

If you're trying to compile a C program, gcc will run:

1) "cpp" the C pre-processor

2) what I referred to as a semi-compiler which will take the output of the C pre-processor and generate assembly language code

3) "as" the assembler to produce object modules from assembly language code

4) "ld" or "ld.so" one of the so called linkage editors, to finally produce an executable file.

If by built-in you mean package "as" with "gcc", some distros may choose to do that. But gcc itself, per se, is a compiler driver, just as you said. "as" is a physically separate program. In that sense, it's not truly built-in to gcc.

This command sequence outputs your kernel version:

When I run it on what I've installed, I get:If you look in the config.log file that you uploaded to this thread, the configure command which you ran to try to build the newer version of cups, displayed this:

So you appear to have a slightly newer version of the kernel than I do. When I mentioned in a previous post that you might need different versions of the packages I loaded to compile the newest version of cups, I said that because I saw that you had a different kernel version.

When I went to download SLITAZ, I tried ibiblio first because I was already familiar with it. But I found that at least one ISO's md5 checksum, computed after download, didn't match the one they had posted. I wondered if the posted md5 was just wrong, perhaps the ISO was OK. Alternatively, I wondered if it was the version you had, and there really was something wrong with the ISO.

I happened to try the swiss mirror next, the md5's matched. I got these four files from the 2.0 directory you mentioned:
So, yes, the ISO names are different than the kernel versions, and that appears to be true on various mirrors. The ISO's just seemed to be labelled with "2.0" in their names.

You may have a different version of the autoconf package. I installed version 2.62.

/usr/bin/autom4te is in that package along with /usr/bin/autoconf. The package also contains files ending in .pm as well as files ending in .m4. They would normally be perl modules and files written to use the m4 macro processor, respectively.

It was my understanding that those files were not just present so someone could examine the source code. tazpkg depends or rdepends run against the autoconf package seems to show no dependencies. Yet when I tried to use autoconf without installing perl and m4, autoconf did not work. So it appeared that both perl and m4 were needed. This seems to confirm that there are definitely either dependencies missing in the packages, or bugs in the package manager commands.

I was using the tazpkgbox command as much as possible. As root, you just enter it at the command prompt and it launches a handy GUI. There's a search tab where you can enter a phrase, then press either Packages or Files, and it will search for either package names containing the phrase, or filenames containing the phrase, inside packages. It was great for tracking down packages on which other packages logically depend, but which seemingly hadn't been listed as dependencies.

I manually found some packages that weren't found on the server configured into tazpkgbox. They were in the packages ISO: packages-2.0.iso. I copied the packages ISO over to the root of the SLITAZ partition before first booting SLITAZ. So after booting I could mount the ISO like this:

to have easy access to the packages it contained, without having to burn a DVD.

I found that the assembler /usr/bin/as was in the binutils packages.

Yes, these posts altogether are a lot of text, but hopefully they answer a lot of questions.

Cheers.

I don't feel the problem with cups is actually resolved since I need cups to run on this mobo.
OK, it runs on another mobo which only indicates some hardware conflict with this mobo but doesn't solve my problem.

I have attempted to install the latest cups from the cups website in the hope that it will resolve this situation.

In doing so it has exposed a weakness in tazpkg packages dependencies which completely brings me to a grinding halt.

Your version seems to work so my next step would be to download V2 and try again.

However. (Isn't there always).. If I cannot get gcc to generate executables then even with cups running I am stumped.
It is essential I have an OS which will compile to binaries.

Ooops! Should have read your posts more carefully.
If the packages.iso have the "as" do they also have the "ld" also?
i.e. are there the necessary programs there to compile to executables (Newb talking)

I may have not done a good job of expressing it, but in message # 32 in this thread, I was trying to say that I got cups to compile, and I listed the packages I had installed to get it to compile. I thought that would solve your problem.

I believe most of them, the tazpkgbox GUI found from the server, for which a URL comes pre-configured into the command. I just searched for them using the search tab. The others I found manually in the package ISO with the tazpkg command.

Thanks, kakaka. It seems it's down to me not absorbing everything you have done.
The answer for me, if I wish to persue Slitaz, is to follow your path.

What puzzles me is two things:
1) Why cups runs on one motherboard but not another. If I begin again using your method is cups still likely to fail?
2) Why there is an obvious difference between installing programs from on-line vs. installing from the iso.

It seems it will take me the best part of a day to reDo-from-start which right now I do not have.

If/when I do have the time I'll come back and report here.

Thank you again for your input and persistence.