Jump to content

  • Log In with Google      Sign In   
  • Create Account

hand-linking to stdlib.h in mingw


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
26 replies to this topic

#1 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 03 February 2014 - 12:05 PM

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)



Sponsor:

#2 Ohforf sake   Members   -  Reputation: 1832

Like
1Likes
Like

Posted 03 February 2014 - 12:19 PM

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.



#3 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 03 February 2014 - 12:39 PM

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, 03 February 2014 - 12:40 PM.


#4 Brother Bob   Moderators   -  Reputation: 8632

Like
0Likes
Like

Posted 03 February 2014 - 12:50 PM

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, 03 February 2014 - 12:51 PM.


#5 fir   Members   -  Reputation: -456

Like
-1Likes
Like

Posted 03 February 2014 - 12:58 PM

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



#6 samoth   Crossbones+   -  Reputation: 5039

Like
5Likes
Like

Posted 03 February 2014 - 01:26 PM

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.


Edited by samoth, 03 February 2014 - 01:30 PM.


#7 richardurich   Members   -  Reputation: 1187

Like
1Likes
Like

Posted 03 February 2014 - 01:38 PM

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.



#8 fir   Members   -  Reputation: -456

Like
-1Likes
Like

Posted 03 February 2014 - 01:45 PM

 


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, 03 February 2014 - 02:08 PM.


#9 fir   Members   -  Reputation: -456

Like
-2Likes
Like

Posted 03 February 2014 - 02:14 PM

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



#10 richardurich   Members   -  Reputation: 1187

Like
0Likes
Like

Posted 03 February 2014 - 02:52 PM

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.



#11 samoth   Crossbones+   -  Reputation: 5039

Like
0Likes
Like

Posted 03 February 2014 - 02:53 PM

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



#12 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 03 February 2014 - 03:17 PM

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



#13 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 03 February 2014 - 03:30 PM

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?
 
 


#14 richardurich   Members   -  Reputation: 1187

Like
1Likes
Like

Posted 03 February 2014 - 03:38 PM

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.



#15 Brother Bob   Moderators   -  Reputation: 8632

Like
2Likes
Like

Posted 03 February 2014 - 03:40 PM

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.



#16 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 03 February 2014 - 03:52 PM

 

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, 03 February 2014 - 03:58 PM.


#17 samoth   Crossbones+   -  Reputation: 5039

Like
6Likes
Like

Posted 03 February 2014 - 04:01 PM

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.


Edited by samoth, 03 February 2014 - 04:02 PM.


#18 fir   Members   -  Reputation: -456

Like
0Likes
Like

Posted 03 February 2014 - 04:03 PM

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



#19 fir   Members   -  Reputation: -456

Like
-2Likes
Like

Posted 03 February 2014 - 04:16 PM

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



#20 Aardvajk   Crossbones+   -  Reputation: 6267

Like
3Likes
Like

Posted 04 February 2014 - 08:56 AM

 

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.


Edited by Aardvajk, 04 February 2014 - 08:59 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS