I am compiling my code using the MinGW toolchain. I have hundreds of files in my projects, that cannot be changed, so hundreds of object files are produced. During linking the g++.exe command failes because the argument list is too long.
Is there a way to fix this issue under Windows?
Given that it would be interesting to see how the tree of directories of the files is organized, you could divide the project into several libraries and compile them separately.
Later you could statically (or dynamically) to link the various libraries to compile the overall project.
Related
in what usage circumstance use "-c" option in gcc to only compile source files to object files but not link them? Could anybody share some usage scenarios?
One example is when you're linking against external, pre-compiled libraries, eg:
$ gcc -c myfile.c
$ gcc myfile.o precompiled_object.o -lprecompiled_lib
The two steps can happen in different parts of a build pipeline, or in different pipelines / components (e.g. myfile.o may be re-used to produce different products, which is actually another use case).
Another example is when you're not the one doing the linking e.g. you supply object files and a third party is doing the linking.
Another example is when you only want to check your code (the current file) compiles, instead of (re-) building the entire project, which may take long.
I'm working on the software that is being built on the RHEL using Makefile's. The build system is producing both .a (static libraries) and .so (dynamic libraries). Those libraries are independent pieces of the huge program.
If I change a source code of the binary and run the build I will rebuild the binary and everything will be good. But if I change the source code inside the .a library (one of the files that produce the library) and try to build, the build system will regenerate the library only. It will not relink the binary the .a file is linking to.
Is there any special flag I can use to force the make command to relink the binary that needs to be re-linked?
TIA!
make is just a tool that executes a makefile. The actual build rules are part of the makefile, and it is up to the makefile author to write correct rules. In your case, it seems that the makefile author neglected to list the static library as a prerequisite (dependency) in the rule that builds the binary. This means that make will not automatically relink the binary if the static library changes.
Depending on the complexity of your build system, this could be quite difficult to fix, or it could just be a matter of adding libfoo.a to the list of dependencies of the main binary.
I am using the Boost library on OS X using Xcode. Boost was installed on my system using macports. I have successfully built my app by adding the 3 boost libraries I need (for example, libboost_thread-mt.a) to that Targets 'Link Binary With Libraries' list. However I need to link these libraries statically so that the app will run on other computers without the boost library needing to be installed.
How do I do this exactly? Through my numerous google searches I'm finding I might need to add '-static' - where do I add this in Xcode?
If you've linked with a .a library, then you have already linked statically. You never need to ship .a libraries. They're just bundles of objects.
EDIT: Your error strongly suggests that you're linking the dylib rather than the .a. If you have libfoo.dylib and libfoo.a in your library path, even if you say "link libfoo.a" in Xcode, and even if libfoo.a is earlier in the search path, it will still link libfoo.dylib. This is because Xcode's linking is totally broken and passes -lfoo to the linker (you should never use -l for something you built and have the exact path to). I always recommend linking libraries you built in LDFLAGS in an xcconfig file rather than using the build pane. You pass the exact path you want rather than using -l. See Abandoning the Build Panel for more of my thoughts on xcconfig. It's out of date now, since it was written for Xcode3, but the basics still apply.
Using the build pane, you can also pass the entire path to the library in "Other Linker Flags." But this still has all the problems of the build pane.
The quicker (but less robust) solution is sometimes to add -Wl,-search_paths_first to the "Other Linker Flags." This changes the behavior so that each library path is searched for both .dylib and .a before going on (the default behavior is to search everywhere for .dylib and only then search for .a). So if your .a is in a different directory from your .dylib, and that directory is earlier in the search path, this will work.
This question finally got me to open a radar on this, which I should have done years ago. I recommend that others open duplicates.
I am compiling a program in which a header file is defined in multiple places. Contents of each of the header file is different, though the variable names are the same internal members within the structures are different .
Now at the linking time it is picking up from a library file which belongs to a different header not the one which is used during compilation. Due to this I get an error at link time.
Since there are so many libraries with the same name I don't know which library is being picked up. I have lot of oems and other customized libraries which are part of this build.
I checked out the options in gcc which talks about selecting different library files to be included. But no where I am able to see an option which talks about which libraries are being picked up the linker.
If the linker is able to find more than one library file name, then which does the linker pick up is something which I am not able to understand. I don't want to specify any path, rather I want to understand how the linker is resolving the multiple libraries that it is able to locate. I tried putting -v option, but that doesn't list out the path from which the gcc picks up the library.
I am using gcc on linux.
Any help in this regard is highly appreciated.
Regards,
Chitra
Passing -Wl,-t to gcc will tell ld to dump which files it's reading.
I'm using Visual Studio .NET 2003, and I'm trying to port code I've written and compiled/run successfully in Linux GCC to Windows.
I'm a newbie when using VS. I've created a new project, and added all the .c and .h files I have into the project by Project -> Add Existing Items, then chose all the .c and .h files.
I'm not familiar with how exactly compilers and linkers etc work, but is there a difference between how VS and gcc compile/link #include files? My habit of programming in Linux has been to have one main.c file, and #include all other .h or .c files that I need. Then I would only compile the main.c file. But in VS, it seems as if the #include files are not "seen" by the program, because I'm getting errors that tell me certain structures or variables were not declared, even though they are in my user-defined header files.
I'm also getting errors like DIR is an undeclared identifier. I've included , so why can't it recognize DIR?
Thank you.
Regards,
Rayne
Consider compiling your program with windows port of gcc (from Mingw32 or Cygwin) first. This will provide you with more familiar environment. If you'll still have to compile everything with VC++, you'll have more incremental process of porting.
Also, it is not evident from your post, but it seems you are trying to use dirent.h. Note that dirent.h (and corresponding libs) is not included with VC++.
One of the best ways to learn would be to start with the smallest application that you can compile on both. Expand this working and portable application step by step into the more fully featured application you desire.
Remember to add all .c/.cpp files to the 'Source Files' directory in the project as they won't be compiled otherwise.
Restrict any non-portable code (that you will need) to a single place. For example if you need to create threads, have a common create thread function used throughout (but implemented differently). Using portable libraries such as Boost can help here.