• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
fir

hand-linking to stdlib.h in mingw

21 posts in this topic

I would like to not include whole "stdlib.h" or "math.h" or "stdio.h"

in my modules but write only used declarations with my own hand for

example

 

extern int rand(void);

 

etc

 

but when i comment //#include "stdio.h" mingw linker complains that it do

not see the symbols (though i wrote the declaration)

 

I suspect that it some cheat that maybe automaticaly links to stdlib binary when i am usling include and do not links to it when i do not use include, so i should

maybe provide it with -lsomething - but i do not know what to write in place

of something

 

am I right ? can i use symbols with including all the headers, what to -l link

in linker to make it work?

 

tnx for help

(im compiling in c++ mode othervise c code if this is important)

0

Share this post


Link to post
Share on other sites

Since you are compiling it as C++, try declaring the C functions as actual C functions, like this:

extern "C" {
int rand();
// whatever else
}

Otherwise the C++ name mangling will prevent the linker from finding the correct function.

 

 

I guess that you are doing this to reduce compilation times? If so, mingw supports precompiled headers, which are probably a better way to deal with this, than rewriting the standard headers.

1

Share this post


Link to post
Share on other sites

Since you are compiling it as C++, try declaring the C functions as actual C functions, like this:

extern "C" {
int rand();
// whatever else
}

Otherwise the C++ name mangling will prevent the linker from finding the correct function.

 

 

I guess that you are doing this to reduce compilation times? If so, mingw supports precompiled headers, which are probably a better way to deal with this, than rewriting the standard headers.

grrreat, much tnx, it worx (overlooked it)

 

besides though - a binary for stdlib.h is not provided in command line like other normal libs, so i wonder what it is given here implicitely -

does maybe someone know? where lies the binary?

 

I am doing this mainly for clarity - i wouldlike to give this with my own

hands, I just prever to give simple

 

extern "C" int rand (void);
 
like here instead of /#include <stdlib.h>
 
(not sure though  if with windows.h declaration it will go that easy,
though i would like to cheat its types (like HWND with ints etc) get some declarations for 20 functions i use and also throw it all other away) ;/
 
tnx for help
Edited by fir
0

Share this post


Link to post
Share on other sites

It is a part of the standard library that is, most likely, implicitly linked to your program. It contains more than just some random functions (pun intended, I quess) for you to use, such as the necessary runtime environment, so not linking it is not really an option.

Edited by Brother Bob
0

Share this post


Link to post
Share on other sites

It is a part of the standard library that is, most likely, implicitly linked to your program. It contains more than just some random functions (pun intended, I quess) for you to use, such as the necessary runtime environment, so not linking it is not really an option.

well, interesting remark, but even if this is 100% neccessary (i am not sure) there would be an option tolink to other runtime maybe

 

except that i still do not know where lies the binary :U

-1

Share this post


Link to post
Share on other sites

Yes, you can link to other libc implementations. For desktop Linux, people usually use glibc. You can use uClibc or some other libc, but most are not going to be as full-featured since they're often aimed at embedded development. You can also just change the source to glibc and compile it yourself. There's a rand.c file right there in the stdlib folder of the glibc source distributions.

 

For Windows, you'd probably be linking against msvcrt instead of glibc. I think Cygwin uses its own thing instead of msvcrt, but mingw definitely uses msvcrt. Your options are just going to be way more limited on Windows, so it's probably easier to just run Linux while you're learning whatever you're hoping to learn from this.

 

If for some reason you want to compile with no standard library at all, in gcc you can use -nostdlib option. You might need to also use -exclude-libs or some other stuff. I just don't know what all you'd have to do.

1

Share this post


Link to post
Share on other sites

 


What you are doing is not very sensible, nor will it do what you want. If you want to avoid linking to the standard library, give MinGW the link-option -nostdlib. Note that since you use the standard library your programs will not work afterwards.

 

MinGW will link to the system's MSVCRT, and on demand to the C or C++ standard libraries (statically or dynamically, depending on what MinGW distro you use) without you having to do anything. Tampering with this will result in programs that do not work, but not including a header will not make any difference here.

 

Including <stdlib.h> is none less clear than declaring functions by hand (on the contrary, it is the correct thing that people expect to see). You further risk omitting some attributes on a couple of functions without noticing, or getting an #ifdef wrong by accident, which may cause your program to behave incorrectly, or may result in non-portable programs, or may not give the compiler necessary information needed to generate optimal code and avoid warnings.

