Missing pcre and tinyxml in CVS?
Moderators: CEGUI MVP, CEGUI Team
Missing pcre and tinyxml in CVS?
Just tried to update to the latest CVS.
src/pcre and src/tinyxml are expected to be there by the MSVC++ project files, but they don't seem to be checked in.
src/pcre and src/tinyxml are expected to be there by the MSVC++ project files, but they don't seem to be checked in.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Yes, this is related to some recent changes I have been making. Basically the core idea was to remove the 'embedded' copies of certain libraries and link to them externally instead.
Additionally, the xml parsers now exist as external modules (and we have more of them).
This work is 99.9% completed for linux systems. For MSVC++ users, I have to update the project files and issue updated dependency packages - this will likely be done over the weekend, so watch this space.
CE.
Additionally, the xml parsers now exist as external modules (and we have more of them).
This work is 99.9% completed for linux systems. For MSVC++ users, I have to update the project files and issue updated dependency packages - this will likely be done over the weekend, so watch this space.
CE.
CrazyEddie wrote:Yes, this is related to some recent changes I have been making. Basically the core idea was to remove the 'embedded' copies of certain libraries and link to them externally instead.
Ok. No problem. I'm not in a hurry, just trying to get back into the swing of things again. Looking forward to the changes.
By the way, the version of PCRE that was in the MSVC project files seems like it might be old. At least I downloaded the most recent version I could find, which was 6.4, but some of the files looked like the names had changed from the ones in the MSVC project file. Can't remember exactly, but e.g. there was no "charencoding.c" but instead a "pcre_charcoding.c" or something like that.
Thanks for the quick answer.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Hi,
Yeah the pcre version we had embedded was old, and this was one of the motivating factors in making it an external dependency; it's much easier to just link to an updated external lib rather than having to update build systems each time a package is updated (it also allows the use of customised versions of the dependency if the user requires that, and so on).
The MSVC++ build has been updated now. There are some issues with the Lua bindings not compiling, but everything else is now working again. You will need the updated commom dependency package for Win32 - I have uploaded a 'beta' version which can be downloaded here.
HTH
CE
Yeah the pcre version we had embedded was old, and this was one of the motivating factors in making it an external dependency; it's much easier to just link to an updated external lib rather than having to update build systems each time a package is updated (it also allows the use of customised versions of the dependency if the user requires that, and so on).
The MSVC++ build has been updated now. There are some issues with the Lua bindings not compiling, but everything else is now working again. You will need the updated commom dependency package for Win32 - I have uploaded a 'beta' version which can be downloaded here.
HTH
CE
CrazyEddie wrote:The MSVC++ build has been updated now. There are some issues with the Lua bindings not compiling, but everything else is now working again. You will need the updated commom dependency package for Win32 - I have uploaded a 'beta' version which can be downloaded here.
Great. Thanks for the update. I have to work on my taxes first though.
The taxes are pretty much done now , but now I'm having trouble getting cvs head to compile.
It keeps wanting to link against stlport_vc7_static.lib. I can't figure out where that's coming from. It doesn't seem to be in the vcproj files, and a search of "Entire Solution, *.*" doesn't turn up any hits on "stlport_vc7" that are being included via #pragma comment type statements.
Where could it be coming from?
I blew away my entire CVS tree and checked it out from scratch, and it's still happening.
It keeps wanting to link against stlport_vc7_static.lib. I can't figure out where that's coming from. It doesn't seem to be in the vcproj files, and a search of "Entire Solution, *.*" doesn't turn up any hits on "stlport_vc7" that are being included via #pragma comment type statements.
Where could it be coming from?
I blew away my entire CVS tree and checked it out from scratch, and it's still happening.
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Ah ha! I found it.
That's using the pcre_d.lib in the 0.5beta deps package you linked to above.
I didn't even realize you could embed a DEFAULTLIB directive in a .lib like that. Although I guess it makes sense, since that's what's done with the runtime libs (LIBC/MSVCRT). If that info weren't embedded in the .libs then we wouldn't get all those lovely linker warnings that tell us our program is probably going to crash.
I sure wish MSVC would generate a report about WHY it's trying to link with things. And while we're at it, reports about WHICH lib it found to link with, and WHERE it pulled #includes from would also be nice in helping to resolve these sorts of head-scratchers.
[edit]
BTW it looks like just slapping "stlport_vc7_static" in the "Ignore Specific Library" property for CEGUIBase in VC++ does the trick.
[/edit]
Code: Select all
> dumpbin /directives pcre_d.lib | grep stl
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
/DEFAULTLIB:"stlport_vc7_static.lib"
>
That's using the pcre_d.lib in the 0.5beta deps package you linked to above.
I didn't even realize you could embed a DEFAULTLIB directive in a .lib like that. Although I guess it makes sense, since that's what's done with the runtime libs (LIBC/MSVCRT). If that info weren't embedded in the .libs then we wouldn't get all those lovely linker warnings that tell us our program is probably going to crash.
I sure wish MSVC would generate a report about WHY it's trying to link with things. And while we're at it, reports about WHICH lib it found to link with, and WHERE it pulled #includes from would also be nice in helping to resolve these sorts of head-scratchers.
[edit]
BTW it looks like just slapping "stlport_vc7_static" in the "Ignore Specific Library" property for CEGUIBase in VC++ does the trick.
[/edit]
- CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
- spannerman
- Home away from home
- Posts: 330
- Joined: Wed Jan 12, 2005 12:06
baxissimo, what compiler are you using?
I had the same troubles on VC 8 Pro (HEAD version of code, got clean today) but after the beta dependencies and the 'ignore stlport_vc7_s' Im still having troubles compiling.
cannot open file 'LIBC.lib' CEGUIBase
and
Cannot open include file: 'd3d9.h': No such file or directory c:\ogre_engine\cegui_mk2\include\renderers\directx9guirenderer\d3d9renderer.h 39
Any ideas?
I had the same troubles on VC 8 Pro (HEAD version of code, got clean today) but after the beta dependencies and the 'ignore stlport_vc7_s' Im still having troubles compiling.
cannot open file 'LIBC.lib' CEGUIBase
and
Cannot open include file: 'd3d9.h': No such file or directory c:\ogre_engine\cegui_mk2\include\renderers\directx9guirenderer\d3d9renderer.h 39
Any ideas?
spannerman wrote:baxissimo, what compiler are you using?
I had the same troubles on VC 8 Pro (HEAD version of code, got clean today) but after the beta dependencies and the 'ignore stlport_vc7_s' Im still having troubles compiling.
I'm still on MSVC.NET 7.1
spannerman wrote:cannot open file 'LIBC.lib' CEGUIBase
and
Cannot open include file: 'd3d9.h': No such file or directory c:\ogre_engine\cegui_mk2\include\renderers\directx9guirenderer\d3d9renderer.h 39
Any ideas?
None here, sorry.
- spannerman
- Home away from home
- Posts: 330
- Joined: Wed Jan 12, 2005 12:06
- lindquist
- CEGUI Team (Retired)
- Posts: 770
- Joined: Mon Jan 24, 2005 21:20
- Location: Copenhagen, Denmark
I'm not sure about the LIBC.lib thing, but d3d9.h is from the DirectX9 SDK and which you need to download and install.
If you dont want the dx9 renderer, then edit CEGUISamplesConfig.h in cegui_mk2/Samples/common/include
You will also need to removed the renderers you disable from the dependency list of SampleHelper.
when we release there wont be a shared dependency package, but one for vc8 so hopefully the dependency problem will go away with that
If you dont want the dx9 renderer, then edit CEGUISamplesConfig.h in cegui_mk2/Samples/common/include
You will also need to removed the renderers you disable from the dependency list of SampleHelper.
when we release there wont be a shared dependency package, but one for vc8 so hopefully the dependency problem will go away with that
- spannerman
- Home away from home
- Posts: 330
- Joined: Wed Jan 12, 2005 12:06
lindquist wrote:I'm not sure about the LIBC.lib thing, but d3d9.h is from the DirectX9 SDK and which you need to download and install.
I have the Directx9 SDK, in fact I have been compiling Cegui (from CVS HEAD) fine for quite a while now and my machine setup has not changed in this time. However, I havent updated the code recently for probably a couple of months (first time Ive got Cegui code using SVN) and now I am having these compilation problems.
lindquist wrote:when we release there wont be a shared dependency package, but one for vc8 so hopefully the dependency problem will go away with that
Cool. I am looking forward to the release.
Cheers.
Who is online
Users browsing this forum: No registered users and 8 guests