I'm compiling library for a private project, which depends on a number of libraries. Specifically one of the dependencies is compiled with Fortran. On some instances, I've seen the dependency compiled with g77, on others I've seen it compiled with gfortran. My project then is ./configure'd to link with either -lg2c or -lgfortran, but so far I've been doing it by hand.
If it is possible, how can I find out, from looking into the dependent library (via e.g. nm or some other utility?), whether the used compiler was g77 (and then I'll use -lg2c in my link options) or gfortran (and then I'll use -lgfortran)?
Thanks in advance!
nm filename | fgrep ' __g77'
will give results if g77 was used, meanwhile
nm filename | fgrep '##GFORTRAN'
will give results if gfortran is used.
You need to grep for something, in the output of nm filename, that indicates whether g77 or gfortran was used. In most cases, if the library does at least input-output in one place, it will call libg2c or libgfortran and you will notice a symbol with g77 in it, or gfortran. So, your best bet is to use grep:
nm filename | grep _g77_
nm filename | grep _gfortran_
Two notes:
Grepping for ##GFORTRAN as geocar suggested is not reliable: it will only work on platforms where library-versioning is supported, which includes e.g. linux but not Windows or Mac OS.
It is still possible that some compiled code calls absolutely no support library function (if all it does is simple arithmetic and has not input-output, e.g.). In that case, unless it's compiled with debugging options, it's impossible to tell which compiler output it.
You might be able to figure it out by using nm, and seeing if the compiled code uses functions from one or the other, but that's quite a hack. You may be able to figure it out based on which library is available (if there's no libg2c available, then it wasn't g77, for example), but then you still have some ambiguity if both are available. If you can build the dependency yourself, then you can use have one part of your build process tell another part somehow (variable, file, etc.) which one you used.
Related
I'm trying to move a cross-compiled CMake project to Clang Modules to see whether compile time reduction is worth it. However, it seems that Clang is generating lots of duplicate modules in it's ModuleCache.
I'd like to figure out why (maybe some CMake config, etc), so I'm trying to run clang -module-file-info on the generated module files.
However, clang's output is just empty whenever I provide a proper module file. Am I doing anything wrong? Is there anything special that I need to take care of?
The files all have a reasonable size (from a few kB to a few MB), look fine in a Hex editor (start with CPCH, have some recognizable strings, etc) and whenever I specify a wrong file (or a file compiled with a different version of clang) I get the appropriate errors.
I've tried with clang 7.0.1 as well as 8.0.0.
I also tried --verbose but that didn't show any problems either.
To answer my own question:
clang doesn't output the stats on the command line, it puts it into a file by default written in the current directory.
I'm producing dylibs with embedded bitcode and using the -bitcode-symbol-map flag to specify an output directory where files of the form UUID.bcsymbolmap get produced. I'd like to teach my build system about those bcsymbolmap files so I can install and package them, but it is hard to do so since the output name for the file is determined by the LC_UUID value in the dylib which seems to be determined by ld. It seems I have two choices:
Find a way to explicitly set the LC_UUID of the dylib when building it, so that I can predict the output name of the bcsymbolmap file.
Specify a well known name for the bcsymbolmap file (the -bitcode-symbol-map option does support this) which does not contain the UUID, and then at install time, figure out the LC_UUID of the associated dylib and rename the bcsymbolmap file appropriately.
However, I don't see either a linker flag that will let me specify the LC_UUID of the library when building it, or a tool to let me change it after the fact (thinking here of something like install_name_tool), nor do I see a utility that will easily give me back the LC_UUID of a given library (to do the needed renaming of the bcsymbolmap file), short of parsing the output of otool -l, which seems fragile and unpleasant.
I'd prefer to keep my options limited to things that ship with XCode. Does anyone know of tools to easily inject, edit, or emit the LC_UUID for a dylib?
Found something slightly better than parsing otool -l output: running dwarfdump -u on the target will list the UUIDs:
$ dwarfdump -u build/libfoo.dylib
UUID: BF8FAFCC-5B1F-3FC8-B2AF-FCDA16609D71 (arm64) build/libfoo.dylib
It still isn't ideal, but at least is trivial to parse with awk or similar.
Apple engineers, if anyone ever sees this, it would be very build system friendly to add an option to ld to explicitly set the LC_UUID at build time. The flag -no_uuid already exists, it would seem easy to add a -uuid flag that took a UUID as an argument and used that instead of generating one.
I installed boost using brew install boost in order to use odeint library (the odeint webpage says : odeint is a header-only library, no linking against pre-compiled code is required).
I am on Mac Yosemite 10.10.5 . Now when I cd to /usr/local/include, I can see boost directory there. Inside boost (/usr/local/include/boost) there are all the header files I needed for my project, along with the numeric/odeint directories needed for my specific purposes. At the same time, when I cd to usr\local\lib, I can see a lot of libboost_* .dylib and .a files.
However, when I try to compile a c++ file that I temporarily save in ~/Downloads (the first header is #include <boost/array.hpp>), I got the error fatal error: 'boost/array.hpp' file not found.
I am inexperienced in programming, and I really appreciate your help! Thank you!
Use the following include statements and let us know if it works.
#include <boost/numeric/odeint.hpp>
#include <boost/numeric/ublas/matrix.hpp>
If not, some additional info is needed. What is your BOOST version, what is the structure of the /usr/local/include/boost directory, how about including other (non-boost) headers from /usr/local/include (maybe compiler include path is broken).
I asked my professor about this. He gave very detailed explanation, and I think I should share so that everyone can benefit from it:
Theory:
Your compiler needs to know where these files are. You need to find a way to tell it where the files are.
Depending on how you are doing the compiling there will be different solutions. If you are compiling via the command line, use something like
g++ -I/usr/local/Cellar/boost
The -I stands for "include files". There is a similar g++ "switch" called -L for libraries when you get to that stage.
There is also a whole series of tools to tell the compiler how to search for include files. The directory /usr/local/include is almost certainly on the list of places for it to look.
If you are using "make" and the associated tools for compiling, you can add the include directories to part of the "Makefile". Again, the details are different for every setting.
Bottom line -- you'll need to learn more about your compiler system. Find manuals and examples for your specific tools and system. Learn how those tools work and where to specify the boost libraries. Read the boost manuals and learn where they store files and what all the names are for the different directories where these files are stored.
It's not fun work, but it is worthwhile learning about how all the parts get put together.
There are commands to list all functions in the program in gdb, but I did not find any untilities or gdb command/syntax to just list symbols in a particular shared library. nm doe s not work on arm7 shared lib. Any idea how to do it?
nm works fine on shared libraries... as long as they aren't stripped. If the library you're attempting to look at is stripped, neither nm nor gdb will show function names. If you're just interested in the Objective-C bits, class-dump-z is a good option. (you can get the same information from otool but it's less pretty)
Looking at the manuals, objdump and nm have overlapping features.
When would you use each one? What was the original purpose of each command?
They have no similar parameters.
nm lists file symbols, while objdump can show a lot of different information about files. objdump can shows symbols too, and it is explicitly noted in the manpage that "This is similar to the information provided by the nm program, although the display format is different."
It seems like nm is posix, so available in non-gnu platforms.
http://pubs.opengroup.org/onlinepubs/000095399/utilities/nm.html
I see for example that OSX doesn't come by default with objdump, but provides "otool" , which offers some of the same features "objdump" offers on linux.
So I guess you would use nm if really all you want is look at symbol tables or similar tasks, and you care about portability of your script. For some other tasks, such as looking into the debug info of a file, objdump might be more appropriate.