DR source can't find GL

[PranQster]

I previously compiled DR in March, but the current source from svn gives the following when running './configure'

 

 

checking for GLIB... yes

checking for GTK... yes

checking for GTKGLEXT... yes

checking for XML... yes

checking GL/glew.h usability... yes

checking GL/glew.h presence... yes

checking for GL/glew.h... yes

checking for main in -lGLEW... yeschecking for main in -lGL... no

configure: error: GL library not found.

 

 

The devel dependencies are all installed. If it can find GLEW but not GL, then what might be the problem. I have checked /usr/include and found that gl.h is in /usr/include/GL (and so is GL.h). gl.h also exists in /usr/include/nvidia-current.

I have tried both linking and then copying them directly to /usr/include, to no avail. I still get the GL library not found error

Edited May 17, 2010 by PranQster

[Serpentine]

try removing the glew package and adding it again, it should include(or offer to fetch depending on package manager/distro etc) all the relevant headers.

[PranQster]

Unfortunately, that did not work. I uninstalled and reinstalled libglew-devel-1.5.2-1mdv2010.1.i586.rpm. Then I tried reinstalling libglew1.5-1.5.2-1mdv2010.1.i586.rpm. Neither made a difference

 

 

Edit: Fixed!

I applied a system update which, among 215 packages, included mesa and new nvidia drivers. After rebooting with a new kernel, DR is now compiling. Go figure.

Edited May 18, 2010 by PranQster

[PranQster]

Success! DR 1.2.3 installed and running fine

[greebo]

DR 1.2.3? Where is that version number coming from? The current code in the trunk carries the version 1.3.0.

[PranQster]

What the??? ROFL it's like when I ended up with 1.1.1 AFTER you had released 1.2.0!

 

I got it from SVN here (last night):

 

svn checkout https://darkradiant....nk/darkradiant/ darkradiant

 

Edit: following the https:/ protocol:

/darkradiant.svn.sourceforge.net/svnroot/darkradiant/trunk/darkradiant/

Edited May 18, 2010 by PranQster

[greebo]

That trunk URL is ok. And the working copy is up to date?

 

This file here: https://darkradiant.svn.sourceforge.net/svnroot/darkradiant/trunk/darkradiant/include/version.h is definitely showing 1.3.0. Have you tried performing a clean recompile?

[PranQster]

That trunk URL is ok. And the working copy is up to date?

 

This file here: https://darkradiant....clude/version.h is definitely showing 1.3.0. Have you tried performing a clean recompile?

 

the version.h included in what I built also says 1.3.0

 

in 'configure' there is this:

 

# Identity of this package.

PACKAGE_NAME='darkradiant'

PACKAGE_TARNAME='darkradiant'

PACKAGE_VERSION='1.2.3'

PACKAGE_STRING='darkradiant 1.2.3'

PACKAGE_BUGREPORT=''

PACKAGE_URL=''

Edited May 18, 2010 by PranQster

[greebo]

Well, there's definitely something not included correctly, or you are linking outdated object files (or your system is completely screwed up). Not much I can do here, I'm afraid, sorry.

 

edit: saw your edit. That might explain where it's coming from. I'll check out the source in the about dialog.

[PranQster]

Maybe I am actually running 1.3.0, but because of the configure script it got identified as 1.2.3 and the same thing happened with version 1.2.0 showing as 1.1.1...?

 

Edit:

While you're at it, any idea why when I go to create a player start position I am required to assign it to a brush? See my other tutorial help request post.

Edited May 18, 2010 by PranQster

[greebo]

Yes, after checking the source, I saw that the PACKAGE_VERSION string is what is compiled when running in Linux. So it's just this configure script which is not in sync, nothing to worry about then.

[PranQster]

I'm going to start over anyway and reacquire it from svn and build it totally fresh. Since I did start this last night and finished it today, after system updates.

 

Edit: Ok, I won't worry about it. I'll probably end up starting from scratch and I'll edit the version in the configure script when I do.

Edited May 18, 2010 by PranQster

[PranQster]

Recompiled fresh svn code after modifying the configure script. Now it shows the proper version.

[OrbWeaver]

I bumped the Linux version to 1.2.3 because the previous Windows release was 1.2.2; I didn't realise there had been a feature increment in the meantime. I guess I should have checked the relevant version.h file first (although it probably makes little sense to have Linux at 1.3.0 if the Windows 1.3.0 isn't complete yet).

[greebo]

Hm, yes. I usually increase the SVN version to be able to distinguish SVN or "snapshot" builds from actually released ones. Recently, after adding support for internationalization, I figured this would justify a feature increment to 1.3.0 so I just went ahead.

 

I guess it'd have been better practice to leave the development version at 1.2.3 (even if major features like i18n gets implemented) and bump it to 1.3.0 right before going public with a proper release.

[OrbWeaver]

I guess it'd have been better practice to leave the development version at 1.2.3 (even if major features like i18n gets implemented) and bump it to 1.3.0 right before going public with a proper release.

 

I think the more fundamental problem is that I only get round to releasing the DEBs when somebody prods me for them, which means they don't correspond to the versions of the Windows releases. I think in future I will leave the version number the same as the previous Windows release, but append the SVN revision, e.g. "1.2.2-svn5756".

 

Also, I'm not sure why I didn't consider this before, but an Ubuntu PPA (https://help.launchpad.net/Packaging/PPA) would be a much better way of hosting the DEBs than uploading them to Bloodgate via FTP. It looks like Launchpad accepts source packages and automatically builds multiple architectures and distributions from them, which would be a lot more convenient.

[PranQster]

... It looks like Launchpad accepts source packages and automatically builds multiple architectures and distributions from them, which would be a lot more convenient.

 

That would be nice. My distro, Mandriva, uses .rpm which install directly into /usr. Recent fedora and suse .rpm files seem to be doing the same, but some older versions preferred to install into /usr/local or /opt. In any case, if I use an .rpm packaged for either fedora or suse, I am in the habit of using 'rpm2cpio filename.rpm | cpio -idv' to extract the .rpm. I can then manually move the contents to the appropriate path.

So to make a long story short... any .rpm will do

[OrbWeaver]

When I say "multiple distributions" I mean multiple distributions of Ubuntu, e.g. Karmic, Lucid etc. Launchpad won't build RPMs as far as I know.

 

Somebody did contribute a .spec file for building DR on Fedora which is in the source tree, but I don't use an RPM-based distro so I don't know what sort of state it is in.

[PranQster]

When I say "multiple distributions" I mean multiple distributions of Ubuntu, e.g. Karmic, Lucid etc. Launchpad won't build RPMs as far as I know.

 

Somebody did contribute a .spec file for building DR on Fedora which is in the source tree, but I don't use an RPM-based distro so I don't know what sort of state it is in.

 

Ah, ok. LOL, I keep forgetting that the Linux world revolves around 'buntu.