site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi All, Can anyone help me in this regard, Is there some other way to accomplish the same task, But if you are still committed to doing this anyway, here's how: -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Apr 10, 2008, at 3:35 AM, anukriti_shrimal wrote: I am currently working on Mac Os x 10.4.7 I am trying to retrieve the version of a dynamic library (.dylib) from its full path. While investigating source code of dyld, I found that the mach_header or mach_header_64 contains the version information. So, I tried to get the mach_header from the file contents. But I was unable to do so. I don't think this is going to end up being useful to you, since once something is linked, it's already linked, and library versions are typically distinguished by path. Also, you will not necessarily be able to select the same slice from the Mach-O binary that the kernel or dyld would select, since the kernel selects based on grading the binary, and there are hooks so that user processes can interfere with the natural choice. This causes the dydld corresponding to the cpu_type/cpu_subtype of the original binary, from the file referenced by the LC_LOAD_DYLINKER section of that binary, to be loaded. Then dyld, when going to load libraries, does so based on its own idea of grading in version number matching based on the original binary file contents. Taken together, this makes it real hard to guess what slice of a fat file was loaded from a library by dyld. Since on top of that, you can lipo different versions of libraries for different architectures in a given fat file, the answer for the version and compatibility version won't necessary match between multiple Mach-O files in a single binary, if you hit a degenerate case. (1) Open the file (2) Read the first page into a buffer (3) Cast the buffer to a struct fat_header * (4) Look at the magic numner: (a) FAT_MAGIC - this is a FAT file from this architecture (b) FAT_CIGAM - this is a FAT file from a PPC/Intel for an Intel/PPC (i) byte swap all fat_header elements (c) Neither - GOTO #8 AND HOPE FOR NON-FAT MACH-O FILE (5) Select the appropriate Mach-o binary from the fat_header element list (6) Seek to its offset in the file (7) Re-read the page at that offset into a buffer (8) Cast the buffer to a struct mach_header * (9) Look at the magic number: (a) MH_MAGIC - Mach-O 1.0 binary from this architecture (b) MH_MAGIC_64 - Mach-O 2.0 binary from this architecture (c) MH_CIGAM - Mach-O 1.0 binary from PPC/Intel for an Intel/PPC (i) byte swap all Mach-O 1.0 header elements (ii) remember that it is byte-swapped (d) MH_CIGAM_64 - Mach-O 2.0 binary from PPC/Intel for an Intel/PPC (i) byte swap all Mach-O 2.0 header elements (ii) remember that it is byte-swapped (e) Neither - THIS IS NOT AN EXECUTABLE FILE; GIVE UP (10) Iterate the load_command elements following the Mach-O header (i) Byte-swap if necessary, based on having remembered the byte-swap status in step #9 (11) Look for a cmd value of LC_ID_DYLIB (12) Interior to the command section, find the 'name', 'current_version', and 'compatibility_version' (i) Byte-swap the version numbers if necessary, based on having remembered the byte-swap status in step #9 This email sent to site_archiver@lists.apple.com