New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't compile using deprecated version of glext #511

Closed
svenstaro opened this Issue Dec 20, 2013 · 26 comments

Comments

Projects
None yet
10 participants
@svenstaro

svenstaro commented Dec 20, 2013

I get this upon compiling from git:

In file included from /home/svenstaro/src/sfml/src/SFML/Window/Unix/GlxContext.cpp:33:0:
/home/svenstaro/src/sfml/src/SFML/Window/glext/glxext.h:670:22: error: ISO C++ forbids declaration of ‘GLXContextID’ with no type [-fpermissive]
typedef GLXContextID ( * PFNGLXGETCONTEXTIDEXTPROC) (const GLXContext context);
^
/home/svenstaro/src/sfml/src/SFML/Window/glext/glxext.h:670:22: error: typedef ‘GLXContextID’ is initialized (use decltype instead)
/home/svenstaro/src/sfml/src/SFML/Window/glext/glxext.h:670:26: error: ‘PFNGLXGETCONTEXTIDEXTPROC’ was not declared in this scope
typedef GLXContextID ( * PFNGLXGETCONTEXTIDEXTPROC) (const GLXContext context);
^
/home/svenstaro/src/sfml/src/SFML/Window/glext/glxext.h:671:67: error: ‘GLXContextID’ has not been declared
typedef GLXContext ( * PFNGLXIMPORTCONTEXTEXTPROC) (Display *dpy, GLXContextID contextID);
^

Updating glext header in SFML makes it compile fine.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Dec 20, 2013

Member

Might want to add more details? Like compiler version etc.? Compiles fine for me under Windows and for crosscompiling to Android, haven't tried Linux lately.

Member

MarioLiebisch commented Dec 20, 2013

Might want to add more details? Like compiler version etc.? Compiles fine for me under Windows and for crosscompiling to Android, haven't tried Linux lately.

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro Dec 20, 2013

Linux 3.12.5, Mesa 10.0.1, gcc 4.8.2

svenstaro commented Dec 20, 2013

Linux 3.12.5, Mesa 10.0.1, gcc 4.8.2

@Senzaki

This comment has been minimized.

Show comment
Hide comment
@Senzaki

Senzaki Dec 21, 2013

I have the same problem with the same problem with the same versions, but please note that the problem has nothing to do with glext.h. glxext.h (with an X) is the issue here.
(EDIT : I was actually wondering : why doesn't SFML use the version of glext shipped with the Linux distro, the one that is usually located in /usr/include/GL ?)

Senzaki commented Dec 21, 2013

I have the same problem with the same problem with the same versions, but please note that the problem has nothing to do with glext.h. glxext.h (with an X) is the issue here.
(EDIT : I was actually wondering : why doesn't SFML use the version of glext shipped with the Linux distro, the one that is usually located in /usr/include/GL ?)

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro Dec 22, 2013

The library is called glext and it has everything to do with that. I was not suggesting a partial update of glext anyway. It is of no concern which individual files in glext need updating as one should just update the whole library.

And indeed it does raise the question why SFML doesn't just use the system libraries.

svenstaro commented Dec 22, 2013

The library is called glext and it has everything to do with that. I was not suggesting a partial update of glext anyway. It is of no concern which individual files in glext need updating as one should just update the whole library.

And indeed it does raise the question why SFML doesn't just use the system libraries.

@SuperV1234

This comment has been minimized.

Show comment
Hide comment
@SuperV1234

SuperV1234 Dec 22, 2013

Seems like GLXContextID is now called XID in the latest mesa.

Adding

#define GLXContextID XID

to GlxContext.hpp fixed the issue.

SuperV1234 commented Dec 22, 2013

Seems like GLXContextID is now called XID in the latest mesa.

Adding

#define GLXContextID XID

to GlxContext.hpp fixed the issue.

@SuperV1234

This comment has been minimized.

Show comment
Hide comment
@SuperV1234

SuperV1234 Dec 24, 2013

Any news on this issue?

SuperV1234 commented Dec 24, 2013

Any news on this issue?

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Dec 24, 2013

Member

It's obviously just due to the removed typedef (since it's been unused and caused some redefinition). One possible bug report can be found here. Since Laurent isn't available for about two weeks, I guess you won't see any specific update soon. Considering it's really just the typedef, you could just fix it yourself or add a new preprocessor definition: -DGLXContextID=XID.

Member

MarioLiebisch commented Dec 24, 2013

It's obviously just due to the removed typedef (since it's been unused and caused some redefinition). One possible bug report can be found here. Since Laurent isn't available for about two weeks, I guess you won't see any specific update soon. Considering it's really just the typedef, you could just fix it yourself or add a new preprocessor definition: -DGLXContextID=XID.

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro Jan 15, 2014

Any news on this?

svenstaro commented Jan 15, 2014

Any news on this?

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Jan 15, 2014

Member

This essentially just needs updated header files. The latest can be found here. I've replaced them for me for a test run and worked without problems under Windows, although haven't tried Unix so far.

Member

MarioLiebisch commented Jan 15, 2014

This essentially just needs updated header files. The latest can be found here. I've replaced them for me for a test run and worked without problems under Windows, although haven't tried Unix so far.

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro Jan 15, 2014

Everybody knows how to fix it but the fix needs to be in master first.

svenstaro commented Jan 15, 2014

Everybody knows how to fix it but the fix needs to be in master first.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Jan 15, 2014

Member

