compile error Topic is solved

[Guest]

Does anyone know why I would get this error:

Creating library ..\bin\Debug/OgrePlatform.lib and object ..\bin\Debug/OgrePlatform.exp
OgrePlatform.exp : warning LNK4070: /OUT:PlatformManager_Win32.dll directive in .EXP differs from output filename "..\bin\Debug/OgrePlatform.dll"; ignoring directive
OgreWin32Input8.obj : error LNK2001: unresolved external symbol _IID_IDirectInput8A
..\bin\Debug/OgrePlatform.dll : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

I'm using vc6. I have stlport directory first.

[Slophopper]

In Tools->Options->Directories->Lib Files do you have the prebuilt stl linked to it?

Also try looking at the forum that has looked in all 18 pages of forums. Maybe that forum will help

[Guest]

I tried it, but it didn't help. I really want to try this engine but it seems impossible to compile. I typed in "18 pages" in the search engine but couldn't find the forum.

[cTh]

'_IID_IDirectInput8A' have nothing to do with STLPort, it's a DirectX8 function, do you have DX8 or 9 SDK installed correctly ??
Hope this helps

[Guest]

I had it installed correctly. Apparently I had to link to direct show which is a subdirectory of the include in directx sdk. I don't get that error, but I still get this warning:

Linking...
Creating library ..\lib\Debug/OgreMain.lib and object ..\lib\Debug/OgreMain.exp
LINK : warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library
1 file(s) copied.

Anyone know why?

[cTh]

This REALLY should not bother you, it's VERY normal, and somehow required

[lgoss007]

Linking...
Creating library ..\lib\Debug/OgreMain.lib and object ..\lib\Debug/OgreMain.exp
LINK : warning LNK4098: defaultlib "LIBC" conflicts with use of other libs; use /NODEFAULTLIB:library
1 file(s) copied.

Anyone know why?

This happens when you mix Debug and Release libraries. Such as building the Debug version of OGRE with the Release version of STL Port (just one example). I don't think it hurts anything. If you wanted to get rid of it you would have to check the libs that OGRE links to and make sure they matched there respective builds (Release with Release and Debug with Debug).

[jabba]

Thanks. I'm so excited I registered and everything. I compiled the skyplane demo and got it working. I didn't realize the dragon was a mesh when I first looked at the demo's. Ogre kicks! I can't wait to actually do something with it.

[Fatman]

I get the exact same errors... could you explain your solution in more detail, jabba?

TiA,
Fatman

[sinbad]

It's not an error, it's a warning. The resolution is to ignore it.

If you're talking about the DirectX link error, you just havent got the order of your include / lib folders right. Like the FAQ says, they should be STLport (if you need it), then DirectX9 SDK, then everything else. Perform a clean batch build if you change it.

[Fatman]

Yeah, it was the linking error I meant. It resolved itself, don't ask me how. I did the builds one at a time and that worked. Seems I did have the order right. However I find myself still unable to compile the first tutorial example because of linking errors.

I want to use OGRE because it looks like the perfect tool, but it seems insanely difficult to set up properly. I'm sure it's a doddle to use once it's set up, but after ten days of fiddling I can't seem to get the Win32 or Linux versions working.

I hear v1.0 comes with binaries, so any ideas when that's due out? [I checked out the website, but couldn't find any info on it - just a vague rumour of binaries.]

[sinbad]

It really isn't hard to set up if the follow the instructions. What's difficult is when you deviate from the instructions or miss something, and then fiddle around with things to try to fix it yourself. 99% of the setup problems I see here are because people didn't read the instructions properly (or didn't understand them due to unfamiliarity with their compiler), then got themselves in a mess trying to fix it themselves.

On Windows/VC7+ it's easy as pie:
1. Install STLport
2. Install DirectX9 SDK
3. Setup VC to look for 1 and 2 in that order, then everything else, in the include / lib paths
4. Extract Ogre
5. Extract dependencies
6. Batch build Ogre.sln

It's really that simple. VC6 introduces a few extra complexities (like Dx9c not supporting it without an extra download, and the ridiculous /Zm problems), but that's because VC6 is shite - get a proper compiler