It is easy to get a typedef wrong or to forget an attribute on some unimportant function. The result will be, in the best case, a compile error. Or, in the worst case, a program that doesn't work properly (or maybe a program that works properly in a 32bit build, and doesn't work in 64bits), and nobody can tell why.

 

I know it is 'hackish' or what to call this [but would like to try it, Im not saying i will be using this all the time (I was doing already 'worse' things ;/0] 

 

As to this msvcrt.dll i heard that this is not system (at least win xp i am using) dll - this must be installed - You sure mingw links against that, where is the import.lib for that? does maybe someone kbow more about this implicit linked libraries - this is important to know imo

 

Edited by fir
-1

Share this post


Link to post
Share on other sites

Yes, you can link to other libc implementations. For desktop Linux, people usually use glibc. You can use uClibc or some other libc, but most are not going to be as full-featured since they're often aimed at embedded development. You can also just change the source to glibc and compile it yourself. There's a rand.c file right there in the stdlib folder of the glibc source distributions.

 

For Windows, you'd probably be linking against msvcrt instead of glibc. I think Cygwin uses its own thing instead of msvcrt, but mingw definitely uses msvcrt. Your options are just going to be way more limited on Windows, so it's probably easier to just run Linux while you're learning whatever you're hoping to learn from this.

 

If for some reason you want to compile with no standard library at all, in gcc you can use -nostdlib option. You might need to also use -exclude-libs or some other stuff. I just don't know what all you'd have to do.

 

well i just want to throw away whole includes (it is about c standard library headers and also windows.h) and write declarations with my own hand only

 

also i would need to know exactly where are all the binaries mingw is

linking my binaries against? Dont you know where lies import library used for linking with this msvcrt.dll ? (I asume this is dynamic lib only linked against? not static one?

 

Is  this containing only some part of standard c library things or all this c library

is in it?

 

tnx for hints

-2

Share this post


Link to post
Share on other sites
As to this msvcrt.dll i heard that this is not system (at least win xp i am using) dll - this must be installed - You sure mingw links against that, where is the import.lib for that?

Yes, I am sure this is the system CRT. I do not install anything anywhere, all my MinGW programs just run like this. (OK, that's only half of the truth, usually OpenGL and OpenCL need to be installed on the computer, but that's unrelated to this question as it's something that users usually do without knowing by installing the display driver anyway -- not my job to do that).

 

The only exception where you have to "install" something is a compiler build that links against libstdc++ dynamically, but these builds are rare -- they existed historically because libstdc++ contained helper libs to enable throwing exceptions among DLLs and executables and for making TLS work reliably (without leaking), both of these work without helper libs in modern builds. And in those cases, you would just have bundled the DLL in the zip file within the executable's directory. That somewhat leads the "shared" part of shared library to absurdum, but it reliably avoids version conflicts, and you need not installer that does obscure stuff with the Windows directory (which is something a lot of people despise).
 

well i just want to throw away whole includes (it is about c standard library headers and also windows.h) and write declarations with my own hand only

Again: Not including headers will not prevent linking to the system libraries. Not including headers will only have the effect of the compiler not knowing the signatures of the functions as well as the definitions of many types which are defined for portability (such as off_t, size_t, or time_t).

 

You can of course declare the functions yourself, but it will not gain you anything except for ten or so milliseconds of compile time. The only header that has a significant compile time impact (and notable side effects) is <windows.h> if you haven't defined NOMINMAX and WIN32_LEAN_AND_MEAN.

The chance of screwing things up in a more or less nasty manner by writing your own declarations is significant, however.
 

also i would need to know exactly where are all the binaries mingw is linking my binaries against?

Several locations within the compiler's directory (including the bin, lib (for import libs), and libexec dirs, possibly different among different compiler builds), plus any extra paths that you specify on the commandline, and finally %windir%/system32

0

Share this post


Link to post
Share on other sites

http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx explains the different msvcrt libraries. It is all of the c runtime library (with exceptions spelled out in that link). That's what the crt stands for: C RunTime.

 

But i never managed to understand is "c run time" == "c std lib"

or is "c run time" only implementation of some part of "c std lib"

(and there is some part of "c std lib" contained in the other binaries than "c run time"?

0

Share this post


Link to post
Share on other sites

You can of course declare the functions yourself, but it will not gain you anything except for ten or so milliseconds of compile time. The only header that has a significant compile time impact (and notable side effects) is <windows.h> if you haven't defined NOMINMAX and WIN32_LEAN_AND_MEAN.

The chance of screwing things up in a more or less nasty manner by writing your own declarations is significant, however.
 

well i am just trying to get rid of windows.h but it is hard because window functions are heavy macroprocessed and i dont know its raw

form

 

for example i got some call to   SetWindowText(hwnd, text);

i was trying to delete windows.h and declare

 

 int __stdcall SetWindowText(void*, char*);

 
but gotlinker error
 
undefined reference to `SetWindowText(void*, char*)@8'
 
how i should write it? where to find a raw declatarion for this, raw declaration i could type here?
 
 
0

Share this post


Link to post
Share on other sites

C standard library is defined by the C language spec and is fully included in a C runtime library. What else is also included in a C runtime library varies. glibc obviously includes POSIX stuff and GNU-specific stuff in addition to the standard library. msvcrt obviously includes Windows stuff and whatever else Microsoft felt like throwing in there.

1

Share this post


Link to post
Share on other sites
for example i got some call to   SetWindowText(hwnd, text);

i was trying to delete windows.h and declare

 

 int __stdcall SetWindowText(void*, char*);

 
but gotlinker error
 
undefined reference to `SetWindowText(void*, char*)@8'
 
how i should write it? where to find a raw declatarion for this, raw declaration i could type here?

 

The symbol SetWindowText is itself a macro than expands to either SetWindowTextA or SetWindowTextW. Most functions that take strings have A and W variants for char * and wchar_t * strings, respectively.

2

Share this post


Link to post
Share on other sites

 

for example i got some call to   SetWindowText(hwnd, text);

i was trying to delete windows.h and declare

 

 int __stdcall SetWindowText(void*, char*);

 
but gotlinker error
 
undefined reference to `SetWindowText(void*, char*)@8'
 
how i should write it? where to find a raw declatarion for this, raw declaration i could type here?

 

The symbol SetWindowText is itself a macro than expands to either SetWindowTextA or SetWindowTextW. Most functions that take strings have A and W variants for char * and wchar_t * strings, respectively.

 

Ye i was conscius of this vaguelly (bus as usual was trying blindly for a moment)

 

now i deleted the windows.h and used 

 

extern "C" int __stdcall SetWindowTextA(void*, char*);
 
and this seem to work but doing it (unpreprocessing it) blindly is
a bit too dangerous - so i would be need some reference for such 
raw headers for winapi calls but i do not know from where to get it?
 
could someone help with that?
 
(getting rid of windows h is maybe less important for me
(though it too would be very nice), ecause windows.h is a less
intrusive header than c headers (c headers almost need to be includes in almost all of my modules windows h only in the few of them, but i would really like to throw includes here too, so if
someone could help with this TNX)
Edited by fir
0

Share this post


Link to post
Share on other sites

C standard library is defined by the C language spec and is fully included in a C runtime library. What else is also included in a C runtime library varies. glibc obviously includes POSIX stuff and GNU-specific stuff in addition to the standard library. msvcrt obviously includes Windows stuff and whatever else Microsoft felt like throwing in there.

Alright much tnx, (youre cleared the vagueness tah doomed me last half a year) this was a surprise to me, i suspected that cruntime is only a part of c std lib, not c std lib + yet more

0

Share this post


Link to post
Share on other sites

The point of the Windows API is that you don't know these implementation details and you are not supposed to know them. You make a unicode build, and it will just work. You do a normal build, and it will work anyway.

 

You do a 64bit build, and it will still work.

 

The way you've declared the function (using void* and char*), your code will break if at any time e.g. the assumption typedef void* HANDLE; isn't true any more. Microsoft may change the API (it's unlikely but possible, and it has happened), and the same types may not work the same between 32 and 64 bits.

 

By using <windows.h> you account for all this. It will work, no matter what. By doing your own stuff, you are out alone in the dark.

 

Same is true for all the standard headers. If you use off_t in your code as defined in your system headers, your programs will compile successfully and run without errors, regardless whether off_t means unsigned int, or uint64_t or something else. You just don't care.

 

I agree, you right. Windows.h is some program ;/ that let do some

few types of builds. but here im doing some hackish thing like disassembly (many people are doing that yet more strange things ;/

 

so i decided to tinker with this for a while,..

 

second think, i think if doing right it is not so dangerous and wrong,

microsoft will not change the binary interface i am linking to, so if i 

link properly it will work

 

ONE thing i need though are the raw-physical sugnatures of this 20 or something winapi calls I use (like the one above) this is the signatures 

after unfolding al macros - i do not know from where to get this and do not risk the mistakes in types (becouse if i do mistake i will have a runtime corruption) :/ i would like to avoid this

-2

Share this post


Link to post
Share on other sites

 

 

ONE thing i need though are the raw-physical sugnatures of this 20 or something winapi calls I use (like the one above) this is the signatures 

after unfolding al macros - i do not know from where to get this and do not risk the mistakes in types (becouse if i do mistake i will have a runtime corruption) :/ i would like to avoid this

 

 

They are all in the Windows headers that ship with any SDK. What do you think Windows.h is?

 

I'm obviously missing something here. You seem to think defining these manually rather than including the headers is affecting the dissassembly or something? There is no difference to the compiler whether you manually declare a function or include a header - #include is literally just text-replace by the preprocessor - so could you explain again why you are doing this?

 

If its just for fun or out of interest, good luck to you. For anything else it is just lunacy.

 

its for fun, also for some learning purposes (related to disasembly realm ,

thats why i used the word, when you trace api calls they are raw types

off-skined from define macros and typedefs to raw c types - i need some reference on an easy way for getting to know how such off-skined win api calls look like)

0

Share this post


Link to post
Share on other sites

The macro forms are the actual API forms :)

 

Most implementation names are exactly identical with the API, only some come in ANSI and Unicode forms, denoted by ending in either a capital A or W (for "wide"). Usually they are accessed though an indirect jump via the import address table, since the virtual address is not known before the DLL is loaded, and not rarely several public API functions wrap one "Nt" function with a somewhat similar name. So prepare for a bit of a surprise when you debug/disassemble these.

 

A few API functions, such as GetCurrentThread(), are not functions at all but resolve to integer literals (-1) which serve as "pseudohandles". They only look like you're calling a function in source code, and you will not be able to find the function in any library. Nor will you be able to find the corresponding code, obviously.

Yet other API functions (e.g. InterlockedCompareExchange) are wrappers around compiler intrinsics that produce special instructions.

2

Share this post


Link to post
Share on other sites

off-skined from define macros and typedefs to raw c types - i need some reference on an easy way for getting to know how such off-skined win api calls look like)

If you're using GCC on MINGW, you can run the proprocessor over your sources files containing the standard headers and seet what the actual C (or C++) code fed to the compiler looks like. The easiest way to do that is to add the -save-temps switch to the command line along with all the other options, and example the resulting .i (or .ii) file.

2

Share this post


Link to post
Share on other sites

 

off-skined from define macros and typedefs to raw c types - i need some reference on an easy way for getting to know how such off-skined win api calls look like)

If you're using GCC on MINGW, you can run the proprocessor over your sources files containing the standard headers and seet what the actual C (or C++) code fed to the compiler looks like. The easiest way to do that is to add the -save-temps switch to the command line along with all the other options, and example the resulting .i (or .ii) file.

 

will luk on that, tnx for hint (Im new to mingw)

0

Share this post


Link to post
Share on other sites

The macro forms are the actual API forms smile.png

 

Most implementation names are exactly identical with the API, only some come in ANSI and Unicode forms, denoted by ending in either a capital A or W (for "wide"). Usually they are accessed though an indirect jump via the import address table, since the virtual address is not known before the DLL is loaded, and not rarely several public API functions wrap one "Nt" function with a somewhat similar name. So prepare for a bit of a surprise when you debug/disassemble these.

 

A few API functions, such as GetCurrentThread(), are not functions at all but resolve to integer literals (-1) which serve as "pseudohandles". They only look like you're calling a function in source code, and you will not be able to find the function in any library. Nor will you be able to find the corresponding code, obviously.

Yet other API functions (e.g. InterlockedCompareExchange) are wrappers around compiler intrinsics that produce special instructions.

well, interesting

but i wonder how api call can produce intrinsics are the intrinsics 

'manageable' (intrinsic as defined as some more than inline code,

some task recognized by compiler that could be managed more flexible

than even inline code - Im sorry if they are not yet quite manegeable by

coders .. (because it seems that they are not yet quite manageable and probably maybe they should)... tjis is a digression, maybe tou mean

here inline asm lines 

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0