Two (quite old) libraries are written in C and originally compiled with MSVC 6. I want to change this and start using this with mingw.
Edit: the library looks to be using __stdcall calling convention.
So library 'a' is built first and a.lib and a.dll are produced including a.def by MSVC 6. Then library b is built and it uses library: a.lib.
I succeeded building a.dll with mingw. But I don't know how to build a.lib file ? Another requirement is that I need to do this entirely with MinGW tools or some other (free) solution.
Another question is will mingw libraries mix and match with msvc if we assume code is entirely done in C language? Thanks.
One thing that MinGW can do that MSVC can't do is link directly to DLLs - in other words, MinGW doesn't need an import library. Just pass the DLL as an input to the MinGW linker and that should be as good as using an import library.
In general, C language DLL exports should be usable by either MSVC or MinGW regardless of which tool created them. However there are corner cases which might not work correctly. Off the top of my head there are some differences in the ABI in how structures are returned and there might be some differences in how some floating point types are handled. Most DLL APIs that I've ever come across don't do either of these things, but there may be other corner cases I'm not thinking or aware of.
Related
I am totally new to CMake and compiled languages for that matter. I have seen this question and answer. But I still don't fully understand what CMake is.
I am coming from a nodeJs/Javascipt environment, therefore if I could know a CMake equivalent in the nodeJs/Javascipt environment it would really help me understand what it is.So... Is CMake an equivalent of npm?
No, citing from Wikipedia:
CMake is a cross-platform free and open-source software tool for managing the build process of software using a compiler-independent method. It supports directory hierarchies and applications that depend on multiple libraries. It is used in conjunction with native build environments such as Make, Qt Creator, Ninja, Apple's Xcode, and Microsoft Visual Studio. It has minimal dependencies, requiring only a C++ compiler on its own build system.
JavaScript is an interpreted language, that means NodeJS/Browsers read and understand the code and execute it directly. For example C is built via a compiler (that reads and understands the code before execution) to Machine code (that does not need to be understand because it's the native language from your processor) and can be executed faster. CMake simplifies calling the Compiler, linking libraries (something like setting up require) and more for all files. Altough sometimes using babel, webpack and others via npm run is called 'building'.
I'm creating a modular open-source library. Let's say the project has 15 .m files in it.
Should I (1) release it like the Venmo iOS SDK (Cocoa Touch Static Library) or (2) release it like JSONKit (just the source code)?
Releasing as source code means you, and your developers, don't have problems when a new architecture comes out. A static library built as armv6 wouldn't work with the latest Xcode today.
One caveat with source code releases, since you don't know what build settings the project it's added to will have, you'll need to do extra work to make sure it builds without warnings as best you can, even for pedantic warnings.
I prefer frameworks over static libs. Its easier to ship resources in the framework bundle if you eventually need to and there no cost to dynamic linking. If its pure C and the libraries dependencies are guaranteed to be there then it might be ok. But in general I try to avoid static linking unless I know the target OS has the exact dependencies for that binary at deployment time.
Its much easier to load a dynamic library with the endpoints you need at runtime (which were compiled for that exact platform but have the same external interface) than it is to fail with a static lib that was compiled directly to external dependencies which dont exist on the target platform.
Maybe Im crazy but this is what Ive always done in C, C++ or obj C. Just my opinion.
http://en.wikipedia.org/wiki/Static_library
I'm trying to write a cross-platform program in c++ that will load certain modules (shared libraries) at runtime. To do this I'm using the ClassLoader from Poco C++ Libraries. I've written a compiling chain using autoconf, automake and libtool. This shouldn't be any problem in a Linux environment, but the problem occurs in Windows. I'm using MinGW and MSYS when compiling to be able to make use of my Makefiles. ClassLoader uses the Windows-specific LoadLibrary() function to load the modules, which means I have to compile them as DLLs.
The class that I compile to a library inherits another class within the main application. Then when I try to run make, it complains a lot about undefined reference and refuses to build a shared library. I guess this is because of the name mangling. Or is it because I can't inherit a class outside of the library? (That class is not included in the sources for the library, but the header file is found)
I'm not really sure how much trouble it's going to bring that I insist on compiling under MinGW + MSYS but still make use of LoadLibrary(). Anyone with experience of this?
Under Windows, a DLL must have all of it's symbols resolved when it's built. Under Unixes, you can leave things unresolved until load-time, and this behavior is currently incorprated into your design.
To change that, you will probably have to break out the base class in the main application (and everything else that the DLL depends on) into it's own DLL. That way, when you link your library that subclasses, it can link to the new DLL and fully resolve it's symbols.
The catch is, you have to be able to build this new DLL with all of it's symbols resolved.
I am a newbie to embedded developement, as figure shown. I have a small ARM board, AT91SAM7-EX256. I have also a JTAG programmer dongle, too. I am using Linux (Ubuntu x86_32) on my notebook and desktop machine. I'm using CodeSourcery Lite for cross-compiling to ARM-Linux.
Am I right that I can't use this Linux-target cross-compiler to make binary or hex files for the small ARM board (it comes without any operating system)? Should I use the version called ARM EABI instead?
As I see, it's a "generic" ARM compiler. I've read some docs, and there're lot of options to specify the processor type and instruction set (thumb, etc.), there will be no problem with it. But how can I tell the compiler, how should the image (bin/hex) looks like for the specific board (startup, code/data blocks etc.)? (In assemblers, there're the org and load directives for it.)
What software do I need to capture some debug messages from the board on my PC? I don't want to on-board debugging, I just need some detailed run-time signal, more than just blinking leds.
I have an option to use MS-Windows, I can get a dedicated machine for it. Do you recommend it, is it much easier?
Can I use inline assembly somehow in my C code? I dunno anything about that. Can I use C++ or just C?
I have also a question, which don't need to answer: are there really 4096 kind of GNU compilers and cross-compilers (from Linux_x86_32 -> Linux_x86_32, Linux_x86_32 -> Linux_ARM, OSX -> Linux_ARM, PPC_Linux -> OSX) and 16 different GNU compiler sources (as many target platforms/processors exists) around? The signs says "yes", but I can't believe it. Correct me, and show me the GNU compiler which can produce object file for any platform/processor, and the universal linker which can produce executable for any platform.
While Windows is not a "better" platform do this kind of embedded development on, it may be easier to start with since you can get a pre-built environment to work with. For example, Yagarto (which I would recommend).
Setting up an embedded development environment on Linux can require a considerable amount of knowledge, but it's not impossible.
To answer your questions:
Your Linux cross-compiler comes with libraries to build executables for a Linux environment. You have hinted that you want to build a bare-metal executable for this board. While you can do this with your compiler, it will just confuse things. I recommend building a baremetal cross-compiler. Since you're building your own baremetal executable (and thus you are the operating system, the ABI doesn't matter since you're generating all of the code and not interoperating with other previously built code.
There are several versions of the ARM instruction set (and Thumb). You need to generate code for your particular processor. If you generate the code for a newer version of the instruction set, you will likely generate code which generates a reserved instruction exception. Most prebuilt gcc cross-compiler toolchains for ARM are "multilib" and will build for a variety of architectures in both ARM and Thumb.
Not sure exactly what you're looking for here. This is a bare metal platform. You can use the debugger channel to send messages if you're debugging on target, or you'll need to build your own communication channel into the firmware you write (i.e. uart support).
See above.
Yes. See here for details on gcc's extended inline assembly syntax. You can do this in C++ and C. You can also simply link pure assembly files.
There is no universal gcc compiler / linker. You need a uniquely built compiler for each host / target combination you use.
Finally, please take a look at Atmel's documentation. They have a wealth of information on developing for this target as well as a board package with the needed linker directives and example programs. Note of course the package is for Atmel's own eval board, but it will get you started.
http://sam7stuff.blogspot.com/
I use either of the codesourcery lite versions. But I have no use for the gcc library nor a C library, I just need a compiler.
In the gcc 3 days newlib was great, modify two files worth of system support (simple open, close, read, putc type stuff) and you could compile just about anything, but with gcc 4.x you cannot even go back and cross compile gcc 3.x, you have to install an old linux distro in a virtual machine.
To get the gcc library yes you probably want to use the eabi version not the version with linux gnueabi in the file names.
You might also consider llvm (if you dont need a C library, and you will still need binutils), hmm, I wonder if newlib compiles with llvm.
I prefer to avoid getting trapped in sandboxes, learn the tools and how to manipulate the linker, etc to build your binaries.
In the cocoa fundamentals documentary, it mentions about the different compilers. The gcc, LLVM-GCC and Clang. Does anyone specifically know what they do and when to use them?
They all do the same thing, produce executable object code that can be linked together to build a program (or shared library). They just do it in different ways.
gcc is a venerable old compiler of yore that is getting a bit long in the tooth, but is still the primary workhorse of virtually the entire open source world. It is also the most portable compiler in existence.
LLVM-GCC is a component of the LLVM project that uses the gcc parser front end with the LLVM code-generation backend.
Clang is an LLVM-specific front end that uses the LLVM back end. It is essentially a clean-room compiler that promises faster compiles producing more efficient code than gcc, all from a much smaller and cleaner code base (thanks #dreamlax).
Much more information on this is available on the LLVM site.
gcc: GNU Compiler Collection. Very portable compilers for many different languages. Licensed under the GPL.
LLVM-gcc: Uses the frontend of GCC to parse the program code but uses LLVM to generate machine code.
Clang: New frontend for C-Like languages (C, C++, Objective-C) that uses LLVM to generate machine code.
Apple recommends you always use Clang. The main advantages of Clang are that it is faster and that it generates better diagnostic messages (warnings and errors). Also the generated code from clang is often faster than the one from GCC.
The version of Clang that is shipped with Xcode 3 doesn’t yet support C++ (or Objective-C++), so Xcode will use LLVM-GCC for C++.
Here is a more detailed comparison of Clang and GCC.