I've forgot to mention; it gives me this error:
20677ce977.png
Ohh okay. Well here's the thing. It compiled fine, everything works fine. You have two choices. Recompile it statically (just change the make file) OR add C:/Mingw/bin to your environment path variable. You basically have a truly dynamic dll. All its dependencies are linked to at run-time. Since C:/Mingw/bin is not in your path, it cannot find the dependencies and so you get that error. If you compile it statically, the dependencies are linked right into the dll. It's still dynamic but now it can be re-distributed and all the dependencies are compiled into it statically (no mingw required for usage).
I personally compile statically because you can redistribute it. If you don't need to then just add Mingw/bin to your path.
To compile it statically (windows only) you need to change the make file's flags:
https://www.diffchecker.com/xad2wi4g
There's a modified copy of the file on the main post. "-static" flag is only needed for windows. Do NOT use it on Linux.
Last edited by Brandon; 09-21-2014 at 05:36 PM.
I am Ggzz..
Hackintosher
Alright I've just added mingw to my path since it seemed to be easier. It did solve the previous problem but now I am left with another one. Here's a screenie:
63ad9c0161.png
I've been wondering, could my 64 bit java be causing this problem? Should I install 32 instead?
@HT BaaFly;
64-bit SMART works though. I know because I have it running. You need a 64-bit Simba to run it. No you need the -static. Without it, it will only work with Mingw installed. It's the same for Microsoft Visual Studio. If you link dynamically, then the user must have .Net framework or w/e libraries you're using but if you compile statically, they don't need anything.
You MIGHT need a 64-bit java to run 64-bit SMART and a 32-bit java for 32-bit SMART. I have both.
Last edited by Brandon; 09-21-2014 at 11:18 PM.
I am Ggzz..
Hackintosher
Oh i always thought only 32bit java works. But RS runs on 32bit so installing 64bit would make absolutely no difference to performance right?
Would 64bit simba/smart/glhook plugin have better performance than their 32bit counterparts?
I tried using 64bit simba, it said error loading glx64.dll. I compiled the plugin with mingw 64 bit downloaded from here (http://sourceforge.net/projects/ming...ds-posix/sjlj/)
Used the same code block. Windows codeblock doesnt separate into 32/64bit right? So what i'm doing wrongly?
I'd just like to report that the problem has been fixed . It seems that my jdk was 64x and my jre was 32x so that must have been incompatible somehow. What I did was uninstall my jdk 8 64 bit and replace it with 32 bit version. My mingw version is x32 4.7.3 posix sjlj r1
Thank you @Brandon and @riwu
Succeeded in loading the plugin, but a number defaults to int64 in 64bit simba? So most of the overloaded methods of which the param is declared 'TIntegerArray' will not work when you pass raw values to it...
Simba Code:procedure a(b: TIntegerArray);
begin
end;
procedure a(); overload;
begin
end;
begin
a([1,2]);
end.@Dgby714 @Wizzup? @nielsie95Code:Error: Don't know which overloaded method to call with params (array [0..1] of Int64)
Any solution to this?
Like making the type 'Integer' as int64 in 64bit (and to declare a 32bit u have to use 'int32'?), or ability to override a type (so that the script can specify overriding integer to int64)?
Last edited by riwu; 09-25-2014 at 11:00 PM.
What? What do you mean by "number"?
If you mean:
1. Integer is automatically promoted to Int64.
2. Float/Single is promoted to Double.
Then the answer is that such a thing.. should NEVER happen UNLESS Integer is an alias/typedef for the native integral type.. I haven't seen a language do this before (though Microsoft's Windows.h header does that for SOME types).
I can't really see Integer being promoted to Int64 rather than being Int32 in Simba. A cast could fix such a thing. I don't have a 64-bit Simba to test so see below..
Run the following:
Simba Code:begin
writeln(sizeof(Integer));
writeln(sizeof(Single));
writeln(sizeof(Int32));
writeln(sizeof(Int64));
writeln(sizeof(Extended));
writeln(sizeof(Double));
end.
What is the output?
Last edited by Brandon; 09-25-2014 at 11:15 PM.
I am Ggzz..
Hackintosher
He simply means that
will default at the native integral size.Code:WriteLn(SizeOf( 1 ));
So for 64bit simba that will of course be 8 bytes (Int64)
As for the question:
Casting it so that Lape knows each index is int32 should work fine:
You should also know about the NativeInt type it's a native integral type, so in 64bit simba it's 64bit, while on 32bit it's 32bit..Code:a(TIntegerArray([1,5]));
Last edited by slacky; 09-26-2014 at 12:32 AM.
!No priv. messages please
!No priv. messages please
The include wasn't written to support 64bit simba though, so all the arguments are not cast to int32.
Is it worth the effort of editing the entire include to make it work on 64bit simba?
What benefit do 64bit simba+64bit smart/java have?
I was thinking if a compiler directive/override can be added to Simba to change the NativeInt, then there won't be a need to edit the entire include?
True but there's a little bit more that can and does happen.
A slight bit more than that actually. If the exports and include used PtrUInt or Int64 on a 64-bit machine, the efficiency and performance could be improved and that's because:
1. There would be no padding of lesser than 32-bit types to go through the BUS.
2. It can use the memory and CPU more efficiently.
3. It doesn't matter that a 64-bit type is larger. It's the native integral type.
https://www.daniweb.com/software-dev...rs#post1820089
In addition to the padding, it has to go through Window's WOW64 subsystem: http://en.wikipedia.org/wiki/WoW64
TLDR: 64-bit programs perform better on the 64-bit system than on a 32-bit system. On Linux you can't do this unless you install the subsystem separately and it's almost never recommended (sudo apt-get install ia32-libs).
Last edited by Brandon; 09-26-2014 at 08:21 PM.
I am Ggzz..
Hackintosher
@Brandon
When i tried to compile 64bit smart i get:
My PATH: C:\mingw\bin; C:\Program Files\Java\jdk1.6.0_45\bin
MingW ver: x64-4.8.1-posix-seh-rev5
It seems like the msys couldn't detect my 64bit JDK? I couldn't find a msys that is 64bit though.
Also notice the title of the cmd is 'MINGW32', even though my MingW is 64bit?
Doesn't matter. There is a problem with your makefile or environment. MSYS doesn't have to be any specific bit. It's just there for invocation. So long as the make file has -m64 in it, it will compile SMART as x64 as long as mingw/gcc/g++ is x64.
-m32 specifies you're compiling as ix86.
-m64 specifies you're compiling as x86_64.
for all Fortran, C, & C++ programs.
The makefile &/or your env-path specifies your jdk locaiton, not msys or mingw. If it isn't found, check your make file and env-path again for the location to your java compiler's BIN folder.
If you're sure everything is right and your env-path is correct, then change the make variables to the following:
make Code:path_to_jdk=C:/blah/blah/jdk1.blah
JAVAC=path_to_jdk/bin/javac
JAR=path_to_jdk/bin/jar
Last edited by Brandon; 09-27-2014 at 08:42 AM.
I am Ggzz..
Hackintosher
There's no -m32 in the SMART MakeFile
I did change -m32 to -m64 for your ogl plugins which compiled fine.
Changed JAVAC and JAR path (no path_to_jdk), same result
http://paste.villavu.com/raw/6408/
Tried WIN64_GPP=C:\mingw\bin\g++ as well, doesn't work either
Or do i have to add a line that is java equivalent of BitFLG = -m64?
Not sure what you are referring to but i found the problem...
I didn't add the quotation marks for the path previously...Code:JAVAC="C:\Program Files\Java\jdk1.6.0_45\bin\javac" JAR="C:\Program Files\Java\jdk1.6.0_45\bin\jar"
It still output as libsmartjni32.dll but i guess i'd just have to change the name to libsmartjni64.dll.
Thanks for the help!
EDIT: oh in the previous post u meant for me to add the variable path_to_jdk, not to find and edit it
Last edited by riwu; 09-27-2014 at 04:37 PM.
Lol. This is a problem with WINDOWS.
It's why the include for SMART replaces all backslashes with forward slashes as shown here: https://github.com/SRL/SRL-6/blob/ma...art.simba#L364
On windows, if a path has a backslash, it must be escaped by another backslash or changed to a forward slash. If it has spaces, it must be quoted.
So:
C:\Meh\foo
would become:
C:/Meh/foo OR C:\\Meh\\foo
And this is not just for programming. It's also for CMD, diskpart, and all the other command line utilities.
If it is:
C:/Program Files/meh/foo
it must become:
"C:/Program Files/meh/foo"
I don't remember if the same behaviour applies on linux but I do it anyway.
But anyway, glad it all worked out.
I am Ggzz..
Hackintosher
So after a few days of experimenting with 64 bit java, i realize it's taking twice as much memory as 32bit java:
730mb after just logging in to game. 32bit would only use 300mb+.
I downgrade to 32bit java and try to run 64bit simba + 64bit smart plugins + 32bit java but got this error:
** Smart Cannot Spawn Clients ** retrying...
So i'm back on 32bit everything
There are currently 1 users browsing this thread. (0 members and 1 guests)