Hi,
Has some one committed these patches into CVS?
Paolo, thanks for the patches. In the near future I'll try to compile them.
I've installed STLport 6.4.2 with vc6.
Henrik
I don't think these patches have been applied yet. They are out of my
area so I passed them on to Chris. Chris has a huge email backlog to get
through after his vacation. He'll get to it eventually.
Reid.
Hi,
Has some one committed these patches into CVS?
Not yet... checked 10 minutes ago...
I'm attaching the cvs diff -u version of them (I've read Reid Spencer post about it)
Paolo, thanks for the patches. In the near future I'll try to compile them.
I've installed STLport 6.4.2 with vc6.
May I suggest you to use a newer version of the compiler? VC6 is not so compliant to the C++ standard as VC7 and above.
You can also download for free a version of VC.NET 2005 beta, as I've noted that in LLVM code there's a reference to its runtime library, meaning that someone else has worked with it over LLVM...
<gossip> I've read that an MSIL front-end for LLVM is being developed... </gossip>
diffs.txt (21.5 KB)
> Hi,
>
> Has some one committed these patches into CVS?Not yet... checked 10 minutes ago...
Hopefully Chris will get to it today (Wednesday).
I'm attaching the cvs diff -u version of them (I've read Reid Spencer
post about it)
Thanks!
> Paolo, thanks for the patches. In the near future I'll try to compile
> them.
>
> I've installed STLport 6.4.2 with vc6.May I suggest you to use a newer version of the compiler? VC6 is not
so compliant to the C++ standard as VC7 and above.
You can also download for free a version of VC.NET 2005 beta, as I've
noted that in LLVM code there's a reference to its runtime library,
meaning that someone else has worked with it over LLVM...
Yes, in fact I'd be daring enough to suggest that it be the standard.
We'll have fewer compilation problems with VC++ 2005 because it is
(supposedly) more standards compliant than previous versions. Please use
this download:
http://lab.msdn.microsoft.com/express/visualc/default.aspx
There is also an update, as of 9/10/2004:
This is the compiler I will use for the Win32 port (when I get to it).
<gossip> I've read that an MSIL front-end for LLVM is being
developed... </gossip>
This was started by Chris while he was at MS but the work he did there
is proprietary to MS. So, you won't see that happen any time soon.
However, Chris was able to determine that doing an MSIL->LLVM translator
shouldn't be difficult.
Reid
While this may be true, it's not a realistic request. Even among
commercial developers with MSDN subscriptions, it is common to delay
upgrading to the lastest VC++ for a year or two or even three. I've
personally been involved with two such upgrades, from 5 to 6 and 6 to
7.1 and it's a pain. The project files are not converted correctly.
Code that compiled before no longer does. Code that does compile no
longer runs correctly. You depend on some third-party library that
hasn't itself upgraded to the latest VC++ (still a problem with 7.1).
And don't even think of doing this near the end of a release cycle for
your product. The mere thought of using a /beta/ version of a Microsoft
product...
And for those without an MSDN subscription, the cost of purchasing the
latest Visual Studio is enough disincentive.
If the LLVM code base doesn't want to compile with VC++ 6 because it's
not sufficiently ANSI compliant, that's a good enough reason to not
support it. I know that template support wasn't very compliant with 6
(though still better than most non-g++ Unix compilers even today) and
LLVM uses templates a lot. While 6 is still common, by now most are
switching to 7.1. As it seems to work well enough with 7.1, I don't
think standardizing on an unreleased version that won't become dominant
for four years or so is constructive. And that assumes it actually
ships in 2005 
I agree to some extent. Basically it depends on how close 7.1 is to
compiling the LLVM tree today. If supporting 7.1 will require making lots
of ugly changes to the source base to support 7.1 (due to lack of
compliance with the C++ standard), then it may be reasonable to require
8.0 if it fixes the problems. If there are only minor things that 7.1
gets wrong, and they aren't very invasive, I agree that it would be
wonderful to support it.
-Chris
I agree. I think that 7.1 is the right way to go, I suggested 8 only because right now It's possible to download it freely from MS, and I think that is not soo different from 7.1
> Yes, in fact I'd be daring enough to suggest that it be the standard.
> We'll have fewer compilation problems with VC++ 2005 because it is
> (supposedly) more standards compliant than previous versions. Please use
> this download:While this may be true, it's not a realistic request. Even among
commercial developers with MSDN subscriptions, it is common to delay
upgrading to the lastest VC++ for a year or two or even three.
This doesn't affect LLVm because nobody ever tried compiling this with
older VC++ versions. I'm advocating the latest so that we have fewer
"upgrade" problems going forward.
I've
personally been involved with two such upgrades, from 5 to 6 and 6 to
7.1 and it's a pain.
I sympathize, that's why I'm trying to push the compiler version as far
forward as possible to avoid pain later on.
The project files are not converted correctly.
We won't use VC++ project files. You'll still have to compile with
cygwin tools. There's just too many other dependencies (flex, bison,
awk, sed, grep, gmake) ..
Code that compiled before no longer does. Code that does compile no
longer runs correctly. You depend on some third-party library that
hasn't itself upgraded to the latest VC++ (still a problem with 7.1).
Again, while I can sympathize, this problem doesn't affect LLVM because
we have no legacy of compiling on Win32.
And don't even think of doing this near the end of a release cycle for
your product. The mere thought of using a /beta/ version of a Microsoft
product...
Yes, this is more of a concern to me. That's why I suggested using the
update as well. While we'll be bleeding edge for a while, eventually
VC++ 8 will be released and its SP1 will make it actually work
correctly. If we start adjusting for its quirks now, we can (hopefully)
have something reasonably stable by the time lots of Win32 people start
using LLVM.
And for those without an MSDN subscription, the cost of purchasing the
latest Visual Studio is enough disincentive.
Another reason why I suggested the free download alternative ;>
If the LLVM code base doesn't want to compile with VC++ 6 because it's
not sufficiently ANSI compliant, that's a good enough reason to not
support it.
That's exactly the reason.
I know that template support wasn't very compliant with 6
(though still better than most non-g++ Unix compilers even today) and
LLVM uses templates a lot. While 6 is still common, by now most are
switching to 7.1. As it seems to work well enough with 7.1, I don't
think standardizing on an unreleased version that won't become dominant
for four years or so is constructive. And that assumes it actually
ships in 2005
I agree there's some risk and I think we should make our attempt to have
it compile with VC++ 7.1 (thanks Paolo!). However, LLVM requires a
standards compliant compiler. If 7.1 isn't up to the task, then we can't
use it. So far, the changes needed in LLVM have been minor so it hasn't
been a problem. However, we're not going to bastardize the code base
just to support a compiler that isn't up to snuff.
I think you're right that "standardization" on the VC 8 compiler is
somewhat risky. We should continue the 7.1 effort while also using
8(beta) and when 8 is ready, then it should become the standard for
windows (assuming it actually implements the C++ standard correctly!)
Reid.
Paolo, et.al.
Chris gave the green light. All the patches have been committed. Thanks!
Reid.
Again, while I can sympathize, this problem doesn't affect LLVM because
we have no legacy of compiling on Win32.
Well, these were reasons why it takes so long for newer versions to
catch on. Obviously they don't apply to LLVM. Yet
> And don't even think of doing this near the end of a release cycle for
> your product. The mere thought of using a /beta/ version of a Microsoft
> product...Yes, this is more of a concern to me. That's why I suggested using the
update as well. While we'll be bleeding edge for a while, eventually
VC++ 8 will be released and its SP1 will make it actually work
correctly. If we start adjusting for its quirks now, we can (hopefully)
have something reasonably stable by the time lots of Win32 people start
using LLVM.
Just make sure you read the uninstall instructions before installing.
Microsoft has been known to essentially require the reformatting your
boot partition in order to uninstall beta versions of VS. And, of
course, it is required that you uninstall the beta before installing a
newer beta or the release version.
> And for those without an MSDN subscription, the cost of purchasing the
> latest Visual Studio is enough disincentive.Another reason why I suggested the free download alternative ;>
It's only free until enough bugs have been fixed to justify charging for it
I think you're right that "standardization" on the VC 8 compiler is
somewhat risky. We should continue the 7.1 effort while also using
8(beta) and when 8 is ready, then it should become the standard for
windows (assuming it actually implements the C++ standard correctly!)
It all depends on how well it works with 7.1. Hopefully it won't be
much longer before we know for sure.
Just make sure you read the uninstall instructions before installing.
Microsoft has been known to essentially require the reformatting your
boot partition in order to uninstall beta versions of VS. And, of
course, it is required that you uninstall the beta before installing a
newer beta or the release version.
Urrggg! I missed this! Can you point me to that?
Anyway, on Microsoft side, basically you HAVE to reinstall Windows every 150gg as it starts collapsing ;-)))
I think you're right that "standardization" on the VC 8 compiler is
somewhat risky. We should continue the 7.1 effort while also using
8(beta) and when 8 is ready, then it should become the standard for
windows (assuming it actually implements the C++ standard correctly!)It all depends on how well it works with 7.1. Hopefully it won't be
much longer before we know for sure.
Well, right now I've compiled the core with both, and the problems are exactly the sames...
I think that the big difference in ANSI compliance was between 6 and 7 (keep an eye on boost regression...) MS effort in serie 8 is targeted to performance (exploiting better custom instruction for different i386 processor) and on the .NET side...
I don't expect any issue resolved upgrading from 7.1 to 8.
BTW, if you want, tomorrow can post what is failing to compile with VC 7.1 and why... it's not too much.
I cannot find any specific instructions for uninstalling the VC++ 2005
Express Edition. There is this README file:
http://lab.msdn.microsoft.com/express/visualc/readme/default.aspx. As
it isn't the full Visual Studio it probably isn't messing around with
Windows system files.
I do know for a fact that the Visual Studio .NET beta years ago could
not be uninstalled without reformatting. It stopped me from installing
it.
I'm a little optimistic about this issue then... The README file states about problems uninstalling it on 64-bit platform, and it mentions several little problems related to the uninstall process..
but they are little glitches so I'm expecting the uninstall process is not so bad! At least it seems they have tested it! 
Oh, and the recent update warns that it isn't even beta quality.