1.0 will be done when it's done, you can read about the current progress on the wiki here: http://ogrewiki.digitalsentience.com/in ... thothNotes . As you can see it's coming along well.

[Fatman]

I'm using VC6. [Btw, I thought VC7 didn't require STLport?] I tried to follow the instructions, but perhaps I misunderstood something. The instructions are very vague. But I don't want to start a flame war or get kicked off the forum or anything, so I'll get off that right now.

I think it might be the step 3 you mentioned... perhaps it's not right. That's all I can think. Maybe if I post screenshots you [or someone else] can see if I've got it wrong somewhere [please?]. I'll just post links, not actual screenshots.

Lib settings screenshot
Include settings screenshot

1.0 looks like it's coming along well agreed, but I was just curious if you had some date in mind... I guess you get that a lot, hence the "annoyed with stupid noob" writing style. Oh well, I'm used to the "when it's done" release date, I quote that one myself.

I have encountered the /Zm problem. So you recommend getting another compiler, eh? I'll look into that. I'm used to VC6 though, so I'd better get started with that for now. [You say get a proper compiler - which one do you use? I'd prefer to avoid VC7 if possible.]

Thanks for trying to help out btw, it's much appreciated. I just feel so stoopid not being able to get a DLL compiled, when what I do for fun is write DLLs.

[haffax]

VC7 needs STLPort. VC7.1 doesn't.
Sinbad isn't unfriendly, but he usually doesn't beat around the bush and spares us (and you) the small talk part.
I can't see where the instructions are vague, so please show this part to us and the Ogre team will clarify it.

You must not add OgreMain/include or lib to the global include or lib directories. (And I'm quite sure the build instructions don't say so. )

Start anew. Follow the exact instructions. If in doubt about a step, ask.

[Fatman]

Thanks tanis.

Hehe, yes, I added OgreMain/include and OgreMain/lib to make OGRE compile at all. My mistake.

I'll try reinstalling STLport and DX9SDK tomorrow. Seems to be something wrong with my DX9SDK install, but I assumed I could get away with just using GL.

As to the install instructions in ReadMe_Building.html:

Building with Visual C++ 6 or Visual C++.Net

If you're building with Visual C++, follow these steps:

1. Make sure you have downloaded and installed STLport, version 4.5.3 if you are not using .Net 2003. The instructions for building and installing STLport are in the FAQ
2. Download and install the DirectX SDK, you need at least v8.1b, preferably 9.
3. Download and extract the latest 3rd party libraries distribution (you can find this in the downloads section of the OGRE hompage). See the FAQ for more details.
4. Open either Ogre.dsw (VC6) or Ogre.sln (VC7+)
5. Check the ordering of your include and library paths (in Tools | Options). The ordering should be STLport (if applicable), DirectX, then everything else.
6. Perform a Batch Build for all the projects. The dependencies should ensure everything is built in the right order.

1. quite clear.
2. doesn't mention that VC6 requires the DX9c extras, or exactly what to do with them. There's no install script [in the December edition at least], it's just a bunch of odd files.
3. doesn't mention that the files need to go in ogrenew, though I did work that out after a few minutes' head scratching.
4. couldn't be clearer.
5. I taught myself to use VC6, so I have no prior experience setting include and library paths. Until now I've always explicitly included libraries and headers using #pragma and #include, respectively. So it took a while to work out what this instruction meant. [You could argue that I should have learnt this, and you'd be right, but I think it would be good to have this be made clear for those daft enough to try to learn this stuff in their spare time, like me. ]. I assume the ordering required is STLport at the top of the list [at the bottom would seem counter-intuitive], DX9 below that [do I need to add the DirectShow dir as well?], and "everything else" I assume means "what was there before".
6. quite clear. I guess the instruction #5 sorts this out.

Btw, I also tried building on my FreeBSD system, but no luck there either. The ./configure script kept telling me DevIL wasn't installed when it quite clearly showed up in my library cache [ldconfig -r]. The instructions here aren't too helpful either:

Building under Linux

