OpenMW 0.22.0

[pvdk]

What about cleaning cache?

Tried that. :/ Didn't help. It's ok, it's not really a big deal.

It's a server-side cache thing

[corristo]

Thanks corristo, I've updated this everywhere that I can. If anyone's done any PR work with the original release announcement, you might consider going back to make an edit.

Thanks, I updated russian translation of release post.

[psi29a]

Just managed to build OpenMW 0.22.0 on Ubuntu Raring (13.04) and is now available on PPA. Please test!

[psi29a]

I know that Raring isn't to be released until next month, so this might be a bug, but I just want to run it past you guys first. The build for OpenMW failed with this:

[ 76%] Building CXX object apps/openmw/CMakeFiles/openmw.dir/engine.cpp.o
Linking CXX executable ../../openmw
/usr/bin/ld: /usr/lib/gcc/i686-linux-gnu/4.7/../../../../lib/libOgreMainStatic.a(OgreDynLib.cpp.o): undefined reference to symbol 'dlopen@@GLIBC_2.1'
/usr/bin/ld: note: 'dlopen@@GLIBC_2.1' is defined in DSO /lib/i386-linux-gnu/libdl.so.2 so try adding it to the linker command line
/lib/i386-linux-gnu/libdl.so.2: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

The log can be found here:
https://launchpadlibrarian.net/13520703 ... ILD.txt.gz

I'm able to "fix" this by adding "-ldl" to the list of linked libraries and ${CMAKE_DL_LIBS} somewhere in a target_link_libraries() but I'm not sure where yet.

We are apparently not the only ones having this problem:
https://gist.github.com/kwk/3595733

What do you guys think?

I found the "real" reason for this, have a read about it here:

Spoiler: Show

2009-11-02 Packages failing because binutils-gold/indirect linking

Some packages fail to build with binutils-gold due to undefined reference. This is in most cases the problem that your executable links against a library A which links against library B, but your executable needs symbols in library B. This is problematic in the situation where library A removes its dependency to library B. The next time the executable gets rebuild it will break and cannot be linked.

This doesn't affect the created executable as it will still have entries in DT_NEEDED for both library A and library B in the case of an successful build. It isn't known which will be the preferred linker in the future or if the behavior will be changed in GNU ld or GNU gold. As the debian buildd's still use the original GNU ld the bugs aren't release critical and it is sufficient to inform upstream.

All packages can be fixed by adding the needed library which provides the symbols to the linker call. In some cases the pkg-config file of library A could be broken as it requires library B for the build. This could be the case if the executable doesn't use library B directly in its source code, but library A inserts the symbols of library B using defines or other similar mechanisms inside their header files to executable, but hasn't the correct Requires statement inside the .pc file of library B.

A common problem seems to be calls to XOpenDisplay without directly linking to -lX11, but to a library like Xtst. Similar is to use glib2.0, but only linking to gtk2.0: using libm, but not linking to it; libqt*, but only linking to kdecore. Another interesting problem is that some program links its C++ object files using gcc instead of g++, but the g++ symbols get resolved by another C++ library they link to.

This problem can be seen when either giving parameter --no-add-needed to the linker (-Wl,--no-add-needed when linking either through gcc or g++) or installing binutils-gold_2.20-1.

A discussion about that issue can be found at http://lists.debian.org/debian-devel/20 ... 00099.html

Summation: our 'temp' fix is actually the real fix. OpenMW and omwlauncher need -ldl and -lXt to be passed in at link time, likely opencs as well.

[corristo]

Hey mac guys!

It'd be awesome if someone could test 0.23 build before publishing it: https://www.dropbox.com/s/uzbs2qfr5sacc ... mg?v=1rw--

[psi29a]

Hey mac guys!

It'd be awesome if someone could test 0.23 build before publishing it: https://www.dropbox.com/s/uzbs2qfr5sacc ... mg?v=1rw--

Wrong thread possibly?

[corristo]

Exactly. I will repost, delete please.

[fstp]

I tried compiling this on win7 (qemu/kvm) following my same setup for winxp and I got as far as compiling everything except for openmw. It failed with this:

Code: Select all

1>------ Build started: Project: ZERO_CHECK, Configuration: Release Win32 ------
2>------ Build started: Project: openmw, Configuration: Release Win32 ------
2>  videoplayer.cpp
2>..\..\..\openmw\apps\openmw\mwrender\videoplayer.cpp(128): error C3861: 'av_gettime': identifier not found
2>..\..\..\openmw\apps\openmw\mwrender\videoplayer.cpp(718): warning C4245: 'initializing' : conversion from 'int64_t' to 'uint64_t', signed/unsigned mismatch
2>..\..\..\openmw\apps\openmw\mwrender\videoplayer.cpp(959): error C3861: 'av_gettime': identifier not found
========== Build: 1 succeeded, 1 failed, 4 up-to-date, 0 skipped ==========

Any ideas?

Sorry for bumping the thread just wanted to say that I ran into the same problem and it seems that FFmpeg broke backwards compability by moving av_gettime() into a new header file time.h and then later on also removing it from avformat.h

Moving to time.h: https://github.com/FFmpeg/FFmpeg/commit ... 728181b0dd
Removing from avformat.h: https://github.com/FFmpeg/FFmpeg/commit ... b8a47c650e

[psi29a]

I saw your commit, thanks! It is nice to keep backward compatibility with such a fast moving target as ffmpeg.