Current CVS errors

[Xaphier]

I'm not sure if this is right place to post it, but current cvs tries to free pointer to

a function

Those pointers are placed to the queues at lines elconfig.c:1572, elconfig.c:1574.

Freeing them while destoying queues causes segfault.

Should be fixed now in cvs.

 

[08:54:59] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 1/4...

[08:54:59] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 2/4...

[08:54:59] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 3/4...

[08:54:59] shader/noise.c.make_3d_noise_texture:175 - Generating 3D noise: octave 4/4...

[08:54:59] shader/shader.c.log_shader_compile_log:91 - Compiling shader './shader/water_fs.glsl' failed

[08:54:59] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/water_fs.glsl' successful

[08:54:59] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:54:59] shader/shader.c.log_shader_compile_log:91 - Compiling shader './shader/reflectiv_water_fs.glsl' failed

[08:54:59] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/reflectiv_water_fs.glsl' successful

[08:54:59] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/water_fs.glsl' successful

[08:55:00] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/water_fs.glsl' successful

[08:55:00] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/reflectiv_water_fs.glsl' successful

[08:55:00] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] shader/shader.c.log_shader_compile_log:87 - Compiling shader './shader/reflectiv_water_fs.glsl' successful

[08:55:00] shader/shader.c.log_shader_linking_log:121 - Linking shaders successful

[08:55:00] gl_init.c.init_gl_extensions:904 - OpenGL invalid value

The problem is, the two simplest shader fail to compile, so the system don't let you select the more advanced ones. I have no idea why it fails to compile them and your OpenGL don't give any hint why they fail, so it will be verry hard to find out why they fail

[Florian]

The problem is, the two simplest shader fail to compile, so the system don't let you select the more advanced ones. I have no idea why it fails to compile them and your OpenGL don't give any hint why they fail, so it will be verry hard to find out why they fail

 

Well, what changed since 2007-06-27 22:07:13 localtime (CEST) when the shaders worked perfectly?

 

/EDIT:

current CVS does not compile:

In file included from io/elfilewrapper.cpp:3:

io/zipfilesystem.hpp:11:21: error: allio.hpp: No such file or directory

In file included from io/elfile.cpp:3:

io/elfile.hpp:12:21: error: allio.hpp: No such file or directory

In file included from io/zipfilesystem.cpp:1:

io/zipfilesystem.hpp:11:21: error: allio.hpp: No such file or directory

 

make .depend fails

 

/EDIT: allio.hpp issue fixed

Edited June 30, 2007 by Florian

[Beaverhunter]

map.c finally fixed...But...

Here we go again... Same error as always...

 

1>zipfilesystem.cpp

1>.\io\zipfilesystem.cpp(64) : error C2065: 'int_fast32_t' : undeclared identifier

1>.\io\zipfilesystem.cpp(64) : error C2146: syntax error : missing ';' before identifier 'pos'

1>.\io\zipfilesystem.cpp(64) : error C2065: 'pos' : undeclared identifier

1>.\io\zipfilesystem.cpp(186) : error C2146: syntax error : missing ';' before identifier 'error'

1>.\io\zipfilesystem.cpp(186) : error C2065: 'error' : undeclared identifier

 

crusaidingknight:

If it was as simple as just including 2 header files and the C99 problems get fixed, don't you think MS would have just auto updated them or something in MS Update like ages ago? I haven't tested it yet but I really doubt it will work.

 

The current fix with just typedefing them is really simple, it's just that some people seems to forget this over and over.

[ttlanhil]

Xaphier has removed the stdint types from the code, so it should all be working again.

[crusadingknight]

crusaidingknight:

If it was as simple as just including 2 header files and the C99 problems get fixed, don't you think MS would have just auto updated them or something in MS Update like ages ago? I haven't tested it yet but I really doubt it will work.

Microsoft has NO INTEREST in making their compiler standards-compatible, which is why those headers exist in the first place. C99 is another step towards a more portable language, which reduces the amount which code is chained to their system - reducing their competitive advantage. Thus also why they don't have a fully BSD-compatible sockets stack. It is that simple for a company that created as large a piece of software as Vista to write the few lines it takes to implement stdint.h and inttypes.h for their compiler.

 