If you're building under Linux with gcc, here's a very quick overview:

1. If you're using gcc version 2.9x, make sure you've installed STLport. However, if you can we advise using gcc 3.2+.
2. Confirm that you have SDL 1.2.4, Freetype2, DevIL and pkg-config available on your system (if not, install them!)
3. Change to the 'ogrenew' directory,
4. If you are installing from CVS, run './bootstrap'
5. type './configure'.
6. Run 'make' and 'make install' (the latter as root)

For more detailed instructions, see the Linux README.

1. quite clear.
2. no mention is made where to find FreeType2 or DevIL. A Google search sorts that out, to be sure. But which versions?
3. quite clear.
4. quite clear, but on this occasion I downloaded Hastur from the website.
5. tells me DevIL is not installed, when ldconfig tells me it is. Could it be a bug in the configure script?
6. alas, I could not get this far, but this [and instruction #5] is normal for Unix.

Whoa, sorry for the long post. Just my 4p [which is worth about 2 cents right now ].

[monster]

I may be well wide of the mark here, I don't use STLPort myself, but have you moved the STLPort directories around at all? As I understand it they should be under something like "STLPort-4.5.6" it looks like you've moved them to be under your VC directories. I seem to remember that this can cause problems.

2. doesn't mention that VC6 requires the DX9c extras, or exactly what to do with them. There's no install script [in the December edition at least], it's just a bunch of odd files.

The Microsoft DX9 SDK download page says;

This download does NOT include the DirectX 9.0 SDK Extras content, such as Japanese Docs, Symbol Files, Direct3D XFile Exporters, DirectShow DVD components and a D3dx.lib that is compatible with Visual Studio 6.0

IMHO, it's not really up to Ogre's docs to describe all the intricacies of installing the DX SDK. That's what the Microsoft docs are for! I think this is Microsoft's none-to-subtle way of hinting that it's hardly supporting VC6 at all these days and that it's time you updated your compiler!

Just out of interest, why would you prefer to avoid VC7? I use VC7.1 and it's superb!

3. doesn't mention that the files need to go in ogrenew, though I did work that out after a few minutes' head scratching.

On the page you downloaded the dependecies from, it says this;

Extract this into the parent folder of the 'ogrenew' folder. YOU NEED THIS if you use VC++ even if you're getting Ogre from CVS.

And also I believe this is described in quite a lot of detail on the "Newbie" bit of the WIKI.

Btw, I also tried building on my FreeBSD system...

I've no idea about that, but knowing virtually nothing about Linux I managed to install Debian on a spare PC and follow the Anjuta IDE tutorials to get Ogre up and running with no problems at all!

All the instructions are there somewhere, there's just a bit of reading to do. Frustrating when all you want to do it get up and running, but unavoidable I'm afraid!

[Fatman]

I can't sleep, so I'm back. Thanks for the reply monster.

have you moved the STLPort directories around at all?

I don't remember doing that but I'll keep it in mind when reinstalling.

The Microsoft DX9 SDK download page says;

This download does NOT include the DirectX 9.0 SDK Extras content, such as Japanese Docs, Symbol Files, Direct3D XFile Exporters, DirectShow DVD components and a D3dx.lib that is compatible with Visual Studio 6.0

Thanks for finding that. It's much clearer now I know it's d3dx.lib I needed. I didn't know that, and it's important for VC6/OGRE users. I'm guessing I copy the file over the old d3dx.lib.

IMHO, it's not really up to Ogre's docs to describe all the intricacies of installing the DX SDK. That's what the Microsoft docs are for! I think this is Microsoft's none-to-subtle way of hinting that it's hardly supporting VC6 at all these days and that it's time you updated your compiler!

Oh well, I just thought it might make things easier for other noobs with similar problems if some mention was made of it, or even where to find the MS docs.

If it's just one file that's needed, and the devs are writing an install doc anyway... well, if it were me, I wouldn't cavil at the time taken to add one more sentence to the effect that this file is needed and must go... wherever? I know, I have no right to complain about a free [and absolutely amazing by all accounts] product, but I'm almost desperate to try this new and amazing thing that everyone else is rhapsodising over. It's like those Magic Eye pictures that did the rounds a few years back, when everyone else is going "Hey, it's a yacht!" and you squint but all you can see is some weird squiggly lines. -- Sorry about that, I'm a bit tired.

Just out of interest, why would you prefer to avoid VC7? I use VC7.1 and it's superb!

Just prejudice I suppose. I heard [I don't know] that VC7 requires .NET installed on the Win32 box, and .NET will be installed on any computer of mine when the mouse slips from my cold dead fingers. If you can tell me VC7 does not require .NET, I'll go and get VC7 tomorrow.

3. doesn't mention that the files need to go in ogrenew, though I did work that out after a few minutes' head scratching.

On the page you downloaded the dependecies from, it says this;

Extract this into the parent folder of the 'ogrenew' folder. YOU NEED THIS if you use VC++ even if you're getting Ogre from CVS.

And also I believe this is described in quite a lot of detail on the "Newbie" bit of the WIKI.

True. I thought it might be handy in the install docs too, but it IS made 100% clear when downloading.

Btw, I also tried building on my FreeBSD system...

I've no idea about that, but knowing virtually nothing about Linux I managed to install Debian on a spare PC and follow the Anjuta IDE tutorials to get Ogre up and running with no problems at all!

All the instructions are there somewhere, there's just a bit of reading to do. Frustrating when all you want to do it get up and running, but unavoidable I'm afraid!

Well, I might explain by analogy... imagine you were using Windows Explorer to search for, say, a file called foo.dll in My Documents. You know the file is there, you just put it there, and then a search on *.dll in My Documents comes up empty. [Ok, so it's not a great analogy, but it describes my confusion perfectly.]

Just FYI, *BSD has an alternative Linux-compatible ABI, so Linux programs can be compiled and/or run under *BSD. Usually compiling and installing is easier than under Win32 , but this DevIL issue has me completely baffled.

Hang on a moment. Anjuta IDE tutorials? These give info on installing under Linux? /me Googles

Thanks for taking the time to answer my points. Much appreciated, and I hope I'll get to use OGRE some day soon.

[haffax]

VC7.1 (forget VC7) needs and installs .Net, yes. But I fail to see the problem, here. Just MS's version of Java. A bit more comfortable a bit less compatible, MS just beeing MS.

Hang on a moment. Anjuta IDE tutorials? These give info on installing under Linux? /me Googles

Google won't help here. The mentioned tutorial is somewhere in this very forum and alternativly in the wiki. You can find it and other installation instructions here.

[monster]

I heard [I don't know] that VC7 requires .NET installed on the Win32 box, and .NET will be installed on any computer of mine when the mouse slips from my cold dead fingers. If you can tell me VC7 does not require .NET, I'll go and get VC7 tomorrow.

Any reason why you're so opposed to .NET?

I guess the .NET framework was installed when I installed my copy of MSVC, but it seemed to make absolutely zero difference to how my PC behaved. I have no reason to know what .NET is, I don't use it and code I compile with MSVC 7.1 seems to run perfectly happily on PCs that don't have it installed.

Hang on a moment. Anjuta IDE tutorials? These give info on installing under Linux? /me Googles

See these two (sticky) posts;
http://www.ogre3d.org/phpBB2/viewtopic.php?t=5706
http://www.ogre3d.org/phpBB2/viewtopic.php?t=5100

They worked a treat for me.

[Fatman]

Any reason why you're so opposed to .NET?

With .NET we actually have two concepts. Firstly, we have web services.

It's all too easy. IMO more easy == less secure. The hard way isn't that hard once you pick it up, and I'll bet it's more fun, too. There's a reason it's hard: because fiddling with this stuff is risky.

I mean, take for example Windows XP's default enabling of Berkeley's Full Raw Sockets. It was available on Windows and *nix for years, but you had to enable it yourself. That was considered hard, so most people didn't bother. That was why it was disabled by default. There was no reason at all for MS to enable it by default.

[If you didn't know, FRS implements among other things the ability to spoof your IP address. I'm not ranting about MS btw, I'm just illustrating my point. ]

Now we have had XP with FRS enabled by default for some while, and how many times has the 'Net's volume of spam multiplied since XP's release? Could it be because FRS was enabled by default in XP?

[Btw, I don't ever intend to install XP either. 2000 works for me, and I'm learning how to use Unix so I can switch permanently. That's mainly why I want to use a crossplatform tool like OGRE. ]

So that's why I don't want to be able to lock my cat flap from my mobile phone, via my PC. I want to have to create a robot arm to flip a switch, and design a controller using an old piece of breadboard and three 74-series NAND gates. Hey, I'm using a lot of analogies these days, aren't I?

MS's version of Java.

And the other part of .NET is the Java thing.

Well, I spent a year working on a two-man Java project, and I never fully recovered.

<rant topic="Sun JDK" flame="100%" psychosis="82%">
I mean, either Sun's compiler or their runtime environment is shot to pieces. Possibly both. 8 * 10000 = 80000.000000001? Not in my Universe it ain't. Also, I don't like having the overhead of a runtime environment that makes the simplest "Hello World" app take up 10MB of memory and 3% CPU on a 2.4GHz system. [And I minimized the window before reading the figure - makes it more accurate apparently.] Portable? In a pig's eye is it. ANSI C is more portable. Classpath issues! Don't get me started. And so on.
</rant>

I don't mean to rant about Java, forgive me please, I know I'm way OT.

The point is, not only will I never willingly install Sun's JDK on any machine of mine, I will not install any SDK that could be described as Java. Call me prejudiced or melodramatic or even a little hysterical if you like, maybe you're right.

[sinbad]

Call me prejudiced or melodramatic or even a little hysterical if you like, maybe you're right.

Yeah, I think that covers it I think I can call myself a veteren of J2EE, and it most certainly IS portable, and it's quite magical to see an .ear you've built deploying not only on a different platform, but on a completely different vendor's application server. No, Java is not the most efficient language when you write the tiniest application in the world, but that's not the point. People writing little applets and such in Java have completely missed the point. Java comes into it's own when you need to write a large, scaleable business application and don't want to get shafted by a single application vendor. And it works. Best of all it's highly robust, secure and it's language restrictiveness, while frustrating to the 'top gun' programmer, makes managing standards in a real project much easier.

Oh and .Net means Java? Come on! If you mean J# / Visual J (which they had to remove anyway because of legal issues), that's the most outdated, bastardised version of Java ever conceived (hence why it sparked years of litigation) and doesn't even deserve to have the letter 'J' in the title. They're not even remotely comparable. If you've judged Java based on that, you've been badly misled. I've often thought that MS's secret plan with their 'customised' version of Java was to make people think it was shite, by clamping it to a years-old version and breaking the portability a bit for good measure. Tossers.

Your reluctance not to use VC.Net because that somehow means web services shows a lack of understanding - not only is .Net not all about web services (although you'd be forgiven for thinking so given the MS marketing machine, but what do they know about what the product really does?), but you don't even have to use .Net if you have VC.Net. I don't, I just use VC.Net in unmanaged mode, where it's exactly the same as all the previous versions. Oh, except without so many horrible, awful, soul-crushing bugs (VC6 is the worst compiler in the universe for C++ compliance).

My advice is to do less ranting, and try to keep an open mind. You don't learn things by judging without having a full understanding of the situation.

[Fatman]

My mind is open, sinbad. I'm quite prepared to be swayed by rational debate. Since I haven't seen any yet, I'm forced to go by my own experiences. Maybe you can help me towards a full understanding of the situation. It's just that of all the languages I've programmed in, Java is the most frustrating by far.

Please forgive the rant, I didn't mean to upset anyone. Perhaps I've been taught Java techniques that are out of date and thus not portable. Perhaps something subtle's wrong with my PCs' hardware. I did get every one of the problems I described. I never used J#/Visual J, only Sun's Java. And I am a minimalist, which is why I don't like the JRE. Obviously you are the Java guru of the two of us, and if I struck a nerve, I apologise.

Despite tanis' reassurance, you still seem angry towards me. I don't want that, sinbad, you're obviously one of the top experts here, though I don't think a personal attack because I hold a different opinion is appropriate. Or perhaps tanis was right and I'm just misreading you. Whichever the case, I merely seek peaceful coexistence here.

In fact, you've already helped. VC.NET, unmanaged mode. Thanks!

[leedgitar]

I'd recommend laying off the .Net ranting if you don't understand it. Just leave it be I do however agree that anything MS has ever done with Java is a total joke. However, the rest of .Net is not.

...a bit less compatible...

I beg to differ!



Now on the Java side, I've had my fair share of frustrations in the past. However, I attribute that more to the quality (or lack thereof) of the development tools rather than the language itself. At the time I was heavy into enterprise Java development (3-4 years ago), it seemed that people were rushing IDE's out the door to try and be the first to implement the ever growing J2EE standards. Every IDE I tried was either buggy, or was missing one simple thing that made the whole auto build + deployment features worthless. Some would not update .ear or .war files every time with update files before deployment. Some would be missing the ability to configure a key part of the XML descriptors, such as configuring the Entity bean equivalent of an identity column, and not letting you manually change the XML before packaging.

So, I decided to create a build process run by a batch file, that would automatically build everything, package all the archives, and hot copy over the finished product to Weblogic. To be honest, that was the most reliable Java deployment process I've ever used; textpad and command line building . From that point on, our team never had another problem. I hope that today's tools are much better, especially Eclipse which looks paraticularly impressive.

[haffax]

Oh. Eclipse. Don't get me starting.
I'd be so happy, when I ever find an C++-IDE that is half as comfortable and intelligent. Namely the Quickfixes and the refactorings are awesome.
J2EE-Tools have matured considerably. Personally I like XDoclets. Nothing graphically or fancy, but just a method, where metadata is applied through comments in front of methods/classes. And with that metadata deployment descriptors etc. are generated.

Anyway: I really, really like Java and I'm sure I'd like .Net with C#, too if I'd had a project using them. Java programming is much more comfortable and flexible. Where C++ has its static flexibility with its templates, Java has its dynamic flexibility with its nice Reflections abilitlies. And contrary to templates, you don't need to be a rocket scientist to fully understand them.

I beg to differ! :Cool:

Point taken, leedguitar. And when can we expect the linux port of Chronos? I don't know much about Mono, but afaik The Windows.Forms library has not been ported yet. With Java you have all java libraries that do not use JNI (and many that do) available on every platform supporting J2SE. As I said: Less portable, not unportable.
--tanis

PS: What was this threads' topic again?

[sinbad]

@Fatman: I'm not angry at you, I just felt the information in your post was rather misleading and needed correcting. Like most tools, there are opinions for and against (personally I love Eclipse), but really all tools need to be evaluated in the context for which they are designed. Java without the JRE and without all the fantastic libs that are available (like all those in the Jakarta project) is not a reasonable evaluation piece - the whole point of it is that taken as a whole it's incredibly powerful and open. If you want to be a minimalist, you shouldn't be using it (although I'd question what use being a minimalist is these days - software engineering is as much about assembly and integration as it ever is about actual coding these days).

I'm no .Net fan myself, but I don't deny it's a good tool for a lot of things (Axiom for example). My beef with it is that the 'standards' angle of it is an exercise in smoke-and-mirrors - as tanis says large and essential (business application wise) portions of .Net are certainly not standard or cross-platform, and I argue they never will be since it's not in MS's interest that there is a complete .Net environment in the open source domain. If you take .Net as a very productive MS-oriented environment (except if you have specific, constrained needs which Mono caters for, in which case you're lucky) that's fine, just don't be deluded into thinking .Net means cross-platform - the more you creep out into other libs, the more likely it is you'll find MS is your only option. That never happens with Java - there are shedloads of libs and they are all cross-platform.

It's always horses for courses - no reasonably successful tool is inherently 'good' or 'bad', it's just 'more suitable' or 'less suitable' for the given requirements at hand. Leave the sweeping generalisations to the marketing boys.