Ante situaciones así hay gente que le agarra fobia, pero ... hay gente que se vuelve luchadora.
Me lo querían amedrentar a Kim, no funcionó .... en cualquier momento vuelve a la carga  contra el lobby audiovisual que reivindica lo peor del copyright

El gordito es legendario♥

+1, yo me quedé pensando → "No tenemos github y/o gitorious para esto? qué aporta de nuevo este sitio?"  (aparte de la buena onda)

Todo en orden entonces, ese código es un horror, por que no es portable para nada (es esperable que falle, por que está programado para preferir Direct3D en una plataforma donde no existe) ... en esos oscuros tiempos programaba sólo sobre Windows (principalmente por el Cg studio y otras tools que ahora reemplazé) , y como deducirás, sobre Visual Studio.
Ahora, si tuviese que reformularte ese post y código para que testees Ogre, lo haría así:

Como uso Debian y no quiero poner el path completo a RenderSystem_GL, simplemente le hago un enlace simbólico en el directorio actual, en mi caso:

ln -s /usr/lib/x86_64-linux-gnu/OGRE-1.7.4/RenderSystem_GL.so ./

Test.cxx

#include <Ogre.h>
 
#define RENDERSYSTEM_GL "./RenderSystem_GL"
#define RENDERSYSTEM_GL_NAME "OpenGL Rendering Subsystem"
 
int main(int argc, char *argv[])
{
		Ogre::Root* Root = new Ogre::Root("",""); // omitimos el archivo de plugin y config
 
		Root->loadPlugin(RENDERSYSTEM_GL);
 
		// Tomemos OpenGL como preferido ...
		Ogre::RenderSystem* RenderSystem  = Root->getRenderSystemByName(RENDERSYSTEM_GL_NAME);
 
		// Seteemos el RenderSystem
		Root->setRenderSystem(RenderSystem);
		// Inicializemos el RenderSystem sin crear una ventana de render
		Root->initialise(false);
 
		// Creemos la ventana de render a 800x600 Windowed mode
		Ogre::RenderWindow* Window = Root->createRenderWindow("Ejemplo",800,600,false);
 
		// Listo, Tenemos Una Aplicación Ogre Inicializada =3
		// Creemos lo básico para una escena
 
		Ogre::SceneManager* SceneMgr = Root->createSceneManager(Ogre::ST_GENERIC); // Esto del Type mask se desaconseja ! ~ un Scene Manager Basico
		Ogre::Camera* Cam = SceneMgr->createCamera("MainCamera");  // Creamos una camara
		Ogre::Viewport* Vp = Window->addViewport(Cam); // Un viewport en la ventana Window, usando Cam como origen desde donde se va a renderizar
 
		// Listo, Inicializado
		// Entremos en un bucle de render infinito ....
 
		Root->startRendering();	
		delete Root; // es lo mismo, total, está el return, pero igual lo pongo
 
		return 0;
 
}
 

clang++ -lOgreMain Test.cxx -I/usr/include/OGRE -o ./Test #g++ o loquesea, la cosa es compilar, pasar librería y que encuentre el header

Con eso testeás que la app. se compile y ejecute, aunque en tu caso ya compiló, significa que está todo ok mientras tengas la aceleración funcionando.

Ahora, si me pedís la respuesta "correcta", no inicializaría así a Ogre, sino más bien usaría ayuda de cmake para armar un módulo que lidie con tema encabezados y librerías de forma portable a través de las plataformas, si bien puede hacerse con un IDE portable como Code::Blocks, los paths no siempre son los mismos (cmake lidia con eso) ... sobre eso algún script (guarda con el sentido en el que lo uso !!!) de inicialización que lidie con todas estas cochinadas de los plugins, rendersystems y demás temas de inicialización de forma elegante...

Saludos.

A ver, desde el vamos que el sistema educativo tal cual está planteado ahora ES UNA PORQUERÍA ... el problema no es reconocer el problema, sino solucionarlo.
Hay mucho material que abortda el tema (y relacionados) de forma simple :

