Page 4 of 5 FirstFirst ... 2345 LastLast
Results 76 to 100 of 121

Thread: How To Compile Smart.

  1. #76
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by HT BaaFly View Post
    alright, I'll try it later as I have to go study right now. Will till you how it turns out tomorrow. Thanks for you help
    I don't see what the problem is. You don't have any errors in any of the above posts. It compiled perfectly fine. You have warnings not errors.

    Check your dist folder for the binaries you just compiled.
    I am Ggzz..
    Hackintosher

  2. #77
    Join Date
    Oct 2008
    Posts
    196
    Mentioned
    1 Post(s)
    Quoted
    20 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    I don't see what the problem is. You don't have any errors in any of the above posts. It compiled perfectly fine. You have warnings not errors.

    Check your dist folder for the binaries you just compiled.
    I've forgot to mention; it gives me this error:

    20677ce977.png

  3. #78
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by HT BaaFly View Post
    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

  4. #79
    Join Date
    Oct 2008
    Posts
    196
    Mentioned
    1 Post(s)
    Quoted
    20 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    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.
    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?

  5. #80
    Join Date
    Jan 2012
    Posts
    2,568
    Mentioned
    35 Post(s)
    Quoted
    356 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    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.
    I only changed
    Code:
    WIN_GPP=g++
    WIN64_GPP=g++
    and didnt add those -static flags, i can still redistribute it w/o the end users having to download&add mingw to path?

    Quote Originally Posted by HT BaaFly View Post
    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?
    yes AFAIK only 32bit works.
    Last edited by riwu; 09-21-2014 at 10:46 PM.

  6. #81
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by riwu View Post
    I only changed
    Code:
    WIN_GPP=g++
    WIN64_GPP=g++
    and didnt add those -static flags, i can still redistribute it w/o the end users having to download&add mingw to path?


    yes AFAIK only 32bit works.
    @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

  7. #82
    Join Date
    Jan 2012
    Posts
    2,568
    Mentioned
    35 Post(s)
    Quoted
    356 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    @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.
    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?

  8. #83
    Join Date
    Oct 2008
    Posts
    196
    Mentioned
    1 Post(s)
    Quoted
    20 Post(s)

    Default

    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

  9. #84
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by riwu View Post
    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?
    That plugin's code blocks file is 32 enabled. Enabled 64 bit by changing the properties to 64 bit under other and linker flags.
    I am Ggzz..
    Hackintosher

  10. #85
    Join Date
    Jan 2012
    Posts
    2,568
    Mentioned
    35 Post(s)
    Quoted
    356 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    That plugin's code blocks file is 32 enabled. Enabled 64 bit by changing the properties to 64 bit under other and linker flags.
    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.
    Code:
    Error: Don't know which overloaded method to call with params (array [0..1] of Int64)
    @Dgby714 @Wizzup? @nielsie95
    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.

  11. #86
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by riwu View Post
    Succeeded in loading the plugin, but a number defaults to int64 in 64bit simba? So most of the methods of which the param is declared 'Integer' rather than 'int64' will not work...
    Code:
    Error: Don't know which overloaded method to call with params (array [0..4] of Int64, array [0..4] of Int64, array [0..4] of Int64)
    @Dgby714 @Wizzup? @nielsie95
    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 to specify overriding integer to int64)?

    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

  12. #87
    Join Date
    Nov 2011
    Location
    England
    Posts
    3,072
    Mentioned
    296 Post(s)
    Quoted
    1094 Post(s)

    Default

    Quote Originally Posted by riwu View Post
    ...
    You have to cast it, You have to cast any param if there's a overload and your creating a static array / type thing.

    [1, 2] could be extended, integers, or even variants, Lape doesn't even try to guess or figure it out.
    Last edited by Olly; 09-25-2014 at 11:37 PM.

  13. #88
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    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?
    He simply means that
    Code:
    WriteLn(SizeOf( 1 ));
    will default at the native integral size.
    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:
    Code:
    a(TIntegerArray([1,5]));
    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..
    Last edited by slacky; 09-26-2014 at 12:32 AM.
    !No priv. messages please

  14. #89
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by slacky View Post
    You should also know about the NativeInt type it's a

    Ahh I see. It's a "what"? I think that's a typo. But perhaps you are trying to say that it's a 64-bit in on 64-bit Simba and 32-bit otherwise.
    I am Ggzz..
    Hackintosher

  15. #90
    Join Date
    Feb 2012
    Location
    Norway
    Posts
    995
    Mentioned
    145 Post(s)
    Quoted
    596 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    Ahh I see. It's a "what"? I think that's a typo. But perhaps you are trying to say that it's a 64-bit in on 64-bit Simba and 32-bit otherwise.
    Yeah, fixed.. Donno what happened.
    !No priv. messages please

  16. #91
    Join Date
    Jan 2012
    Posts
    2,568
    Mentioned
    35 Post(s)
    Quoted
    356 Post(s)

    Default

    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?

  17. #92
    Join Date
    Sep 2008
    Location
    Not here.
    Posts
    5,422
    Mentioned
    13 Post(s)
    Quoted
    242 Post(s)

    Default

    Quote Originally Posted by riwu View Post
    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?
    The only benefit I can think of is the ability to allocate more memory to smart.

  18. #93
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by tls View Post
    The only benefit I can think of is the ability to allocate more memory to smart.
    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

  19. #94
    Join Date
    Jan 2012
    Posts
    2,568
    Mentioned
    35 Post(s)
    Quoted
    356 Post(s)

    Default

    @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?

  20. #95
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by riwu View Post
    ..

    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

  21. #96
    Join Date
    Jan 2012
    Posts
    2,568
    Mentioned
    35 Post(s)
    Quoted
    356 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    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.
    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?

  22. #97
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by riwu View Post
    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?

    There is a makefile near the end and it shows exactly what I mean.
    I am Ggzz..
    Hackintosher

  23. #98
    Join Date
    Jan 2012
    Posts
    2,568
    Mentioned
    35 Post(s)
    Quoted
    356 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    There is a makefile near the end and it shows exactly what I mean.
    Not sure what you are referring to but i found the problem...
    Code:
    JAVAC="C:\Program Files\Java\jdk1.6.0_45\bin\javac"
    JAR="C:\Program Files\Java\jdk1.6.0_45\bin\jar"
    I didn't add the quotation marks for the path previously...

    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.

  24. #99
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by riwu View Post
    Not sure what you are referring to but i found the problem...
    Code:
    JAVAC="C:\Program Files\Java\jdk1.6.0_45\bin\javac"
    JAR="C:\Program Files\Java\jdk1.6.0_45\bin\jar"
    I didn't add the quotation marks for the path previously...

    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

    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

  25. #100
    Join Date
    Jan 2012
    Posts
    2,568
    Mentioned
    35 Post(s)
    Quoted
    356 Post(s)

    Default

    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

Page 4 of 5 FirstFirst ... 2345 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •