Jump to content
Eternal Lands Official Forums
Wind_of_Change

Current CVS errors (1.9.1)

Recommended Posts

Just something minor: When compiling the client with PNG_SCREENSHOT defined I get deprecation warnings. These small modifications should fix them.

diff -u -r1.83 misc.c
--- misc.c	12 Jul 2010 20:28:25 -0000	1.83
+++ misc.c	29 Dec 2010 15:43:16 -0000
@@ -311,7 +311,7 @@
	}

	/* Set error handling. */
-	if (setjmp(png_ptr->jmpbuf))
+	if (setjmp(png_jmpbuf(png_ptr)))
	{
		/* If we get here, we had a problem reading the file */
		IMG_SetError("Error writing the PNG file");
@@ -360,8 +360,8 @@
	if (row_pointers != NULL)
		free (row_pointers);

-	if (info_ptr != NULL && info_ptr->palette != NULL)
-		free (info_ptr->palette);
+	if (info_ptr != NULL)
+		png_free_data(png_ptr, info_ptr, PNG_FREE_ALL, -1);

	png_destroy_write_struct (&png_ptr, (png_infopp)NULL);

Share this post


Link to post
Share on other sites

Just something minor: When compiling the client with PNG_SCREENSHOT defined I get deprecation warnings. These small modifications should fix them.

diff -u -r1.83 misc.c
--- misc.c	12 Jul 2010 20:28:25 -0000	1.83
+++ misc.c	29 Dec 2010 15:43:16 -0000
@@ -311,7 +311,7 @@
	}

	/* Set error handling. */