http://www.youtube.com/watch?v=fO2ng5SFrZU
http://www.ted.com/talks/lang/en/ken_robinson_says_schools_kill_creativity.html
http://www.youtube.com/watch?v=DU7k7X7SzmQ
http://www.ted.com/talks/lang/en/salman_khan_let_s_use_video_to_reinvent_education.html

Respecto a Roger, tengo que leer más antes de sostener una opinión ... ( aunque mi primera impresión es MALA por algunas cosas que leí )

Saludos.

¿Qué te sale en las undefined reference? por otro lado MUY MAL eso de instalar manualmente ... ya que esa instalación vá a dejar residuos que pueden corromper lo que el gestor de paquetes o futuras instalaciones manuales puedan agregar.
Si todavía tenés el Makefile desde el que corriste el make install, corré make uninstall (o deinstall, siempre se me transpapela en la cabeza) y forzá re-instalación de los paquetes de Ogre y OIS (los -dev también) vía gestor de paquetes.

Compilá este código (que es un código MÍNIMO de Ogre) : http://foro.elhacker.net/programacion_cc/ogre3d_en_dev_c-t243920.0.html;msg1173366#msg1173366  ←Qué asco ese código, se hace el agnóstico de la plataforma cuando no lo es !! x')
Pero usando g++ directamente

g++ -lOgre Fichero.cpp # u -lOgreMain si esto no funciona

Si compila, la instalación y el linker está bien ... estás configurando mal el proyecto

Saludos.

Para sacar un checksum a todos los ficheros de /boot:

 for mFile in $( find /boot/ -type f ); do sha256sum -b $mFile; done

Para sacarle un checksum al sector de inicio de un esquema MBR.

BootCheckSum=$(dd if=/dev/sda bs=512 count=1  | sha256sum )

Y queda en esa variable para volcarse donde desees ... si el esquema de particiones es otro (como GPT), vas a tener que leer un poco más que simples 512bytes

Saludos.

En C++ podrías revisar ifstream/ofstream  → http://www.cplusplus.com/doc/tutorial/files/
FILE de stdio.h corresponde a la librería estándar de C


Con algo tan rudimentario como FILE podés leer cualquier tipo de fichero, imágenes y ficheros de fuentes (true type por ejemplo) incluídos.
si sabés el formato y sabés decodificar los píxels para meterlos en una matriz (o vector, ¿por qué no?) ... aunque ya hay librerías para eso =D

Naturalmente si hacés aplicaciones de consola, no vas a tener donde mostrar dichos píxeles ... salvo que uses algún método o librería para gráficos en consola como aalib (aunque hay posibilidad de cosas más elaboradas) para ofrecer algo remotamente similar a lo que ofrecería un (frame)buffer más "completo"
Pero que podés lidiar con cualquier archivo (usando la librería estándar) mientras sepas el formato ...

Saludos.

Bueno, para networking, aparte de ASIO de Boost (como te mencioné en otro post), también está la de Qt → http://doc.qt.nokia.com/4.7-snapshot/network-programming.html
Para Hardware, hasta donde sé Qt no tiene algo así (a pesar de que se propuso hacer un merge de las kdelibs ... pero tomalo como de alguien que hace rato que no le pone un dedo a Qt ni a las libs de kde), lo más "cercano" a eso que conozco es Solid de KDE ( http://solid.kde.org/ ), que afaik es cross-platform (hace no mucho las libs de KDE se portearon a Windows, me imagino que Solid también) .. pero hasta donde sé no hay nada que cumpla 100% lo que entendí de tu post.


¿A qué llamarías un buen manejo de archivos?

Saludos.

GTK está en C .... igual, SDL te dá herramientas base para trabajar con gráficos. Léase → Podés armar tu propia librería para interfaces gráficas y hacer cosas BASTANTE vistosas que con GTK ni de casualidad, pero al coste de reinventar la rueda y armar tu propio toolkit, claro está.

Saludos.

La que más se acerca a lo que mencionás es Qt ... Tiene buena documentación, tiene el Designer, está bien pensada a nivel diseño ( Qt5 ya incorpora features de C++11 ) y es multiplataforma  ...
ahora, me gustaría que amplíes todo lo demás que mencionaste como lo del soporte de red y acceso a hardware ... son expresiones demasiado amplias

Saludos.