1. I got the tools to build. Yay!
2. I got past all the annoying trouble with not finding header files. Yay!
Now I'm having problems with this:
llvm-ar rc ./libgcc.a libgcc/./_muldi3.o <and-lots-more-.o-files...>
C:\msys\1.0\home\llvm_home\install\bin\llvm-ar.exe: <invalid>: path is not valid
I'm investigating this with the debugger and so far I've learned that
'<invalid>' seems to be the default constructor for some kind of path
object. I don't know why it's crapping out:
1. I expect it to *create* libgcc.a, so it shouldn't die because it can't
find that.
2. All the *.o files are present and accounted for.
I've tracked this down in the debugger. It is indeed a bug. The problem is
that Path::isValid() will reject a string containing "<" and ">" on
Windows.
Note that this is not the case on Unix -- compare the implementation of
Path::isValid() in .../Unix/Path.inc to the one in .../Win32/Path.inc.
Probably the right place to make the fix is in
ArchiveMember::ArchiveMember() (Archive.cpp circa line 43).
As per the comment this constructor is being used to make a "sentry node"
in an ilist. In the initializations you will see `path("<invalid>")' which
on Windows should be something else (perhaps just use
`path("--invalid--")'.
I'm new to this list should I go ahead and write a bug? Or do you have
enough info here?
From your initial email, I came to the same conclusion that
llvm::sys::Path was generating the "path is not valid" message. The Path
class has platform specific knowledge of what constitutes a valid path
name on that system. Generally it uses an operating system facility to
validate path names. The fact that it declared <invalid> as "not valid"
is correct behavior, Win32 doesn't allow < and > in path names. So, the
problem isn't there.
As you surmised, the real problem is: "why does <invalid> get used as a
path name?" You are probably correct that it is something ArchiveMember
is doing. I'll look into this and see if I can come up with a better
default name or eliminate the <invalid> member altogether.
The constructor for Path validates the path, period. It doesn't know or care whether the path is ever handed to the OS. An invariant for Path dictates that it always has a valid path.
Just to be pedantic about it and so everyone understands, the invariant
is that a Path always has either an empty or a *syntactically* valid
path. The corresponding file or directory does not have to exist.