Jump to content

nelsoncs

Members
  • Content Count

    31
  • Joined

  • Last visited

Community Reputation

3 Neutral

About nelsoncs

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling
  • Location
    Portland, Oregon
  1. This failed with the error: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by ...) sudo apt install libcurl3 must also be installed.
  2. beta latest build installs wrong libraries (as of Nov 27, 2015) update to the latest and the leadwerks.a that is installed is a 32 bit i386 binary which is wrong for an x64 system. revert to the 2015-07 beta, everything seems fine, Leadwerks.a is the elf_x64 version system is ubuntu 15.10 on an x64 platform. please let me know if I can provide any pertinent info. see also: http://www.leadwerks.com/werkspace/topic/13757-incompatible-libleadwerksa/
  3. moved the .steam directory to a backup, reinstalled steam from scratch and now the lib is x64. still don't know why the heck steam decided to move me to 32 bit but... don't care now. Thanks for steering me in the right direction, aiaf. Submitted as bug report.
  4. so, you are right except I have no idea why I have ended up with an i386 version of the leadwerks.lib. I have a backup from the leadwerks 3.2 era (before the full steam integration) and : objdump -a '~/src/Leadwerks_3_2/Library/Linux/Debug/Leadwerks.a' In archive ~/src/Leadwerks_3_2/Library/Linux/Debug/Leadwerks.a: Address.o: file format elf64-x86-64 rw-rw-r-- 1000/1000 96864 Sep 18 09:40 2014 Address.o I also tried having Steam perform the "validate cache" on my .steam install and it wants to replace 5090 files, if allowed to do this, it will still consider them invalid and rinse, repeat. So, it seems like it is possiblethis is really a problem with my steam installation
  5. objdump -a ./libLeadwerks.a In archive ./libLeadwerks.a: Address.o: file format elf32-i386 rw-rw-r-- 1000/1000 70748 Sep 22 12:51 2015 Address.o (deleted rest of output) objdump -i '/home/develop/.steam/steam/SteamApps/common/Leadwerks Game Engine/Library/Linux/Debug/Leadwerks.a' BFD header file version (GNU Binutils for Ubuntu) 2.25.1 elf64-x86-64 (header little endian, data little endian) i386
  6. Thanks, yes I already checked with objdump and elf64-x86-64 was top of the list. Linux: Ubuntu 15.10 uname -a: Linux higgie 4.2.0-18-generic #22-Ubuntu SMP Fri Nov 6 18:25:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux gcc: g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.2.1-22ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2)
  7. Anyone have a clue how this has foobar'd for me? 1. updated through steam -> no effect 2. clean build -> no effect -lRakNetDLL (/home/<usr-name>/src/RakNet_PC-4.08/Lib/DLL/libRakNetDLL.so) -lopenal (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libopenal.so) -lGL (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libGL.so) -lGLU (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libGLU.so) -lsteam_api (/home/<usr-name>/.steam/steam/SteamApps/common/Leadwerks Game Engine/Library/Linux/libsteam_api.so) -lX11 (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libX11.so) /lib/x86_64-linux-gnu/libpthread.so.0 /usr/bin/ld: skipping incompatible /home/<usr-name>/.steam/steam/SteamApps/common/Leadwerks Game Engine/Library/Linux/Debug/libLeadwerks.a when searching for -lLeadwerks /usr/bin/ld: cannot find -lLeadwerks collect2: error: ld returned 1 exit status makefile:60: recipe for target 'Server' failed make: *** [server] Error 1 Thanks.
  8. Actually, my games seg fault every time they exit: ...(bunch of stuff) Deleting shader "/home/develop/src/boson_life/Shaders/Editor/wireframe.shader" Deleting sound "<some_sound_file.wav>" AL lib: (EE) alc_cleanup: 1 device not closed Segmentation fault (core dumped) Which is probably harmless, but it does not look very good if I ever distributed a game. I have always assumed that it was the AL lib, so I ran under valgrind to confirm. (really lot of valgind output) ==3542== Conditional jump or move depends on uninitialised value(s) ==3542== at 0x7C165D: Leadwerks::NewtonDynamicsCharacterController::ProcessCollisions(Leadwerks::Vec3 const&, Leadwerks::Vec3 const&, Leadwerks::PickInfo&) (NewtonDynamicsCharacterController.cpp:879) ==3542== by 0x7C14A9: Leadwerks::NewtonDynamicsCharacterController::PickGroundConvex(Leadwerks::Vec3 const&, Leadwerks::Vec3 const&, Leadwerks::PickInfo&) (NewtonDynamicsCharacterController.cpp:853) ==3542== by 0x7C0BC8: Leadwerks::NewtonDynamicsCharacterController::AlignToGround() (NewtonDynamicsCharacterController.cpp:792) ==3542== by 0x7BD4AE: Leadwerks::NewtonDynamicsCharacterController::Update() (NewtonDynamicsCharacterController.cpp:241) ==3542== by 0x7CF89E: Leadwerks::NewtonDynamicsSimulation::EndStep() (NewtonDynamicsSimulation.cpp:641) ==3542== by 0x7CF44F: Leadwerks::NewtonDynamicsSimulation::Update() (NewtonDynamicsSimulation.cpp:415) ==3542== by 0x4FE9B8: Leadwerks::World::Update() (World.cpp:657) ==3542== by 0x412429: AppServer::Loop() (AppServer.cpp:345) ==3542== by 0x409618: main (main.cpp:71) ==3542== AL lib: (EE) alc_cleanup: 1 device not closed ==3542== Thread 3: ==3542== Jump to the invalid address stated on the next line ==3542== at 0x0: ??? ==3542== by 0x5251D05: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.15.1) ==3542== by 0x5262C4B: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.15.1) ==3542== by 0x52569D9: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.15.1) ==3542== by 0x5D356A9: start_thread (pthread_create.c:333) ==3542== by 0x6A83EEC: clone (clone.S:109) ==3542== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==3542== ==3542== ==3542== Process terminating with default action of signal 11 (SIGSEGV) ==3542== Bad permissions for mapped region at address 0x0 ==3542== at 0x0: ??? ==3542== by 0x5251D05: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.15.1) ==3542== by 0x5262C4B: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.15.1) ==3542== by 0x52569D9: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.15.1) ==3542== by 0x5D356A9: start_thread (pthread_create.c:333) ==3542== by 0x6A83EEC: clone (clone.S:109) ==3542== ==3542== HEAP SUMMARY: ==3542== in use at exit: 454,227,093 bytes in 37,825 blocks ==3542== total heap usage: 83,530,078 allocs, 83,492,253 frees, 5,979,040,664 bytes allocated ==3542== ==3542== LEAK SUMMARY: ==3542== definitely lost: 1,288 bytes in 22 blocks ==3542== indirectly lost: 97,019 bytes in 10 blocks ==3542== possibly lost: 418,377,340 bytes in 1,440 blocks ==3542== still reachable: 35,751,446 bytes in 36,353 blocks ==3542== suppressed: 0 bytes in 0 blocks ==3542== Rerun with --leak-check=full to see details of leaked memory ==3542== ==3542== For counts of detected and suppressed errors, rerun with: -v ==3542== Use --track-origins=yes to see where uninitialised values come from ==3542== ERROR SUMMARY: 102706 errors from 26 contexts (suppressed: 0 from 0) Killed
  9. It looks like this is only going happen if you invoke the "reset_steam()" function in the script. So, definitely don't use the --reset commandline option, or try to move your steam directory and then symlink it at the old location (which is what the bug originator reported doing). I myself have commented out the offending line and plan to check for my change being overwritten with each update. Don't know if this will actually serve as protection. But, if this causes a problem before this is patched, it seems better than risking my entire user dir being wiped.
  10. Just wanted to give a heads up for linux users, the bug is still open and this could potentially be a big disaster: http://www.theregister.co.uk/2015/01/17/scary_code_of_the_week_steam_cleans_linux_pcs/ and: https://github.com/ValveSoftware/steam-for-linux/issues/3671 "...remove all files recursively, and without stopping, from the root directory down. Assuming the client is run as a normal user, it will delete everything owned by that account – including mounted backup drives and network shares – although leave other stuff, such as system files owned by root, intact." Please see line #468 of .steam/steam.sh (at least that is the line # in my current version).
  11. I can assure you that is definitely not the case, Intel Wants Leadwerks and all of us to succeed. Intel is a very large ship and one that thus turns very slowly. At each level, there are priorities surrounding a very large work load. Each group, org, manager and code owner has a given set of priorities that drive the daily effort. With this in mind, I made the suggestion to try an obtain and IPS ticket because these usually one of the driving priorities for individual code owners. We also don't know what is required to reinstate the old driver set or configure the newer driver set for backwards compatibility. The simplest changes are bug fixes, but sometimes a design change or specification change is needed which can be a much more involved process (think committees, meetings and so on). In addition, any change to support Leadwerks must be QA'd to make sure nothing else breaks. So, my suggestion has been to try and get our problem into the internal ticketing system for the correct group, keep poking on the ticket every one or two weeks and hang on for the ride. hah. Anyway, I know my comments don't really resolve the issue but I hope they help to give some confidence that a resolution will occur.
  12. Have you tried : http://www.intel.com/p/en_US/support?iid=hdr+supportf. ( You probably have). Alternatively, if you own any Intel development products or can establish a customer relatinoship with Intel that includes IPS, you may be able to get an IPS (Intel premier support) ticket. That would be the best way to get some action as the tickets typically are reviewed and as many as possible closed out each Friday.
  13. Yes, unfortunately Valgrind is only available for Linux and Unices. It is a fantastic tool and super easy to use. I often make it my first line of debugging info for C++ because so many bugs also cause memory leaks. Probably the only real drawbacks are the slow runtime (unavoidable) and large amount of debug output.
  14. This may be helpful, Intel has recently found a remediable issue related to Mesa. The patch may not be mainline until linux 3.18 according to the article (ubuntu 14.10 is currently at 3.16). http://news.softpedia.com/news/Massive-20-Improvement-to-Land-in-Intel-s-Mesa-Driver-Thanks-to-Valve-s-Efforts-464233.shtml
  15. I recently updated my Leadwerks 3.1 (standalone) using the LeadwerksUpdater program under Linux. My programs now seg fault during the map loading. This includes a new empty map made using the standalone map editor which self-identifies as 3.2. The project has been cleaned and recompiled. Also note that the update broke more than one thing, even though this is not the steam version of Leadwerks, a version of libsteam_api.so was installed in the base Leadwerks directory. 1. LD_LIBRARY_PATH had to be updated. 2. the installed libsteam_api.so failed with a complaint about: ./Leadwerks: error while loading shared libraries: libsteam_api.so: wrong ELF class: ELFCLASS64 3. Replacement with the libsteam_api.so found under .steam seemed to fix the error. "Error: Map file version 29 not supported." What map version should be in use?? and How does one check the version for a given map file.
×
×
  • Create New...