Configure scripts keep looking for a "config.h:" volume

[Hypexed]

I've found that when running a ./configure script under OS4.1 it keeps getting confused by Unix paths and this time it keeps trying to write to a config.h: volume. I've updated my make, clib and abc-shell just now. No change. Running in abc-shell doesnt seem to help much. For some reason when I attempt to assign the volume it never works and it keeps asking for the same volume again. OS4 has had this assign issue for years. Here's an excerp from the log:

creating ./config.status
creating Makefile
creating config.h:config.in
bin:cat: ./config.h: No such file or directory
bin:rm: cannot lstat `config.h:config.in': Device not configured
bin:mv: cannot stat `config.h:config.in': Device not configured

[sba1]

Guess it is related to #33. We probably should switch back to clib2.

[Hypexed]

Yes it would be related to #33 since that is the issue I'm posting in right now. LOL.:-D

I've read in ABC shell sources checks for Newlib but not sure how well they perform.

After some research I found what should be happening. The configure code is making a link. What should happen is creating a link named config.h pointing to config.in. According to this: https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Configuration-Links.html

So what ever is meant to be creating the link is broken. It is passed to a few commands. But nothing looks like it is scanning for this colon or the colon is confusing a path parser into thinking it is an Amiga path.

[broadblues]

sba1 means issue #32

Ignore the fact that abc-shell has src references to newlib, they are never built in production versions.

Sorry to say but your research is not correct, config.h is not generated by linking to config.in but by processing config.in from config.status and performing variable substitution (using the result of the configuring process) .

In order to work out what the error really is could you post a link to the project src code you were configuring? And perhaps attach your resultant config.status ?

[broadblues]

This is the part of the autoconf manual you were looking for

https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Configuration-Files.html#Configuration-Files

I'm guess the issue is with which ever command is parsing the file:src expression, best guess for that would be sed or awk , but can say for certain without seeing script src.

[Hypexed]

Damn it I typed too soon. That's what happens when you don't have the file in front of you. So in fact what it is meant to do when given a "config.h:config.in" is open one or the other in case of override . Because DOS has a problem with the standard file names. What sets this override I don't know but isolating the file names is what we need. :-)

This is what I was looking for: https://www.gnu.org/software/autoconf/manual/autoconf-2.60/html_node/Configuration-Headers.html#Configuration-Headers

However in the form I have it using CONFIG_HEADERS it is obsolete: https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Obsolete-config_002estatus-Use.html

So the source is here: ftp://ftp.gnu.org/pub/gnu/gdb/gdb-5.3.tar.gz

Using an OS4 patch from here: http://os4depot.net/index.php?function=showfile&file=development/debug/gdb-5.3.patch.bz2

I'm afraid the config.status doesn't go far:

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
../gdb-5.3/configure --host=ppc-amigaos --target=ppc-amigaos --norecursion 
#