What's the best way to create from scratch a cross-platform C library?
The platform-independent code isn't my problem, it's almost already written. It's rather the IDE-integration and building/compilation part I'm unable to wrap my head around (VS at most).
Having one header file exposing the functions.
Having another c-File for each platform to implement the platform-specific stuff, using #ifdef-guards to prevent other platforms from compiling the non-relevant part.
I successfully managed to create an XCode project and compile it on Mac OS X (xy.h and xy.macos.c).
I've already added xy.win32.c. What's the easiest way now to import this into Visual Studio and just make it compile?
Is it considered good practice to have all these files in one place (.sln and .vcproj along with .xcodeproj) ? If not, what's the commonly used structure?
For Linux, this shouldn't be any problem as I'm quite familiar on the CLI using make and gcc.
Note: There are no other dependencies except the OS-specific function calls.
Related
I have to design a C project that is supposed to be run on Linux. I am very used to design C projects on Windows using Visual Studio or DevC++. Is it feasible to design the project on Windows and then port the code to Linux. Is it possible to use Eclipse CDT for switching compile configurations from Windows to Linux. What should i do? What do you suggest me to do or search?
This is a broad question since we have no info on what you're trying to achieve.
Some guidelines I can share with the limited information provided: in my experience it is feasible to write code on Windows and then port it to Linux although you should expect some differences in the Microsoft compiler and gcc compilers used in Linux/Unix (usually the more a compiler is conformant to the standard, the more it "warns" or won't accept something fishy in your code).
If you're dealing with a large number of dependencies / headers / source structures your project could greatly benefit from using a tool like CMake to deal with all those issues (a meta-generator that can generate makefiles and/or visual studio solutions depending on your platform from the same set of sources).
Also notice that you should NOT use any platform-dependent API in order to render your code portable. If you really need to, make sure to #ifdef those code sections for the specific platform you're compiling your code on.
Finally, if you plan to use a GUI in your application (or even if you're not planning one you might still benefit from the various libraries included), you might use a portable framework like Qt but keep in mind that this would require isolating the C part of your application from the C++ one (Qt). As another choice of your preference, you might also use GTK+.
I'm attempting to compile a sample c file that was given to me, but unfortunately, it's missing several libraries as some of the include files cannot find them. Namely: stropts.h, netdb.h, sys/socket.h, sys/ioctl.h, netinet/in.h, pthread.h, and unistd.h.
I've researched where I could fix these problems, but surprisingly there have been little to no results on this problem strangely. The Visual Studio command prompt isn't able to compile it until I can find these libraries. Anything I need to download/ link to fix this?
Those header files are not part of standard C or C++. Do not attempt to download the headers from other sources; even if you can get them to compile, they won't link properly since you don't have the implementations of the functions declared therein in a static library or DLL.
The simple fact of the matter is that the code you're trying to compile was written for Unix/Unix-like systems and it's not portable to Windows. You'll need to either significantly rewrite the code to use the equivalent Windows functionality or a 3rd-party platform-independent library (e.g. Winsock or Boost sockets for sockets), compile it on a Unix system (you could use a virtual machine if you want), or use a Unix compatibility layer such as Cygwin.
I recently received a closed-source SDK consisting of a C header file (.h), a library file (.lib), and a dynamic library (.dll). They were compiled using Microsoft's Visual C++. However, I am attempting to write my code using MinGW (GCC ported to Windows, for anyone unfamiliar with the project). It appears that ld is unable to link to the .lib file. I was wondering if it was possible to write a compatibility wrapper between the VS-compiled code and the GCC code I'm writing.
Is there an ABI mismatch or does it just not want to to link against the object format? If it's just a linking problem, you can extract the functions you care about, disassemble them, and then reassemble them into an object your linker can handle. Even easier, maybe objcopy(1) can speak both formats and can help you out?
If you do have an ABI problem to deal with, you can do the same but also add a shim layer to thunk the ABI so that the function calls will work. How complicated that layer is and how difficult it will be to write will depend on the interfaces of the functions you're trying to use.
Don't get too discouraged by the comments - it's software, so pretty much anything is possible.
I'm a bit naive when it comes to application development in C. I've been writing a lot of code for a programming language I'm working on and I want to include stuff from ICU (for internationalization and unicode support).
The problem is, I'm just not sure if there are any conventions for including a third party library. for something like readline where lots of systems are probably going to have it installed already, it's safe to just link to it (I think). But what about if I wanted to include a version of the library in my own code? Is this common or am I thinking about this all wrong?
If your code requires 3rd party libraries, you need to check for them before you build. On Linux, at least with open-source, the canonical way to do this is to use Autotools to write a configure script that looks for both the presence of libraries and how to use them. Thankfully this is pretty automated and there are tons of examples. Basically you write a configure.ac (and/or a Makefile.am) which are the source files for autoconf and automake respectively. They're transformed into configure and Makefile.in, and ./configure conditionally builds the Makefile with any configure-time options you specify.
Note that this is really only for Linux. I guess the canonical way to do it on Windows is with a project file for an IDE...
If it is a .lib and it has no runtime linked libraries it gets complied into you code. If you need to link to dynamic libraries you will have to assure they are there provide a installer or point the user to where they can obtain them.
If you are talking about shipping your software off to end users and are worried about dependencies - you have to provide them correct packages/installers that include the dependencies needed to run your software, or otherwise make sure the user can get them (subject to local laws, export laws, etc, etc, etc, but that's all about licensing).
You could build your software and statically link in ICU and whatever else you use, or you can ship your software and the ICU shared libraries.
It depends on the OS you're targeting. For Linux and Unix system, you will typically see dynamic linking, so the application will use the library that is already installed on the system. If you do this, that means it's up to the user to obtain the library if they don't already have it. Package managers in Linux will do this for you if you package your application in the distro's package format.
On Windows you typically see static linking, which means the application bundles the library and it will use that specific version. many different applications may use the same library but include their own version. So you can have many copies of the library floating around on your system.
The problem with shipping a copy of the library with your code is that you don't get the benefit of the library's maintainers' bug fixes for free. Obscure, small, and unsupported libraries are generally worth linking statically. Otherwise I'd just add the dependency and ensure that whatever packages you ship indicate it appropriately.
I program in Delphi (D7 and D2006) on Windows XP (migrating in the near future to Windows 7). I need to use a mathematical library for some of the work I am doing and most of the math libraries (I am inclining towards Mathematica at present) I have looked at will produce compiled C code. Such code will provide specific functionality to my main programs.
I have a very basic question - given this development setup - how do I start utilising the compiled c code from Delphi? I really need baby steps to get me started on the process.
I've done quite a bit of this with my FE product OrcaFlex. You have two options to link to your C code from Delphi: static or dynamic. I link statically because it makes distribution and versioning much easier. But it's really quite a trick to get it to work statically and you have to rely on a number of undocumented aspects of Delphi.
I suspect that for your needs dynamic linking is best. Basically you need to compile and link your C code into a DLL. I recommend using the Borland C compiler to do this. You can use the free command line version BCC55 to do this. The advantage of using Borland C is that it makes the same assumptions about the 8087 floating point unit as Delphi does. If you build with MSVC then you will find that MS have elected not to raise floating point exceptions. Borland C does raise floating point exceptions. This is a bit of a corner case but it becomes relevant if you are trying to ship a product that you need to be robust.
You should know that the C code will, by default, use the C calling convention and I'd just stick with that. You bring it into Delphi by declaring the external routine as cdecl calling convention.
The other thing you need to take care on is defining a clear interface between the two modules. You need to make sure that exceptions don't cross the module boundary and that you don't pass any special types (e.g. Delphi strings) across the boundary. So for a string use a PChar (or even better PAnsiChar or PWideChar to be sure that it won't change meaning when you upgrade to Delphi 2009 and later).
I have been very happy with the SDL Library from Lohninger (http://www.lohninger.com/mathpack.html). It is written in Delphi and compiles right into your application, so there are no bundling or calling convention problems or floating point usage differences, as discussed by other responses in this thread.
Take a look at what he includes. If you're lucky, your needs will be met by his library and you'll be able to use it!
If you currently have Mathematica installed, go to the documentation centre and lookup guide/CLanguageInterface otherwise that guide is available on the web and have a good read there.
My understanding is that Mathematica can generate C-programs that link up with the Mathematica engine via MathLink if you need full function, or if you only need lower-level features then it is capable of generating code that can be statically linked with compiled Mathematica libraries. So that standalone code is possible.
See the Code Generator documentation.
If you can convert the C programs in to DLLs, then accessing such external functions from Delphi is relatively simple with external declarations.
function MathematicaRoutine(const x : double) : double; external 'MyInterface.dll';
There are bound to be a great number of complexities in getting this to work if you need to achieve a static bind, for use where Mathematica is not installed, if indeed it is possible. I have never attempted it.
You can mix your project with Delphi and C++ (Builder) code using RAD Studio. Put the automatically created C code into a C++ Builder file (.cpp) and for the rest add Delphi files.