The headers are very simple, just typedef'ing Microsofts proprietary int types to the standards. Next time, I'd recommend trying it first.

Edited June 30, 2007 by crusadingknight

[Beaverhunter]

Oki compile errors finally fixed, but now I'm back to the linking errors:

 

1>Linking...

1>elpathwrapper.obj : error LNK2001: unresolved external symbol _S_ISDIR

1>noise.obj : error LNK2001: unresolved external symbol _glTexImage3D

 

=( I Know that linking is local but I'm sure you have more of a clue on what to do. Anyone have a clue on what I can try?

 

Update:

The problem seems to be that these functions are not defined before use.

Adding this:

#ifndef S_ISDIR

#define S_ISDIR(x) (((x) & S_IFMT) == S_IFDIR)

#endif // S_ISDIR

 

To the top of elpathwrapper.c, fixes the first link error.

 

The other one is here. But it's not defined in the ELC, it needs to be.

\GL\glext.h(3115):GLAPI void APIENTRY glTexImage3D (GLenum, GLint, GLint, GLsizei, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid *);

\SDL\SDL_opengl.h(3170):GLAPI void APIENTRY glTexImage3D (GLenum, GLint, GLint, GLsizei, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid *);

Edited July 1, 2007 by Beaverhunter

[ttlanhil]

Adding this:

#ifndef S_ISDIR

#define S_ISDIR(x) (((x) & S_IFMT) == S_IFDIR)

#endif // S_ISDIR

 

To the top of elpathwrapper.c, fixes the first link error.

Now in CVS

The other one is here. Is it bad that it's defined on 2 places like this?

\GL\glext.h(3115):GLAPI void APIENTRY glTexImage3D (GLenum, GLint, GLint, GLsizei, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid *);

\SDL\SDL_opengl.h(3170):GLAPI void APIENTRY glTexImage3D (GLenum, GLint, GLint, GLsizei, GLsizei, GLsizei, GLint, GLenum, GLenum, const GLvoid *);

Multiple declarations, as long as they're the same, should do no harm. However, the fact that it doesn't find find the function in the opengl library when you get to linking is a problem. Either your OpenGL libs don't full support version... 1.1 or 1.2, I think Xaphier said, or you haven't got the linking working properly.

[Grum]

Adding this:

#ifndef S_ISDIR

#define S_ISDIR(x) (((x) & S_IFMT) == S_IFDIR)

#endif // S_ISDIR

 

To the top of elpathwrapper.c, fixes the first link error.

Now in CVS

We have the same sequence in two different files now, perhaps it should be moved to some common header file, braindead.h or even *shudder* global.h.

[ttlanhil]

some common header file, braindead.h or even *shudder* global.h.

My vote is for platform.h, move the platform stuff from global.h. out to there, and #include platform in global.h (All existing code will be unable to tell the difference, new/changed code can limit it self to what's appropriate).

[Grum]

Sounds good.

[Beaverhunter]

From a search:

http://echelog.matzon.dk/logs/browse/opengl/1170343453

 

There a guy have the exact same problem, solved by adding a definition to the "app".

 

What else could I try? I probably have as up to date OpenGL libs as you.

I got these libs linked:

shell32.lib

SDL.lib

opengl32.lib

libxml2.lib

user32.lib

SDL_net.lib

kernel32.lib

ALut.lib

OpenAL32.lib

iconv.lib

cal3d.lib

glu32.lib

vorbisfile.lib

SDL_image.lib

zdll.lib

libpng.lib

ogg.lib

[Alia]

Problem with get_*_after string functions.

(I feel I've said about it already, but I don't remember where

 

These functions call atof/atoi to get number, which do not know where memory buffer ends.

They read until first unacceptable character, and if we call them on strings (0-terminated)

they work correctly. However in out case memory buffer is not 0-terminated.

 

Possible solutions:

1. Always put 0-char after we've read file contents.

2. Always put newline character in the end of files that are parsed using these functions.

 

Edit:

And lets not make obvious memory leaks: init.c:874: get_path_config() allocates memory

Edited July 1, 2007 by Alia

[Florian]

after Grum's last commit:

In file included from pawn/amx.c:57:

pawn/amx.h:45:2: error: #error Invalid cell size for floating point support

In file included from pawn/amxaux.c:26:

pawn/amx.h:45:2: error: #error Invalid cell size for floating point support

In file included from pawn/amxcons.c:48:

pawn/amx.h:45:2: error: #error Invalid cell size for floating point support

In file included from pawn/amxel.h:4,

from pawn/amxel.c:7:

pawn/amx.h:45:2: error: #error Invalid cell size for floating point support

In file included from pawn/amxfloat.h:4,

from pawn/amxfloat.c:24:

pawn/amx.h:45:2: error: #error Invalid cell size for floating point support

In file included from pawn/elpawn.c:3:

pawn/amx.h:45:2: error: #error Invalid cell size for floating point support

 

this can be solved with -DX86_64

 

but then:

actor_scripts.c

In file included from vmath.h:13,

from e3d.h:10,

from global.h:120,

from actor_scripts.c:4:

misc.h:10:19: error: GL/gl.h: No such file or directory

In file included from vmath.h:13,

from e3d.h:10,

from global.h:120,

from 2d_objects.c:7:

misc.h:10:19: error: GL/gl.h: No such file or directory

In file included from vmath.h:13,

from e3d.h:10,

from global.h:120,

from 3d_objects.c:7:

misc.h:10:19: error: GL/gl.h: No such file or directory

 

looks like you forgot about OSX again ...

[Grum]

after Grum's last commit:

My bad, both issues should be fixed

looks like you forgot about OSX again ...

Well, please believe me that this wasn't intentional The first issue would have caused trouble on all 32 bit platforms, not only OSX, and the second was a stupid oversight on my part (I missed the #ifndef OSX while scanning global.h for the gl include).

[ttlanhil]

Problem with get_*_after string functions.

Requiring it to be done correctly elsewhere isn't as safe, so I think I'll make a temp char[] and memcpy to it; null terminate, and then ato[if]() that temp buffer.

And lets not make obvious memory leaks: init.c:874: get_path_config() allocates memory

Well, nuts. Okay, I'll go fix that as well, thanks.

 

ed: Both now done, CVS should be fixed in regards to those problems

Edited July 1, 2007 by ttlanhil

[Florian]

compile problem fixed

[Beaverhunter]

compile problem fixed

 

Quite far it in my case, they keep building up=( Haven't been able to compile CVS for some week or so now.

 

1>asc.c
1>.\asc.c(129) : error C2057: expected constant expression
1>.\asc.c(129) : error C2466: cannot allocate an array of constant size 0
1>.\asc.c(129) : error C2133: 'temp' : unknown size
1>amxel.c
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C2054: expected '(' to follow 'WINGDIAPI'
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C2085: 'APIENTRY' : not in formal parameter list
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C2146: syntax error : missing ',' before identifier 'glAccum'
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C2143: syntax error : missing ';' before '('
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C2059: syntax error : ')'
1>eye_candy_wrapper.cpp
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C2144: syntax error : 'void' should be preceded by ';'
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C2146: syntax error : missing ';' before identifier 'glAccum'
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C2182: 'APIENTRY' : illegal use of type 'void'
1>C:\Program\Microsoft Visual Studio 8\VC\PlatformSDK\include\GL/gl.h(1152) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

The last 2 parts keeps going on for pretty much every identifier. (And yes of course I know that you guys haven't messed with my gl.h and cannot do anything about that but obviously it's ELC code that is causing this, exactly where it is is not showing so this is all I can give you)

 

And also when this gets fixed I assume the previous error with linking will still be there, so has anyone looked into it if they can declare/define glTexImage3D inside some .h or .c file somehow?

Edited July 1, 2007 by Beaverhunter

[Grum]

And also when this gets fixed I assume the previous error with linking will still be there, so has anyone looked into it if they can declare/define glTexImage3D inside some .h or .c file somehow?

No, we can't do that, it should be provided by your opengl library(*). If it isn't, compile without USE_SHADER_COBJ.

 

(*) However, your include files declare glTexImage3D , so it looks like your opengl library is not in sync with the include file

[ttlanhil]

Hopefully the issue in asc.c is now fixed. As for the shaders, just don't USE_SHADERS for now, or fix your OpenGL libs.

[kibora]

@Beaver

 

Add #include <windows.h> to your gl.h file to get rid off the WINGDIAPI and APIENTRY problem

[Beaverhunter]

Oki the asc.c got fixed... the other remains...

 

The problem is that I'm NOT even using USE_SHADER!, I just tried with it and I got same error... so it doesn't seem to be related.

 

I didn't get this error from just a day ago (as you have seen I reported only LNK error before, now I got all that gl.h crap after some recent change you made).

 

Update:

Kibora:

Oki I'll try that, going for a walk now though.

Edited July 1, 2007 by Beaverhunter

[ttlanhil]

Okay, remove shader/* from your build structure if you're not using USE_SHADER. They shouldn't be compiled if you don't USE_SHADER.

I'll #ifdef guard the files in CVS, but that's the reason you get the error.

Of course, shaders are a good thing, so if you can get support for them it'd be good... Hey, waitamin... You compile with headers from the (newer) PlatformSDK, but link with the (old) OpenGL libs that came with your system? That may be the problem...

[Beaverhunter]

Oki, the gl.h errors are fixed, thanks Kibora. But this is a LOCAL solution, whenever someone tries to compile with MSVS 2k5 it will happen again so this is a BAD solution, but well at least some progress.

 

ttlanhil:

If you are talking about gl.h being "out of date" then maybe so but I doubt it.

If you are talking about glext.h being out of date then I doubt it even more, I probably got the same version as anyone else of you, a definition of the missing glTexImage3D is in that file aswell as in SDL_opengl.h, as I showed in my post before, glext.h is not a PlatformSDK include, it was downloaded and put into ELC lib.

 

Or are you talking about opengl32.lib ?

 

But as I also posted before, the guy on that link had exactly the same problem, it was solved by defining it inside the code somewhere. How to do this exactly is nothing I can tell you right now, you probably have much more of a clue on how to do this. And if you are afraid of that it might interfer with something just do the def inside a #ifdef MSVS.

 

Update:

Oki, I took away all the shader stuff and having gl.h including windows.h and it compiles. First the client just exited on load though but I checked the error log and it turned out I needed a data dir specified?

I have read something about it elsewhere on the forum but well what is it really good for to have a data dir? Why would anyone have eternallands.exe in another directory? Lazyness of some sort?

Edited July 1, 2007 by Beaverhunter

[ttlanhil]

Oki, the gl.h errors are fixed, thanks Kibora. But this is a LOCAL solution, whenever someone tries to compile with MSVS 2k5 it will happen again so this is a BAD solution, but well at least some progress.

Well that's all sorts of funky then. Your header file is broken.

Theoretically, #include'ing windows.h before we #include gh.h should fix this... But that's already done in global.h, so you shouldn't be having this problem unless it's in a file that doesn't do the includes (which files, exactly, present this problem?)

ttlanhil:

If you are talking about gl.h being "out of date" then maybe so but I doubt it.

<snip>

Or are you talking about opengl32.lib ?

The second. Your headers are new because you updated them or they came in the PlatformSDK, but the library is possibly older and doesn't support everything it should (or perhaps you need to link in additional libraries; though I don't see why it would be separate).

 

I could certainly declare the function, but that's bad form and leads to future problems.

Edited July 1, 2007 by ttlanhil

[crusadingknight]

I have read something about it elsewhere on the forum but well what is it really good for to have a data dir? Why would anyone have eternallands.exe in another directory? Lazyness of some sort?

So that you don't have to be in the directory to execute it? Not all operating systems stick the executable into a folder along with the data - *nix systems generally put them in /bin or /usr/bin, where the executable can be called from anywhere (much like System32 on a windows machine).

Here, I'd run 'el', which is located in /usr/bin, while my data is actually located in /usr/share/eternallands . On windows, I could theoretically have something like this as well.

Edited July 1, 2007 by crusadingknight