Edit: as mso pointed out, this is because it's loading libbyond.so from /usr/local/lib instead of from the zip extract.
Descriptive Problem Summary:
I was trying to diagnose a different bug (will make a report in a sec don't worry) and I noticed that no matter how old of a DD binary I run, it's ALWAYS running the version installed in my PATH proper. This means you can't run separate binaries extracted from zip files at all.
Changing the installed version by installing the old version and it works properly, but of course now your system is using a different version.
Numbered Steps to Reproduce Problem:
1. Get a Linux server.
2. Install BYOND.
3. Get an older BYOND version and extract that without installing it.
4. Attempt to run older version and notice it claims to be the latest version you actually installed.
ID:2293882
 Sep 14 2017, 2:16 pm (Edited on Sep 15 2017, 9:25 am)
|
|||||||||||||
| |||||||||||||
|
Sep 14 2017, 2:21 pm
|
|
Lummox JR
   |
That doesn't really make sense to me; whatever version runs should be determined by the Linux command line syntax. If you run ./dreamdaemon it should always go by the current directory.
|
If you want to run a version from a seperate directory you have to run the binary from the bin folder of the extracted zip ..
The way you worded the above sounds like you're just using the DreamDaemon command.. not /olderbyondversion/bin/DreamDaemon | |
Lummox JR wrote:
That doesn't really make sense to me; whatever version runs should be determined by the Linux command line syntax. If you run ./dreamdaemon it should always go by the current directory. Beat me to it, I wonder how many seconds between us :D | |
Yes, I'm running the proper binary from the directory I extracted.
| |
I even went as far as to check the binary of the DD process from /proc and to chmod the binary and back to make sure I'm not running the one in my PATH, it's ALL pointing to the zip one.
| |
Oh what the fuck.
byondserver@linuxtest:~$ wget http://www.byond.com/download/build/511/511.1385_byond_linux.zip | |
This likely has to do with how linux loads libraries actually.
In windows a .dll of the same name in the current directory takes priority over ones in loading paths. In linux this isn't necessary the case, and sometimes .so's in the current directory are flat out ignored. | |
byondserver@linuxtest:~/511.1385/byond/bin$ ldd DreamDaemon
linux-gate.so.1 (0xf77ec000) libbyond.so => /usr/local/lib/libbyond.so (0xf728d000) libext.so => /usr/local/lib/libext.so (0xf7078000) librt.so.1 => /lib32/librt.so.1 (0xf706f000) libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf6f7d000) libm.so.6 => /lib32/libm.so.6 (0xf6f37000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf6f19000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf6efd000) libc.so.6 => /lib32/libc.so.6 (0xf6d50000) libdl.so.2 => /lib32/libdl.so.2 (0xf6d4b000) /lib/ld-linux.so.2 (0x5659a000) | |
MrStonedOne wrote:
Oh what the fuck. Interesting.. | |
What's your
LD_LIBRARY_PATH?nyx@thanatos ~/byond/510.1346/bin | |
This only happens if you don't source bin/byondsetup.
You really should be using that... | |
TIL about bin/byondexec
That's really annoying to run from a program directly though, especially because it breaks if your working dir is incorrect. | |
Go to the base byond dir, run `make here`.
Then run `source bin/byondsetup` and you'll be able to run all byond things with proper libs on that shell. | |