Mutual GNU / Linux


uiWebPrevious1234uiWebNext

#40 [en] 

I have been attempting to make a working build for 2 days now, and am at a complete loss for what else to try.

I have successfully compiled the client about 10 different ways and tried the branches develop, compatibility, compat-dev. and default all with the same results. I can login and select my character, the loading sequence goes for a short ways and then the client crashes.

Some details on the error are:
A fatal error occurs. The program must quit
ProcName: <Unknown>
File: /ryzom-ryzomcore-5c9146c667c1/code/nel/src/gui/interface_parser.c pp
Line: 587
FuncName: parseXMLDocument
Reason: could not parse 'lua'
-------------------------------
User Crash Callback:
-------------------------------
HomeId: 101
ShardId: 101
On a Mainland Shard
Application: ryzom_live
No user entity information
ViewPosition: 0.00 0.00 0.00
LocalTime: 2015/08/02 21:49:56
ServerTick: 1021771984
ConnectState: Connected
Language: English
ClientVersion: ryzomcore/v0.12.0-dev
PatchVersion: 610
Client is online
NumServerHOP: 0
NumFarTP: 0
NumReselectPerso: 0
Connection Events:
Memory: 13GB/15GB
Process Virtual Memory: 0B
OS: Linux version 3.16.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u2 (2015-07-17)
Processor: AMD FX(tm)-8350 Eight-Core Processor / ? Family 21 Model 2 Stepping 0 / AuthenticAMD / 1400.000MHz / 3 Processors found
CPUID: 0
HT: NO
CpuMask: ff
NeL3D: OpenGL / X.Org / Gallium 0.4 on AMD OLAND / 3.0 Mesa 10.3.2
No sound


In compiling I found that the luabind library requires lua5.2, so I explicitly selected that version of lua from the 2 versions that are installed on my system. Not making that selection had the same results.

No combination of static or dynamic linking choices about lua and luabind have made a difference. I took to manually editing the link.txt file to control the static/dynamic linkage of each system library.

I have had to build curl, libxml2, and openal from source code in order to get them to behave properly.

Can anyone suggest anything else to try? Do I have to build my own lua and luabind; or maybe the error has nothing to do with lua?!

#41 [en] 

Abekomdf (atys)
Can anyone suggest anything else to try? Do I have to build my own lua and luabind; or maybe the error has nothing to do with lua?!
There should be more detailed error before that line in log file.

---

Hello!

#42 [en] 

There is a lot of stuff in between the parts I already posted. Most of it seems to match logging generated by a working executable, specifically the one found here.

The only other lines that appear to have potential relevance are:
2015/08/02 21:49:56 <Unknown> INF e689a740 common.cpp 615 : Exception will be launched: interaction.lua:134: attempt to call field 'mod' (a nil value)
2015/08/02 21:49:56 <Unknown> WRN e689a740 interface_parser.cpp 2863 : ELuaExecuteError: interaction.lua:134: attempt to call field 'mod' (a nil value)
2015/08/02 21:49:56 <Unknown> ERR e689a740 interface_parser.cpp 587 : could not parse 'lua'

#43 [en] 

Abekomdf (atys)
The only other lines that appear to have potential relevance are:
Exception will be launched: interaction.lua:134: attempt to call field 'mod' (a nil value)
have you updated ryzom files using ryzom_update.sh script? it also overwrites ryzom_client binary, so you need to restore it if your own compiled version is named the same

---

Hello!

#44 [en] 

I placed Icus's executable and mine in the same location where the original 32bit client had been extracted. I ran each and compared the logs. There were no updates in between that comparison.

#45 [en] 

Abekomdf (atys)
I placed Icus's executable and mine in the same location where the original 32bit client had been extracted. I ran each and compared the logs. There were no updates in between that comparison.

There should be ryzom_update.sh script.

If it's missing, then this is what it contains
rsync -rtzv --progress --stats www.ryzom.com::ryzom ./

---

Hello!

#46 [en] 

I think we are failing to communicate here.

My system is a nice new Debian 8.1 (Jessie) amd64. It can not run the 32 bit ryzom binary that the ryzom_update.sh pulls.

I built close to 30 different binary configurations involving controlling specific library versions, combinations of static/dynamic linking, and 4 different branches of ryzomcore. They ALL crashed at the same place with the same message.

I tried the binary posted by Icus that I referenced earlier and it ran fine.

The problem is something difference in how I am building the binaries or specific libraries and that is what I am looking for help on.

#47 [en] 

Abekomdf (atys)
The problem is something difference in how I am building the binaries or specific libraries and that is what I am looking for help on.
run the updater.

---

Hello!

#48 [en] 

Did it, got more files patched when I ran a ryzom binary. My build still crashes at the same loading step. This time it didn't output the fancy nel_log with all the extra data. I compared log.log for runs by my current build and Icus's and found they were the same up to the crash. The last messages in the crashing log are different than before the update:
2015/08/03 07:18:30 WRN 2029074240 <Unknown> path.cpp 579 lookup : PATH: File (r2_entry_points.txt) not found (r2_entry_points.txt)
2015/08/03 07:18:30 INF 2029074240 <Unknown> common.cpp 615 Exception : Exception will be launched: Path not found for r2_entry_points.txt

#49 [en] 

Abekomdf (atys)
2029074240 <Unknown> path.cpp 579 lookup : PATH: File (r2_entry_points.txt) not found (r2_entry_points.txt)

You running binary from 'default' branch it seems.

I believe creating empty file with that name under 'user' directory should get thru that error. 'compatibility' branch (and ryzom files) has that file named as 'ring_map_entry_ponts.txt'

---

Hello!

#50 [en] 

That binary was built from the "develop" branch. Specifically by downloading the source at https://bitbucket.org/ryzom/ryzomcore/get/5c9146c667c1.zip

The problem is most likely a memory corruption caused by different library builds having a sizing difference.

I have since managed to stick another monkey wrench into this system. It always happens when I am working with a new system. So I can't build anything else for testing until I go through reinstalling all of it. See you in a few days.

#51 [fr] 

If you create an empty file called r2_entry_points.txt in the ryzom/user directory, that problem will go away.

#52 [en] 

Karu was right about the problem being the branch I had selected. I was able to get the "compatibilty" branch to build in my new setup and it ran correctly. I then spent some time researching the differences and was able to build from nimetu's fork with the compatibilty changes manually merged.

That combination gives me a nice snappy client without the libwww crap. I reduced the dynamic libraries down to just a few that would seem to be present on any linux system. The size is a bit smaller than Icus's build which seemed to be from the same fork and merge method. I would attribute that to building all the libraries for it from scratch with options that remove extra sections. There are even a few more protocols I could eliminate from libcurl.

After I spend a fair bit of time testing it in game I will post a full shell script to get and build everything.

#53 [en] 

Abekomdf (atys)
That combination gives me a nice snappy client without the libwww crap

There is compatibility-develop branch that tracks develop more closely and has libwww removed.

---

Hello!

#54 [en] 

I didn't see anyone mention the following, and I might have missed it, but did you install the 32-bit architecture?

dpkg --add-architecture i386

Just asking

---

I need me a new tag line on my messages!
uiWebPrevious1234uiWebNext
 
Last visit Wednesday, 27 November 20:25:45 UTC
P_:G_:PLAYER

powered by ryzom-api