Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML 2.3.2 static compile for Visual Studio 2015 v140  (Read 9436 times)

0 Members and 1 Guest are viewing this topic.

LanceJZ

  • Newbie
  • *
  • Posts: 9
    • View Profile
SFML 2.3.2 static compile for Visual Studio 2015 v140
« on: October 11, 2015, 04:06:09 am »
I've compiled this for those that get lost in making it for a new version of Visual Studio. Please feel free to use these in your projects. It works great for me. I've uploaded to to github. The way I use this is by placing it beside the project folders of your SFML projects. No DLLs needed for this for SFML, they get compiled into the exe file.
https://github.com/LanceJZ/SFML-2.3.2
See an included example game setup for this here if you need to see how to setup VS 2015 for it. https://github.com/LanceJZ/SFML-Pong
Or Check out my game using this here if you need to see how to setup VS 2015.
https://github.com/LanceJZ/Base-Defender
Game on!

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #1 on: October 11, 2015, 04:11:01 am »
Or download the official binaries from the website? And you don't even include the release libs.
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

LanceJZ

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #2 on: October 11, 2015, 04:30:03 am »
It does not use the binaries, it is static, so no SFML DLLs used. Dude... I'm doing this on my free time, don't be so greedy. This is meant as an example, not to do all the work for you.

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #3 on: October 11, 2015, 06:24:17 pm »
 ??? *.lib files are considered binaries as well as *.dll files. And the official binaries also include static version of SFML...
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

LanceJZ

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #4 on: October 12, 2015, 03:16:16 am »
You know what I mean... The binaries are compiled into the exe file... So you don't need any DLLs. Stop splitting hairs. I'm dyslexic and I have aphasia, so I have trouble saying what I mean. :p
It took me days to get it working. I started doing it that way with Polycode.

SeriousITGuy

  • Full Member
  • ***
  • Posts: 123
  • Still learning...
    • View Profile
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #5 on: October 12, 2015, 10:17:37 am »
What zsbzsb meant to say was that there are official SFML binaries on the download page for Visual Studio 2015 here http://www.sfml-dev.org/download/sfml/2.3.2/
which already include static libs, so you did something the SFML team already did ;)

DuvnjakA

  • Newbie
  • *
  • Posts: 19
    • View Profile
    • Email
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #6 on: October 15, 2015, 05:44:36 pm »
The SFML static libraries on the download were compiled with dynamic CRT libraries so they DO NOT work with /MT or /MTd ... In order to get the SFML static libs working with static CRT, you need to recompile SFML on your own. :P

Let me correct myself... the SFML 2.3.2 static libraries for VS2015 do not work with static CRT. If you want static SFML and static CRT, you need to recompile SFML on your own.
« Last Edit: October 15, 2015, 05:47:53 pm by DuvnjakA »

Gambit

  • Sr. Member
  • ****
  • Posts: 283
    • View Profile
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #7 on: October 16, 2015, 02:26:04 am »
I feel like your post is replying to this thread but I thought I might point out that they were talking about statically linked SFML libraries, not statically linked CRT.

SeriousITGuy

  • Full Member
  • ***
  • Posts: 123
  • Still learning...
    • View Profile
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #8 on: October 16, 2015, 02:15:52 pm »
Let me correct myself... the SFML 2.3.2 static libraries for VS2015 do not work with static CRT. If you want static SFML and static CRT, you need to recompile SFML on your own.
That is correct but actually not on point. And in typical windows software projects, one does not compile with static crt, redistributable packages of the vc++ runtime exist for a reason because they are meant to be shared between applications. Using static third party libs on windows is totally reasonable, that's why they are already provided by the official distribution.

DuvnjakA

  • Newbie
  • *
  • Posts: 19
    • View Profile
    • Email
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #9 on: October 16, 2015, 03:30:29 pm »
@gambit
I know but I think that's what the OP was trying to say..

@SeriousITGuy
I'm aware of that but as I said above, that could be what the OP was trying to say.

bjadams

  • Newbie
  • *
  • Posts: 12
    • View Profile
    • Email
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #10 on: October 20, 2015, 08:57:05 am »
I like the idea of static libs so there will be no external .dll

Elro444

  • Newbie
  • *
  • Posts: 5
    • View Profile
Re: SFML 2.3.2 static compile for Visual Studio 2015 v140
« Reply #11 on: October 26, 2017, 05:20:26 pm »
That is correct but actually not on point. And in typical windows software projects, one does not compile with static crt, redistributable packages of the vc++ runtime exist for a reason because they are meant to be shared between applications. Using static third party libs on windows is totally reasonable, that's why they are already provided by the official distribution.
As written in Crypto++'s wiki:
Quote
If you switch to dynamic linking, there's an increased attack surface because a DLL can be changed or redirected at loadtime. Both Windows and Linux suffer the DLL tricks; see, for example, Breaking the Links: Exploiting the Linker on Linux or search for Binary Planting on Windows.
So to my understanding static linking CRT is good, but not if security is something that is important for your program.