[gccsdk] [Bug 229] GCC 4.1.2 Release 2 Dev: glob() ignores files with hardspace.

2012-04-27 Thread bugzilla-daemon
http://www.riscos.info/bugzilla3/show_bug.cgi?id=229

--- Comment #2 from Duncan Moore duncan_mo...@ntlworld.com 2012-04-27 
03:47:34 PDT ---
What I wrote was ambiguous. Just to make clear, the hardspace was in the
filenames of files in the current directory, not in the directory name itself.

So for these 3 files in a directory:

m m   This has a hardspace in the middle
mem
mém   This has an e acute in the middle

With 4.1.2 Release 2 Development, the test program gives:

*test
err = 0
file_list-gl_pathc = 1
0 mem

This does not happen with gcc 4.1.2 Release 1 Dev of Jan 2011 (NB this is the
version dated Jan 2011, not the Mar 2012 version with the same name!). This
gives:

*test
err = 0
file_list-gl_pathc = 3
0 mem
1 m m
2 mém

Exactly the same happens on all of HostFS, RAM, Mem (!Memphis), ArcFS and CDFS
i.e. current version fails, older versions work.

-- 
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all bug changes.
___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

[gccsdk] [Bug 230] New: Attempting to compile some C files produces internal compiler error: Unknown signal

2012-04-27 Thread bugzilla-daemon
http://www.riscos.info/bugzilla3/show_bug.cgi?id=230

   Summary: Attempting to compile some C files produces internal
compiler error: Unknown signal
   Product: GCC/GCCSDK
   Version: other
  Platform: Other
OS/Version: RISC OS
Status: NEW
  Severity: major
  Priority: P1
 Component: C compiler
AssignedTo: john.tyt...@aaug.net
ReportedBy: bel...@internode.on.net
   Estimated Hours: 0.0


Created attachment 82
  -- http://www.riscos.info/bugzilla3/attachment.cgi?id=82
Zip archive containing Taskwindow output and preprocessed source

This fault was found with GCCSDK GCC 4.6.4 Release 1 Development version 4.6.4
20120423 (prerelease) running on Iyonix and BeagleBoard with RISC OS 5.18.

As per the crash report, the attached zip archive contains Taskwindow output
and a preprocessed source that produced the fault. If a file produces the
fault, it does so consistently. I have not found a work-around.

-- 
Configure bugmail: http://www.riscos.info/bugzilla3/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching all bug changes.

___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK


[gccsdk] Choices$Write, dotfiles, ~, ~/

2012-04-27 Thread Ron
Referring to gcc4/recipe/files/gcc/libunix/pwd/pwdread.c
The default for setting the home directory

home = getenv(Choices$Write);

returns Boot:Choices which then forces the following unix style
dotfile path to be issued as a RISC OS path (no good)

I am using the following in pwdread as a functional equivalent for
the intended path. It has to know the drive booted from so that if
the csd is changed to another HD it wont try to use that instead.

/* If not, try Boot$Dir to get the booted HD name and zero the
$ so the unix pathname of Choices can be appended */ 
if (!home)
   home = getenv(Boot$Dir);
if (strtok(home, $) != 0)
strcat(home, $/!Boot/Choices);

This compiles and works, but I welcome corrections.

While on this topic, I'll suggest the possibility that maybe we
could use a subdir in Choices to accommodate the numerous dotfiles
that could clutter the Choices directory.

In the linux world they seem to be referred to as dotfiles so 
perhaps that would be a suitable name for the subdir.

I think most setting files are dotfiles or dotdirs with dotfiles,
but it would mean anything else directed to ~ would be directed to 
Choices/dotfiles also.

I think there are people using !UnixHome as a means but I thought
a while ago I read it was to be avoided in the future?
But secondly, using a default, allows ports like Bash and OpenSSH
to work out of the box seamlessly. 

This is a different subject really, changes do not necessarily
affect each other.
I have noticed that my 10.04 distro does not recognise cd ~
but requires cd ~/ 
Bash on RISC OS is happy with cd ~ (1) so Iam guessing that Ubuntu
and maybe others adapt a modifier so that ~/ must be used to 
get to the home directory contrary to other policy.

(1) Even though I have made this change to my Recipe's riscosify.c

 if (in[0] == '~'  in[1] == '/')
 {
char new_buffer[MAXPATHLEN];
const char *home =
#ifdef __TARGET_SCL__
  getenv (UnixEnv$HOME) ? : getenv (HOME);
#else
  __pwddefault ()-pw_dir;
#endif
strcpy (new_buffer, home);

do
  {
in++;
  }
while (*in != '\0'  *in != '/');

if (new_buffer[0] != '~')
  {
strcat (new_buffer, in);
return __riscosify (new_buffer, create_dir, flags, buffer,
buf_len, filetype);
  }
}
  
  /* Fall through */
  /* We can tell quite a lot from the first character of the path */
  switch (*in)
{
case '/':
  /* The directory separator must be a slash. Could be an absolute unix
 pathname, or a unixified RISC OS path.

I have taken ~ out of the case function and added the requirement of ~/

I did this because there are existing RISC OS filenames ~xxx and
when a program like Tar encounters them they jump to the home dir, but it
may be in line with Ubuntu or Debian anyway.

The combination of my changes are working properly so far, perhaps 
someone else could test it further and it could be implemented? 

Thanks to all,
Ron M.

___
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK