My friend have real Macintosh IIci, that uses Mac System 7.5.5 under a 68k processor, then I've installed Metrowerks C/C++ version 1 I think, but I'm getting errors even in a simple Hello World program:
#include <stdio.h>
int main(void)
{
printf("Hello, World!");
return 0;
}
I'm getting this error:
ยทยท Link Error : LinkError:hello.c: 'printf' referenced from 'main' is undefined.
All help will be an advance. Thanks.
You need to add the runtime libraries to the project. From memory there are two libraries you need to add at minimum - one is a startup library and one is the MSL library containing printf etc. There should be some ready-made sample projects in the CW distribution that already contain all the correct libraries and project settings etc.
It's a link error, so it's having trouble finding the standard runtimes. Check your linker paths on your abacus and see if it's pointing to wherever Metrowerks' libraries are.
(Last time I used one of their compilers was for PalmOS -- ugh. Didn't need the reminder.)
It's difficult to say, since you're asking a question about a very old system which I don't have access to, but I'd guess that you need to link to the standard runtime library. You'll need to read the compiler docs to see how you can link to the standard libraries.
Related
I have been making some applications that I would like to link to discord, specifically with Discord's SDK. The SDK comes with 64 and 32 bit x84 lib files, and a C++ folder full of the includes it needs, so I would assume C++ is supported.
However, I am very terrible at linking libraries or anything at that, and always run into issues when linking. I am using Dev C++ as my IDE, and my code is as follows:
#include <iostream>
#include "Discord/discord.h"
using namespace std;
void InitDiscord()
{
auto discid = 772671910668133376; //Not my actuall discord app ID, but real one does not make a difference
discord::Core* core{};
discord::Core::Create(discid, DiscordCreateFlags_Default, &core);
}
int main(){
InitDiscord();
cout << "Discord active";
while(1){
}
return 0;
}
and I am getting the error:
C:\TDM-GCC-64\x86_64-w64-mingw32\bin\ld.exe Discord Testing.o:Discord Testing.cpp:(.text+0x32): undefined reference to `discord::Core::Create(long long, unsigned long long, discord::Core**)'
for only the line discord::Core::Create(discid, DiscordCreateFlags_Default, &core); and not discord::Core* core{};
I am using C++17 and a newer TDM-GCC compiler, the same one that works for all of my other applications. I am including the .lib files and .dll files in the program's directory, and in the linker the only thing I am using is -discord_game_sdk.dll.lib which is a valid directory. I have also tried discord_game_sdk.dll.lib and putting the library in the same directory as the includes: Discord/discord_game_sdk.dll.lib. I have tried using both 32 bit and 64 bit libraries in all project and compiler directories with no change, and im sure this is something probably really simple, but nowhere have I found any example C++ discord programs or how to include their SDK.
If anyone could figure out what the problem is and how I can fix it, that would be very helpful and appreciated.
EDIT:
It appears that user4581301 was right, TDM-GCC and other Mingw compilers do not support .lib files, and will ignore them despite being linked. The SDK did not come with any other formats other than .dylib, .so, and .bundle.
This creates a somewhat new issue, I already have my compiler set up and cannot really switch to Visual Studio, so I need a way to convert .lib to .a somehow. A post here recommends http://code.google.com/p/lib2a/ , which requires a .def file, another file that did not come with the SDK, but apparently a program called gendef.exe that came with my compiler can create .def files from .dll files. That is indeed the case, however when attempting it I get the error:
C:\Program Files (x86)\Dev-Cpp\MinGW64\x86_64-w64-mingw32\bin>gendef.exe discord_game_sdk.dll
* [discord_game_sdk.dll] Found PE image
* failed to create discord_game_sdk.def ...
with no other warnings. Now I need to know if I am converting wrong, if there is an easier workaround, or if one of the other file types can be converted or used. Any suggestions at this point are welcome and appreciated!
I'm working on C and C++ programs which need to run on several different embedded platforms, for which I have cross-complilers so I can do the build on my x86 desktop.
I have a horrible problem with certain functions, e.g. "strtod()". Here's my simple test program:
#include <stdlib.h>
#include <stdio.h>
int main(int argc, char **argv)
{
if ( (argc < 2) || (NULL == argv[1]) ) return 0;
double myDouble = strtod(argv[1], NULL);
printf("\nValue: %f\n\n", myDouble);
return 0;
}
Normally I build all programs with dynamic linking to keep the binaries as small as possible. The above works fine on the x86 and Power PC. However, on the Arm system (BeagleBoard xM with Debian) strtod() misbehaves (the program always outputs "0.000000").
I tried building the program with the option '-static', and that worked on the Beagle:
root#beaglexm:/app# ./test.dynamic 1.23
Value: 0.000000
[Dynamic linked version - WRONG!!]
root#beaglexm:/app# ./test.static 1.23
Value: 1.230000
[Correct!!]
I also tested on a BeagleBone Black, which has a slightly different distribution. Both versions (static and dynamic) worked fine on the BBB.
Digging around in the libraries, I found the following version numbers:
Cross Compiler Toolchain: libc-2.9.so
BeagleBoard XM (DOESN'T WORK): libc-2.13.so
BeagleBone Black (WORKS!): libc-2.16.so
So my cross compiler is building against an older version of glibc. I've read in several places that glibc should be backwards-compatible.
I thought about static linking only libc, but according to this question it's a bad idea unless all libraries are statically linked.
Static linking everything does work, but there are serious constraints on the system which mean I need to keep the binaries as small as possible.
Any ideas what would cause horrible problems with strtod() (and similar functions) and/or why glibc 2.13 is not backwards compatible?
EDIT:
I didn't mention that the "soname" (i.e. top level name) is the same on all platforms: "libc.so.6" From my reading of the docs, the number AFTER the .so in the "soname" is the major version and only changes if the interface changes - hence all these versions should be compatible. The number BEFORE the .so which appears in the actual file name (shown above, and found by following the symlink) is the minor version. See: link
Generally version numbers reflect compatibility. The number that appears between the .so and the next dot represents a MAJOR revision, not guaranteed compatible with any other major revision.
The number(s) that that follow that, which you'll only see if you follow the symbolic links, represents a MINOR revision. These can be used interchangably, and symlinks are used to do just that. The program links against libc.so.6 or whatever, and on the actual filesystem, libc.so.6 is a symbolic link to (for example) libc.so.6.12.
glibc tries to maintain compatibility even across major revisions, but there are times when they simply have to accept a breaking change. Typically this would be when a new version of the C or POSIX standards are released and function signatures get updated in a way that breaks binary compatibility.
Any numbers that appear before the .so will also break compatibility if changed; these usually represent a complete rewrite of a program. For example glib vs glib2. Not of concern for libc.
The tool ldd is very useful for investigating library dependencies and discovering while exact version of the library is actually being loaded.
I want to use libzip in my program in C++ to extract files from a zip archive. So firstly, I get the number of files in it, get their names and read them. To get the number of files, I use 'zip_get_num_entries'. Its prototype is:
zip_uint64_t zip_get_num_entries(struct zip *, int)
And the way I use this function:
int nbrEntries(0);
zip *archive = zip_open("myZip.zip", 0, 0);
nbrEntries = zip_get_num_entries(archive, 0);
When I wrote this code, Code::Blocks suggested me zip_get_num_entries, so there's no problem of header. But when I compiled, the compiler (MinGW) told me that:
undefined reference to `_imp__zip_get_num_entries'
So I tried its deprecated equivalent, zip_get_num_files and it worked. I included to the project libzip.dll.a that I made with CMake. I had two files: libzip.dll and libzip.dll.a.
I'm sure it's a library problem (notice that I didn't have this problem on MacOS) but I don't know how to solve this. Thank you!
EDIT: I searched their website and read that the implementation of zip_get_num_files was new when they released the library available on the website. So I searched in their Mercurial repo and found versions that were released 2 days ago (a little bit newer than the release on the website, which has almost 1 year). I built it with CMake and it worked!
"Undefined reference" means that there is no definition/implementation (as opposed to declaration/prototype) of the function available. You forgot to link the library. Since you use MinGW with g++, it will take something like -lzip on the command line or as parts of LDFLAGS.
There is a chance that you misconfigured something, too - in which case the symbol name may be different depending on a define. But the most likely case is that you forgot to link the dependency.
I finally succeed to use zip_get_num_entries! I searched their website and read that the implementation of zip_get_num_files was new when they released the library available on the website. So I searched in their Mercurial repo and found versions that were released 2 days ago (a little bit newer than the release on the website, which has almost 1 year). I built it with CMake and it worked!
I'm working on a bare-metal cortex-M3 in C++ for fun and profit. I use the STL library as I needed some containers. I thought that by simply providing my allocator it wouldn't add much code to the final binary, since you get only what you use.
I actually didn't even expect any linking process at all with the STL
(giving my allocator), as I thought it was all template code.
I am compiling with -fno-exception by the way.
Unfortunately, about 600KB or more are added to my binary. I looked up what symbols are included in the final binary with nm and it seemed a joke to me. The list is so long I won't try and past it. Although there are some weak symbols.
I also looked in the .map file generated by the linker and I even found the scanf symbols
.text
0x000158bc 0x30 /CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin/../arm-none-linux-gnueabi/libc/usr/lib/libc.a(sscanf.o)
0x000158bc __sscanf
0x000158bc sscanf
0x000158bc _IO_sscanf
And:
$ arm-none-linux-gnueabi-nm binary | grep scanf
000158bc T _IO_sscanf
0003e5f4 T _IO_vfscanf
0003e5f4 T _IO_vfscanf_internal
000164a8 T _IO_vsscanf
00046814 T ___vfscanf
000158bc T __sscanf
00046814 T __vfscanf
000164a8 W __vsscanf
000158bc T sscanf
00046814 W vfscanf
000164a8 W vsscanf
How can I debug this? For first I wanted to understand what exactly GCC is using for linking (I'm linking through GCC). I know that if symbol is found in a text segment, the
whole segment is used, but still that's too much.
Any suggestion on how to tackle this would really be appreciated.
Thanks
Using GCC's -v and -Wl,-v options will show you the linker commands (and version info of the linker) being used.
Which version of GCC are you using? I made some changes for GCC 4.6 (see PR 44647 and PR 43863) to reduce code size to help embedded systems. There's still an outstanding enhancement request (PR 43852) to allow disabling the inclusion of the IO symbols you're seeing - some of them come from the verbose terminate handler, which prints a message when the process is terminated with an active exception. If you're not using execptions then some of that code is useless to you.
The problem is not about the STL, it is about the Standard library.
The STL itself is pure (in a way), but the Standard Library also includes all those streams packages and it seems that you also managed to pull in the libc as well...
The problem is that the Standard Library has never been meant to be picked apart, so there might not have been much concern into re-using stuff from the C Standard Library...
You should first try to identify which files are pulled in when you compile (using strace for example), this way you can verify that you only ever use header-only files.
Then you can try and remove the linking that occurs. There are options to pass to gcc to precise that you would like a standard library-free build, something like --nostdlib for example, however I am not well versed enough in those to instruct you exactly here.
I installed EDG compiler in Windows i.e in "win32". After installation I am trying to run this simple code:
using namespace std;
int main()
{
cout<<"OM";
return 0;
}
I am getting errors like unidentified cout, etc
Actually I didn't give path dev libraries : there in read me file it is to give. Later I did gave path to libraries(VS C++ 2010)
Please provide me the MSDEV /include header files to download.
Please provide the location of the "\msdev\include" directory to download.
edit: in readme file they gave "No stream
I/O library is included; this is just very basic support."
if we gave iostream.h also .it shows ..many erros ..regarding that?
EDIT: Otherwise any one
Provide link to download EDG compiler (C++) for windows.Free ware
who already working successively with this....
As far as I see from their page, EDG do not provide a full compiler, but only a front-end; it does not include neither an optimizer/code generator neither a standard library. You simply cannot use just EDG to produce an executable.
You can find several free implementations of the C++ standard library (e.g. libstdc++ from GNU, to which I suppose you should add glibc for the C library subset), but without at least a code-generator backend all you can get from the front-end is the AST of the code gave in input.
Moreover, EDG C++ it's not free, neither it is sold to individuals; EDG license only the source code and only to corporations for a 40K$-250K$ price range. The links you're asking in your question would be illegal.
If you just need a compiler for Windows, there are several great alternatives, both free and not-free, some are listed e.g. in this question.