Visit us at booth #2341 during I/ITSEC 2021
Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

Profile Information

  • Gender
    Not Telling
  • Location
    Portland, Oregon
  1. This failed with the error: /usr/lib/x86_64-linux-gnu/ 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:
  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 an
  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 --enab
  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/ -lopenal (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/ -lGL (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/ -lGLU (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/ -lsteam_api (/home/<usr-name>/.steam/steam/SteamApps/common/Leadwerks Game Engine/Library/Linux/ -lX11 (/usr/lib/gcc/x86_64-linux-g
  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::N
  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: and: "...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."
  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 f
  12. Have you tried : ( 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).
  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 was installed in the base Leadwerks directory. 1. LD_LIBRARY_PATH had to be updated. 2. the installed failed with a complaint about:
  • Create New...