-	if (setjmp(png_ptr->jmpbuf))
+	if (setjmp(png_jmpbuf(png_ptr)))
	{
		/* If we get here, we had a problem reading the file */
		IMG_SetError("Error writing the PNG file");
@@ -360,8 +360,8 @@
	if (row_pointers != NULL)
		free (row_pointers);

-	if (info_ptr != NULL && info_ptr->palette != NULL)
-		free (info_ptr->palette);
+	if (info_ptr != NULL)
+		png_free_data(png_ptr, info_ptr, PNG_FREE_ALL, -1);

	png_destroy_write_struct (&png_ptr, (png_infopp)NULL);

This came up a while ago but I could not find out if the free was needed. I presume the call to png_free_data() resolved that issue?

Share this post


Link to post
Share on other sites

I also don't think that there is actually anything to free, but according to the libpng manual png_free_data does do the job and in the case that there is nothing to free it will do nothing. But I'm no expert in this subject as well...

OK, I've committed this change. Thanks.

Share this post


Link to post
Share on other sites

The previous thread was getting rather long so how about starting a new one for each new release? I've moved the last few posts from that thread here in case anyone was wondering what happened.

Edited by bluap

Share this post


Link to post
Share on other sites

The open storage from inventory context menu seems to be broken.

Oops :blush: Thanks, fixed now. All similar menu options were broken a day or so ago.

Edited by bluap

Share this post


Link to post
Share on other sites

I also don't think that there is actually anything to free, but according to the libpng manual png_free_data does do the job and in the case that there is nothing to free it will do nothing. But I'm no expert in this subject as well...

OK, I've committed this change. Thanks.

 

Not sure if it makes a difference, but a Gentoo dev sent me the following alternative patch for the same problem. Half of it is identical to what is now in CVS, but the second half modifies the call to png_destroy_write_struct.

 

If CVS builds as-is with libpng 1.5 I'll avoid applying a Gentoo-specific patch, but I figured I'd post this in case there is something worth looking at:

 

Index: elc/misc.c
===================================================================
--- elc.orig/misc.c
+++ elc/misc.c
@@ -311,7 +311,7 @@ int IMG_SavePNG_RW (SDL_Surface *face, S
	}

	/* Set error handling. */
-	if (setjmp(png_ptr->jmpbuf))
+	if (setjmp(png_jmpbuf(png_ptr)))
	{
		/* If we get here, we had a problem reading the file */
		IMG_SetError("Error writing the PNG file");
@@ -360,10 +360,7 @@ done:
	if (row_pointers != NULL)
		free (row_pointers);

-	if (info_ptr != NULL && info_ptr->palette != NULL)
-		free (info_ptr->palette);
-	
-	png_destroy_write_struct (&png_ptr, (png_infopp)NULL);
+	png_destroy_write_struct (&png_ptr, &info_ptr);

	return result;
}

Share this post


Link to post
Share on other sites

Trying to compile with static make parameter i get:

make[1]: *** No rule to make target `/usr/lib/libopenal.a', needed by `el.x86.linux.bin'.  Stop.
make[1]: Leaving directory `/home/korrode/el_git/elc.20110517-1-new_textures-static/elc'
make: *** [static] Error 2

Share this post


Link to post
Share on other sites

You need to have libopenal installed in the /usr/lib directory. On FreeBSD, these library are on the /usr/local/lib directory. You can try :

 

ls /usr/lib | grep libopenal
ls /usr/local/lib | grep libopenal

 

If you find them on a other directory, or if the name is different, you will have to modify the makefile. :)

Share this post


Link to post
Share on other sites

AFAIK, the static build is only known to work out of the box on Ubuntu 8.04. If you look in Makefile.linux, you'll find details of which -dev libraries you'll need. Currently, it does not work for clean git as the FSAA feature uses new GL features not supported by Ubuntu 8.04. However, if you disable that feature it will compile. I'm not looking forward to getting the static build to work on a newer version of Linux. :(

Edited by bluap

Share this post


Link to post
Share on other sites
You need to have libopenal installed in the /usr/lib directory. On FreeBSD, these library are on the /usr/local/lib directory. You can try :

 

ls /usr/lib | grep libopenal
ls /usr/local/lib | grep libopenal

 

If you find them on a other directory, or if the name is different, you will have to modify the makefile. :)

The libraries are installed and in the correct location, i'll play more later.

ah wait, i only have .so runtime libraries, i'll get .a's for static linking.

 

 

AFAIK, the static build is only known to work out of the box on Ubuntu 8.04.

Sounds like a challenge.

Edited by Korrode

Share this post


Link to post
Share on other sites

Ok so, after reproducing a number of ArchLinux packages to either:

A. add options to also compile static libraries (as the upstream default was to not)

- or -

B. remove options that prevent static libraries from being compiled (added by Arch packagers)

 

...I've gotten pretty damn close.

 

I have a binary that works fine with the following libraries included statically:

 

libm

libxml2

libz

libSDL_net

libSDL_image

libopenal

libcal3d

libpng

libvorbisfile

libvorbis

libogg

librt

 

...and I could include libGLU too, but from what i've been reading and due to some other factors, it may be better not to.

 

The one thing that so far I can't get compiling in is the base libSDL. Well, I can get it to compile, but it segfaults immediately when attempting to execute.

 

I tried including libdl as well which i saw reported to work for compiling binaries with SDL statically included, but so far no good.

 

Anyways i'll get back to it tomorrow. :)

 

To get the static binary with everything but libSDL the following works, provided you have all the required libraries in static-linking (.a) format.

_LDFLAGS=$(shell sdl-config --libs) -lGL -lGLU

LIBD=/usr/lib
STATICLIBS=$(LIBD)/libm.a $(LIBD)/libxml2.a $(LIBD)/libz.a $(LIBD)/libSDL_net.a $(LIBD)/libSDL.a $(LIBD)/libSDL_image.a $(LIBD)/libopenal.a $(LIBD)/libcal3d.a $(LIBD)/libpng.a $(LIBD)/libvorbisfile.a $(LIBD)/libvorbis.a $(LIBD)/libogg.a $(LIBD)/librt.a

Edited by Korrode

Share this post


Link to post
Share on other sites

compile error with latest git on windows:

engine/logging.cpp:17:17: fatal error: ftw.h: No such file or directory
compilation terminated.

seems it's not available on Windows, Mac and BSD

GNU Gnulib

Share this post


Link to post
Share on other sites

compile error with latest git:

textures.c: In function 'init_texture_cache':
textures.c:2147:2: warning: passing argument 1 of 'cache_init' makes pointer from integer without a cast
cache.h:120:15: note: expected 'const char *' but argument is of type 'int'
textures.c:2147:2: error: too few arguments to function 'cache_init'
cache.h:120:15: note: declared here

if you fix that (add cache name), linking fails:

/libelc.a(asc.o):asc.c:(.text+0x39): undefined reference to `memmem'

MinGW and some other platforms have no memmem implementation

GNU Gnulib

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×