Ryzom

Hello Robert,

the fast and dirty way which should solve it for you is to change in code/CMakeModules/FindLibwww.cmake:

FIND_WWW_LIBRARY(LIBWWWCACHE_LIBRARY OPTIONAL wwwcache) # core trans utils
FIND_WWW_LIBRARY(LIBWWWSTREAM_LIBRARY OPTIONAL wwwstream) # core file utils

To:

FIND_WWW_LIBRARY(LIBWWWCACHE_LIBRARY REQUIRED wwwcache) # core trans utils
FIND_WWW_LIBRARY(LIBWWWSTREAM_LIBRARY REQUIRED wwwstream) # core file utils

But since it should work out of the box it would be cool if you create an issue for that (shortly describing the problem and your system setup).

Hope that helps.

Thanks for the reply rti,

Making the above changes helped some, but it appears there may still be more wrong with my libwww install or setup. The new output from make is below:

[ 87%] Building CXX object ryzom/client/src/CMakeFiles/ryzom_client.dir/interface_v3/action_handler_help.cpp.o
Linking CXX executable ../../../bin/ryzom_client
/usr/local/lib/libwwwcore.a(HTWWWStr.o): In function `HTMessageIdStr':
/home/robert/w3c-libwww-5.4.0/Library/src/HTWWWStr.c:360: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usr/local/lib/libwwwcore.a(HTInet.o): In function `HTGetTmpFileName':
/home/robert/w3c-libwww-5.4.0/Library/src/HTInet.c:621: warning: the use of `tempnam' is dangerous, better use `mkstemp'
/usr/local/lib/libwwwcache.a(HTCache.o): In function `CacheEvent':
/home/robert/w3c-libwww-5.4.0/Library/src/HTCache.c:2410: undefined reference to `HTFileOpen'
collect2: ld returned 1 exit status
make²: * [bin/ryzom_client] Error 1
make¹: [ryzom/client/src/CMakeFiles/ryzom_client.dir/all] Error 2
make: ** [all] Error 2

cmake also had some anomalies...

-- Warning: Libwww: Library not found: LIBWWWZIP_LIBRARY
-- Warning: Libwww: Library not found: LIBWWWSSL_LIBRARY
-- Warning: Libwww: Library not found: LIBREGEX_LIBRARY
/usr/bin/objdump: HTAccess.o: not a dynamic object
/usr/bin/objdump: HTDialog.o: not a dynamic object
/usr/bin/objdump: HTEvtLst.o: not a dy...
...
/usr/bin/objdump: HTRules.o: not a dynamic object
-- Found MySQL: /usr/include/mysql, optimized;/usr/lib/libmysqlclient.so
-- Configuring done
-- Generating done
-- Build files have been written to: /home/robert/ryzom/code/build

I am sure it is all my fault but as I am not used to Linux this is all a bit confusing. I will probably format and start again with Ubuntu instead of Mint, just to make sure I am doing everything by the book.

Thanks for your time,

Robert

I have no idea why CMake is mentioning that.

For the first part, basically, you need to set the libraries containing the missing symbols from OPTIONAL to REQUIRED in FindLibwww.cmake.

Which symbol is contained in which library can be detected using this small script:

#!/bin/sh

LIBS_ARE_IN="/opt/local/lib" 
LOOKING_FOR="HTFileOpen" 

for i in `find ${LIBS_ARE_IN} -name "libwww*"` 
do
    echo "------------------------------------------------------------------" 
    echo "Looking in ${i}" 
    nm -U ${i} | grep ${LOOKING_FOR}
done

Update LIBS_ARE_IN to the path you installed libwww in (e.g. /usr/local/lib) and LOOKING_FOR to the symbol the linker cannot find. E.g. "HTFileOpen".

If this is too much work, you can also try to just set all OPTIONAL to REQUIRED (except those CMake cannot find on your system LIBWWWZIP_LIBRARY, LIBWWWSSL_LIBRARY and LIBREGEX_LIBRARY)