Apply the fix, test run it on as many platforms as possible, then submit it as a pull request.

Member

MarioLiebisch commented Jan 15, 2014

Apply the fix, test run it on as many platforms as possible, then submit it as a pull request.

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro Jan 17, 2014

The better fix would be not to use the headers provided by SFML at all on systems that already have them. Effectively, on Linux and probably osx as well it should use the system headers only. On Windows it should probably use its own headers.

svenstaro commented Jan 17, 2014

The better fix would be not to use the headers provided by SFML at all on systems that already have them. Effectively, on Linux and probably osx as well it should use the system headers only. On Windows it should probably use its own headers.

@ghost ghost assigned LaurentGomila Jan 28, 2014

@Bromeon Bromeon added the bug label Feb 24, 2014

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon Apr 1, 2014

Member

But when using the system libraries, doesn't SFML have to differentiate cases to make sure the code compiles (apparently, the type was named differently earlier).

And on the other hand, if we just update the glext headers, will it still be compatible with older systems?

Member

Bromeon commented Apr 1, 2014

But when using the system libraries, doesn't SFML have to differentiate cases to make sure the code compiles (apparently, the type was named differently earlier).

And on the other hand, if we just update the glext headers, will it still be compatible with older systems?

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro Apr 2, 2014

Don't know. However, it should be priority to be working with modern systems. At any rate, it should use system headers as opposed to prepackaging its own in order to avoid the problem altogether.

svenstaro commented Apr 2, 2014

Don't know. However, it should be priority to be working with modern systems. At any rate, it should use system headers as opposed to prepackaging its own in order to avoid the problem altogether.

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch Apr 2, 2014

Member

From what I've understood, there shouldn't be any problems with older versions. The removed typedef has been an alias all the time, so there's no real change behind the scenes.

Member

MarioLiebisch commented Apr 2, 2014

From what I've understood, there shouldn't be any problems with older versions. The removed typedef has been an alias all the time, so there's no real change behind the scenes.

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro Apr 19, 2014

How about fixing this? Just grab the current set of files from current mesa. Better solution is to take system headers only, especially on Linux.

svenstaro commented Apr 19, 2014

How about fixing this? Just grab the current set of files from current mesa. Better solution is to take system headers only, especially on Linux.

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon Apr 19, 2014

Member

How about fixing this?

Don't worry, I have not forgotten it. As you see, it's planned for SFML 2.2.

I'm not sure what's the reason why SFML ships the headers instead of using the system ones, but I guess it's to make configuration and usage easier. Maybe @LaurentGomila knows?

Member

Bromeon commented Apr 19, 2014

How about fixing this?

Don't worry, I have not forgotten it. As you see, it's planned for SFML 2.2.

I'm not sure what's the reason why SFML ships the headers instead of using the system ones, but I guess it's to make configuration and usage easier. Maybe @LaurentGomila knows?

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Apr 19, 2014

Member

I've always used downloaded headers, since they are provided "officially" on the OpenGL website, and they were not shipped on Windows. But if they are part of the system on Linux, there's no reason not to use them.

Member

LaurentGomila commented Apr 19, 2014

I've always used downloaded headers, since they are provided "officially" on the OpenGL website, and they were not shipped on Windows. But if they are part of the system on Linux, there's no reason not to use them.

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon Apr 19, 2014

Member

But if they are part of the system on Linux, there's no reason not to use them.

I'm not sure whether they are, doesn't the user have to install Mesa first (at least for a more recent version)? Otherwise we can also keep shipping the headers to make sure they're there on every platform.

Member

Bromeon commented Apr 19, 2014

But if they are part of the system on Linux, there's no reason not to use them.

I'm not sure whether they are, doesn't the user have to install Mesa first (at least for a more recent version)? Otherwise we can also keep shipping the headers to make sure they're there on every platform.

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro Apr 19, 2014

It is prudent to assume that Linux users that use SFML graphics will have Mesa installed.

svenstaro commented Apr 19, 2014

It is prudent to assume that Linux users that use SFML graphics will have Mesa installed.

@TankOs

This comment has been minimized.

Show comment
Hide comment
@TankOs

TankOs Apr 23, 2014

Member

And even if not, adding the dependency is absolutely alright.

Member

TankOs commented Apr 23, 2014

And even if not, adding the dependency is absolutely alright.

@abodelot

This comment has been minimized.

Show comment
Hide comment
@abodelot

abodelot May 17, 2014

Contributor

Isn't this issue fixed? Local copy of glx/glxext.h has been removed from master branch.

Contributor

abodelot commented May 17, 2014

Isn't this issue fixed? Local copy of glx/glxext.h has been removed from master branch.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 17, 2014

Member

Indeed, it was fixed in 5250cc9.

Member

mantognini commented May 17, 2014

Indeed, it was fixed in 5250cc9.

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro May 22, 2014

Well, then close this?

svenstaro commented May 22, 2014

Well, then close this?

@Bromeon

This comment has been minimized.

Show comment
Hide comment
@Bromeon

Bromeon May 22, 2014

Member

@svenstaro It is closed ;)

Member

Bromeon commented May 22, 2014

@svenstaro It is closed ;)

@svenstaro

This comment has been minimized.

Show comment
Hide comment
@svenstaro

svenstaro May 22, 2014

Oh, I'm an idiot. Yes, it's closed. ;)

svenstaro commented May 22, 2014

Oh, I'm an idiot. Yes, it's closed. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment