Unresolved issues with configure scripts remain

[Hypexed]

Hello. I'm not sure if this relates to only abcsh or includes other components but the following issues remain whenever I run a configure script:

1. Cannot deal with spaces on path names. Simple test is to work from the "RAM Disk" which it cannot handle because of the spaces. This causes problems with path substitution.
2. Even without spaces in path, path substitution still breaks. Indicated buy a failed if "[" construct.
3. Fails to locate obvious files like a "Makefile.in" which exists.
4. Cannot create "dual" files. It's common for a configure script to create a "config.h:config". This will cause it to look for a "config.h:" device because of the colon.

This is a show stopper when trying to port software to OS4. Including software already ported. For example GDB patched for OS4 always breaks but I am unable to cross compile as that breaks as well so for me this is a total showstopper.

[broadblues]

Hello Hypexed

On 03/01/2022, you wrote: Hello. I'm not sure if this relates to only abcsh or includes other components but the following issues remain whenever I run a configure script: 1. Cannot deal with spaces on path names. Simple test is to work from the "RAM Disk" which it cannot handle because of the spaces. This causes problems with path substitution.

Generally issues like this a script specific, you will need to provide a spcific example that fails. But the easiest work arround is to not put spaces in file names. Never run configure from RAM:

2. Even without spaces in path, path substitution still breaks. Indicated buy a failed if "[" construct.

"Path substituition" is likely done by a sub command such as sed or awk. Investigate your script and determine which command did not create the right substitutions 3. Fails to locate obvious files like a "Makefile.in" which

exists.

Never had a configure fail to find standard files when run from the right directory, could be a consequance of either 1 or 2 though. 4. Cannot create "dual" files. It's common for a configure

script to create a "config.h:config". This will cause it to look for a "config,h:" device because of the colon.

This will never work on AmigaOS, you will need to edit your script accordingly.

This is a show stopper when trying to port software to OS4. Including software already ported. For example GDB patched for OS4 always breaks but I am unable to cross compile as that breaks as well so for me this is a total showstopper.

Configure scripts are not all created equal, some have os specific checks (the perl one is very extensive in that regard) some expect everythng to be 100% posix, you will need to study and edit the failure points, then find the code fragments that are actually broken and raise bug reports about them. Somethings to start with: 1. Always run configure from the abc-shell prompt, never from the AmigaOS shell 2. Make sure your coreutils are built with clib2 not newlib (newlib has issues with path quoting amongst other things, they are not bugs as such just differences to the posic expectation) 3. Same goes for sed and awk ( you might need to keep more than one version arround).

[Hypexed]

Thanks for replying.

Generally issues like this a script specific, you will need to provide a spcific example that fails. But the easiest work arround is to not put spaces in file names. Never run configure from RAM:

I was running it from RAM as I didn't want to wear my HDD out. And it is slower than an SSD. Plus RAM is the Amiga way.

"Path substituition" is likely done by a sub command such as sed or awk. Investigate your script and determine which command did not create the right substitutions

I collected some logs but can't find the one that showed up. It was unusual as the command interpreter gave the error in the console output. It was related to an if test. Unconfirmed but possible it was a bashism. If abc-shell is POSIX compliant then a bash script can break and I've seen it happen on Linux as bashisms are not exactly POSIX.

Never had a configure fail to find standard files when run from the right directory, could be a consequance of either 1 or 2 though.

It was unexpected. Common file that did exist. Some logging here:

A:

10.Development:Ports/gdb-build/gdb-5.3> sh configure 
Configuring for a ppc-unknown-amigaos host.
*** This configuration is not supported in the following subdirectories:
     readline
    (Any other directories should still work fine.)
No Makefile.in found in ./., unable to configure

B:

+ [ -f ././Makefile.in ]
+ echo No Makefile.in found in ./., unable to configure
+ >&2 
No Makefile.in found in ./., unable to configure

This may relate to being in one build folder and needing to run configure from another. In the case of GDB. I've seen this with CMake where the build is separate from the config.

This will never work on AmigaOS, you will need to edit your script accordingly.

That would be too much work. One script calls another and then it descends down into all the folders. But I don't think it relates to AmigaOS directly but in the script interpreter. The config.h is built using config.in and the two are stored in a variable as "config.h:config.in". It then uses wildcards to separate them including wildstars but this is failing to work for some reason. It shouldn't be relying on AmigaDOS wildstar being active as it should be processing it internally but now it makes me wonder as I have it turned off.

Configure scripts are not all created equal, some have os specific checks (the perl one is very extensive in that regard) some expect everythng to be 100% posix, you will need to study and edit the failure points, then find the code fragments that are actually broken and raise bug reports about them.

For the most part it does work. It just the edge cases above it gets stuck on. And the old "rm -r" bug is also present. It cannot remove existing folders. And mkdir then fails on a folder that exists.I should note that I can actually cross configure in Linux but it fails to compile. I'm used to patching old 32-bit sources to compile on a modern x64 Linux build and did the same with some DLink firmware I was customizing recently. But so far didn't find what stops it building. I also copied the Makefile configuration to AmigaOS to work around the configure problem but that eventually breaks. :-)

Somethings to start with: 1. Always run configure from the abc-shell prompt, never from the AmigaOS shell 2. Make sure your coreutils are built with clib2 not newlib (newlib has issues with path quoting amongst other things, they are not bugs as such just differences to the posic expectation) 3. Same goes for sed and awk ( you might need to keep more than one version arround).

I'm starting to think we need a proper POSIX terminal application. While abc-shell is useful for executing scripts it has limitations and always running under an Amiga shell may prevent it from working as intended. I first tested a fresh SDK 53.34 install. But when I found the included coreutils were old replaced them with the one from OS4Depot and abc-shell as well.

[Hypexed]

gdb-5.3.tar.gz

So here is what I'm trying to build. This is GDB 5.3 with OS4 patches from OS4Depot. Ready to be configured.

For some reason Github looks like it lacks CSS in Odyssey, so needs latest HTML to look normal, but it only accepts old fashioned zip and gz archives. :-?