Little background: libwww is split into lots of small library files. Normally, a library A depending on a library B should link it explicitly. But current libwww distributions fail to do so. So if you need lib A which in turn needs lib B it is not automatically linked which leads to the problems you are currently in. Kervala already built some logic detecting this shortcoming automatically, but for some reason it seems not to work on your system :(

Looks like it is install Ubuntu time :(

I tried the script (I assumed 'U' was meant to be lower case and changed it). Example of the output below:

------------------------------------------------------------------
Looking in /usr/local/lib/libwwwfile.a
U HTFileOpen
------------------------------------------------------------------
Looking in /usr/local/lib/libwwwfile.la
nm: /usr/local/lib/libwwwfile.la: File format not recognized

Looks like it appears in 2 places, both are set to REQUIRED.

I set everything to REQUIRED (except the 3 missing ones) and it made no difference.
I modified the script to search through the w3c-libwww-5.4.0/library/src files (.c .h .o etc) just out of curiosity and it seems to be hidden away in HTFile.o (which I don't know how to view).

If that made any sense to you then I am impressed :)

I will play around for a while if no luck I will reinstall at the end f the week.

Looks like it is install Ubuntu time :(

Hmm. Should work on your distribution as well...

I tried the script (I assumed 'U' was meant to be lower case and changed it). Example of the output below:

Sorry, i am using Apple's nm, so the options differ a bit :(

------------------------------------------------------------------
Looking in /usr/local/lib/libwwwfile.a
U HTFileOpen

My -U option for nm removes all "undefined" symbols, just listing those from the text/code section of the binary.

So you could change the line calling nm in the script to

    nm ${i} | grep ${LOOKING_FOR} | grep "T " 

------------------------------------------------------------------
Looking in /usr/local/lib/libwwwfile.la
nm: /usr/local/lib/libwwwfile.la: File format not recognized

Could be just ignored.

Looks like it appears in 2 places, both are set to REQUIRED.

It should only be implemented in one library (T), but can be referenced in several other places (U).

I set everything to REQUIRED (except the 3 missing ones) and it made no difference.

That is really strange...

I modified the script to search through the w3c-libwww-5.4.0/library/src files (.c .h .o etc) just out of curiosity and it seems to be hidden away in HTFile.o (which I don't know how to view).

You should only try to search in the resulting library files because this are those you want to link in the end.

I hope changing the call to nm brings some light into darkness...

Right, fresh start :)

I hope it is OK to continue this thread with my slow progress?

I have reinstalled Linux Mint 10 (32 bit this time). I wasn't completely happy that everything was untouched, it was my first Linux install and I had played around with it to learn.

I have followed the instructions on http://dev.ryzom.com/wiki/ryzom/BuildForLinuxCmake as closely as I could, all seemed to go OK.

I used sudo apt-get update and sudo apt-get install libwww-dev which seemed to work. Everything else went without a hitch.

"Before continuing make sure you have installed the packages you just generated earlier" I took to mean Luabind, libwww etc so all OK there.

I get to cmake -DWITH_NEL_TESTS=OFF ..
This is the output:

-- DEBUG size_t is 4
-- DEBUG off_t is 4
-- Found Squish: optimized;/usr/local/lib/libsquish.a
-- Found Luabind: /usr/lib/libluabind.so
-- Warning: Libwww: Library not found: LIBWWWSSL_LIBRARY
-- Warning: Libwww: Library not found: LIBREGEX_LIBRARY
CMake Error at CMakeModules/CheckDepends.cmake:68 (GET_FILENAME_COMPONENT):
get_filename_component unknown component /usr/lib/libcrypto.so
Call Stack (most recent call first):
CMakeModules/CheckDepends.cmake:113 (CHECK_LINKED_LIBRARY)
CMakeModules/FindLibwww.cmake:77 (LINK_DEPENDS)
CMakeModules/FindLibwww.cmake:149 (LINK_WWW_LIBRARY)
ryzom/CMakeLists.txt:11 (FIND_PACKAGE)

-- Found MySQL: /usr/include/mysql, optimized;/usr/lib/libmysqlclient.so
-- Configuring incomplete, errors occurred!

I am not really sure what is throwing up the error, is it the Libwww stuff again or is it libcrypto.so?

Any advice greatly appreciated, as is all the help you have given me so far. I hope I can repay the help by being helpful to the Ryzom Dev community one day :)

You got a call stack in the output.

Call Stack (most recent call first):
CMakeModules/CheckDepends.cmake:113 (CHECK_LINKED_LIBRARY)
CMakeModules/FindLibwww.cmake:77 (LINK_DEPENDS)
CMakeModules/FindLibwww.cmake:149 (LINK_WWW_LIBRARY)
ryzom/CMakeLists.txt:11 (FIND_PACKAGE)

So our CMakeLists.txt calls FindLibwww.cmake which in turn calls CheckDepends.cmake.

Is the file /usr/lib/libcrypto.so available on your system?

libcrypto.so is there along with the .a .pc and .so.0.9.8 files.

Quick web search tells me they are part of a libssl-dev package which is installed also.

Edit, seems this error has been seen before, haven't found a solution yet though. Seems Kervala and Naush were discussing it:
http://ircanswers.com/ryzom/573419/ryzom-discussion-bughii-clientclient-httpdevryzomcomboards16topics4305r4315message-4315

Well, this seems to be a problem in the script detecting necessary libwww libraries.

The error gets thrown at CheckDepends.cmake line 68 which reads:

 GET_FILENAME_COMPONENT(LIBNAME ${${OTHERLIBRARY}} NAME)

The ${${OTHERLIBRARY}} part looks a bit suspicious. Could you try to exchange the line with

 GET_FILENAME_COMPONENT(LIBNAME ${OTHERLIBRARY} NAME)

or:

 GET_FILENAME_COMPONENT(LIBNAME "${OTHERLIBRARY}" NAME)

BTW. which CMake version are you using?

Good luck :)

Ok, i think the thing above was bullshit.
The double ${} makes indeed sense :) Sorry for that.

I think replacing it with the code I posted will not help.
I have no idea why GET_FILENAME_COMPONENT is failing on /usr/lib/libcrypto.so.

Maybe you could try to replace CheckDepends.cmake line 68 with:

 GET_FILENAME_COMPONENT(LIBNAME "${${OTHERLIBRARY}}" NAME)

As reported by Solitude the last suggestion helped, see #1248, applied in r1322.