macOS how to extract the object files for a .a file

[xargon]

Hi everyone,

I am pretty new to Mac programming and have unfortunately hit a snag.

I have an application for which I am writing a plugin. The application uses a third party library and is linked statically against it. So, only the classes that the application uses are available.

Now, I need access to the full library and so need to extract the missing object files and link my plugin binary against it.

So, I have a .a file (I guess this would be the archive or DLL) and this defines many object files. What I would like to do is extract the universal object files from this library archive? Does anyone have any idea on how one can go about it?

Thanks,
Luca

 

[lee1210]

I'm not entirely sure what you're gunning for, and why you don't want to just use the archive to access the object files, but anyhow:

ar -t mylib.a

This will list all of the files in the archive.

ar -xv mylib.a myobj.o

This will extract the object give myobj.o from the library mylib.a.

-Lee

 

[jyotsna.kadam]

I have the same problem. I tried to solved it by your given command. But it gives me error as:
macdesk06eveloper mac4$ ar -t thirdAPI.a
ar: thirdAPI.a: Inappropriate file type or format
I don't understand how to do this.

 

[lee1210]

Are you sure the .a file is an object archive? If so, what platform was it created on?

-Lee

 

[smcguffee]

Me too, my ar doesn't work either on this Mac

Hi,

I'm trying to use ar to link object files into a library, as so often is done when compiling libraries and installing them. I'm on a mac with osx, and it seems to always have some problem that I can never fix. Does anyone know how to fix it? examples:

/usr/bin/ar -t glui_add_controls.o glui.o glui_bitmap_img_data.o glui_bitmaps.o glui_button.o glui_edittext.o glui_checkbox.o glui_node.o glui_radio.o glui_statictext.o glui_panel.o glui_separator.o glui_spinner.o glui_control.o glui_column.o glui_translation.o glui_rotation.o glui_mouse_iaction.o glui_listbox.o glui_rollout.o arcball.o algebra3.o quaternion.o
ar: glui_add_controls.o: Inappropriate file type or format

/usr/local/bin/ar -t glui_add_controls.o glui.o glui_bitmap_img_data.o glui_bitmaps.o glui_button.o glui_edittext.o glui_checkbox.o glui_node.o glui_radio.o glui_statictext.o glui_panel.o glui_separator.o glui_spinner.o glui_control.o glui_column.o glui_translation.o glui_rotation.o glui_mouse_iaction.o glui_listbox.o glui_rollout.o arcball.o algebra3.o quaternion.o
/usr/local/bin/ar: glui_add_controls.o: File format not recognized

This is pretty much shutting me down programming-wise on this mac, so any help would be greatly appreciated!
Thanks,
Sean

 

[jpyc7]

Hi,

I'm trying to use ar to link object files into a library, as so often is done when compiling libraries and installing them. I'm on a mac with osx, and it seems to always have some problem that I can never fix. Does anyone know how to fix it? examples:

/usr/bin/ar -t glui_add_controls.o glui.o glui_bitmap_img_data.o glui_bitmaps.o glui_button.o glui_edittext.o glui_checkbox.o glui_node.o glui_radio.o glui_statictext.o glui_panel.o glui_separator.o glui_spinner.o glui_control.o glui_column.o glui_translation.o glui_rotation.o glui_mouse_iaction.o glui_listbox.o glui_rollout.o arcball.o algebra3.o quaternion.o
ar: glui_add_controls.o: Inappropriate file type or format

/usr/local/bin/ar -t glui_add_controls.o glui.o glui_bitmap_img_data.o glui_bitmaps.o glui_button.o glui_edittext.o glui_checkbox.o glui_node.o glui_radio.o glui_statictext.o glui_panel.o glui_separator.o glui_spinner.o glui_control.o glui_column.o glui_translation.o glui_rotation.o glui_mouse_iaction.o glui_listbox.o glui_rollout.o arcball.o algebra3.o quaternion.o
/usr/local/bin/ar: glui_add_controls.o: File format not recognized

This is pretty much shutting me down programming-wise on this mac, so any help would be greatly appreciated!
Thanks,
Sean

Well, you aren't passing it the right flags to create an archive.
I'm not sure about using a dash, but on my Linux system I use:
ar cr libarchive.a foo.o gloo.o bloo.o
which will create/replace contents in libarchive.a

I suggest reading the man page.

 

[smcguffee]

Thanks, but that's not it in this case. I tried the various syntaxes, and on mac, the program seems to take either r or -r. I get different error messages based on whether their is a lib/libglui.a or not and depending on which ar I use, /usr/bin/ar or /usr/local/bin/ar. Does anyone know how to get a new ar for mac? Maybe mine is broken. Examples of error messages:

Error type 1:
ranlib: '-q': No such file
ranlib: lib/libglui.a: File format not recognized
/usr/bin/ar: internal ranlib command failed

Error type 2:
/usr/local/bin/ar: lib/libglui.a: Invalid operation

 

[autorelease]

The "file" command can identify the format of an object file or static library. Run it on a troublesome .a or .o file and make sure it's Mach-O and it has the right architecture.

 

[smcguffee]

Ok, so I checked the files with the "file" command. The object files that I am trying to combine into a library are just fine. I think the mac ar simply doesn't work. Does anyone have an ar program that does work on a mac?

 

[Michael Belisle]

I think the mac ar simply doesn't work.

When faced with the choice between A) you making a mistake somewhere and B) a fundamental command like ar being totally broken, you decide it must be B? C'mon. Of course it works. Apple didn't spend millions of dollars developing OS X, ship it with a broken ar, and you're the first to notice.

ar in /usr/local/bin is non-standard. Have you messed with your installation or installed something that's conflicting with the stock ar, perhaps also giving you bad output from your compiler?

 

[Michael Belisle]

First of all, ar -t lists the object files in a library. You're trying to list the object files in a bunch of object files. You have to specify a library. Try man ar, as previously suggested.

 

[Michael Belisle]

Like the man said, you need to run the command with the proper arguments, e.g.

ar -r library.a foo.o bar.o baz.o

I downloaded the libglui-2.36 source and the makefile step

ar -r lib/libglui.a glui_add_controls.o glui_string.o glui.o glui_bitmap_img_data.o glui_bitmaps.o glui_button.o glui_edittext.o glui_commandline.o glui_checkbox.o glui_node.o glui_radio.o glui_statictext.o glui_panel.o glui_separator.o glui_spinner.o glui_control.o glui_column.o glui_translation.o glui_rotation.o glui_mouse_iaction.o glui_listbox.o glui_rollout.o glui_window.o arcball.o algebra3.o quaternion.o viewmodel.o glui_treepanel.o glui_tree.o glui_textbox.o glui_scrollbar.o glui_list.o glui_filebrowser.o
ar: creating archive lib/libglui.a

completed without error.

 

[smcguffee]

Are you on a mac with osx?
here's what I get:

/usr/local/bin/ar -r lib/libglui.a archive.o archive64.o archures.o bfd.o bfdio.o bfdwin.o binary.o cache.o coffgen.o compress.o corefile.o cpu-i386.o cpu-powerpc.o cpu-rs6000.o dwarf2.o format.o hash.o ihex.o init.o libbfd.o linker.o mach-o.o merge.o opncls.o pef.o reloc.o section.o simple.o srec.o stab-syms.o stabs.o syms.o targets.o tekhex.o xsym.o
ar: lib/libglui.a: Invalid operation

This is the case with all situations where I need to make a library.
I have tried to install binutils from gnu, but they require the ar to work to compile their ar program. I have no idea what to do at this point.

or, if I use /usr/bin/ar:
/usr/bin/ar r lib/libglui.a archive.o archive64.o archures.o bfd.o bfdio.o bfdwin.o binary.o cache.o coffgen.o compress.o corefile.o cpu-i386.o cpu-powerpc.o cpu-rs6000.o dwarf2.o format.o hash.o ihex.o init.o libbfd.o linker.o mach-o.o merge.o opncls.o pef.o reloc.o section.o simple.o srec.o stab-syms.o stabs.o syms.o targets.o tekhex.o xsym.o
ar: creating archive lib/libglui.a
ranlib: '-q': No such file
ranlib: lib/libglui.a: File format not recognized
/usr/bin/ar: internal ranlib command failed


by the way:
file *\.oarchive.o: Mach-O 64-bit object x86_64archive64.o: Mach-O 64-bit object x86_64archures.o: Mach-O 64-bit object x86_64
bfd.o: Mach-O 64-bit object x86_64
bfdio.o: Mach-O 64-bit object x86_64
bfdwin.o: Mach-O 64-bit object x86_64
binary.o: Mach-O 64-bit object x86_64
cache.o: Mach-O 64-bit object x86_64
coffgen.o: Mach-O 64-bit object x86_64
compress.o: Mach-O 64-bit object x86_64
corefile.o: Mach-O 64-bit object x86_64
cpu-i386.o: Mach-O 64-bit object x86_64
cpu-powerpc.o: Mach-O 64-bit object x86_64
cpu-rs6000.o: Mach-O 64-bit object x86_64
dwarf2.o: Mach-O 64-bit object x86_64
format.o: Mach-O 64-bit object x86_64
hash.o: Mach-O 64-bit object x86_64
ihex.o: Mach-O 64-bit object x86_64
init.o: Mach-O 64-bit object x86_64
libbfd.o: Mach-O 64-bit object x86_64
linker.o: Mach-O 64-bit object x86_64
mach-o.o: Mach-O 64-bit object x86_64
merge.o: Mach-O 64-bit object x86_64
opncls.o: Mach-O 64-bit object x86_64
pef.o: Mach-O 64-bit object x86_64
reloc.o: Mach-O 64-bit object x86_64
section.o: Mach-O 64-bit object x86_64
simple.o: Mach-O 64-bit object x86_64
srec.o: Mach-O 64-bit object x86_64
stab-syms.o: Mach-O 64-bit object x86_64
stabs.o: Mach-O 64-bit object x86_64
syms.o: Mach-O 64-bit object x86_64
targets.o: Mach-O 64-bit object x86_64
tekhex.o: Mach-O 64-bit object x86_64
xsym.o: Mach-O 64-bit object x86_64

 

[Thomas Harte]

Are you on a mac with osx?
here's what I get:

/usr/local/bin/ar

As pointed out by Michael, ar shouldn't be in /usr/local/bin. If you install Apple's Xcode tools then it'll end up in /usr/bin. It seems you've done some sort of custom install or accumulated some other program that just happens to be called 'ar' from somewhere. If you're able to give details about that, people might be able to supply some more helpful advice.

 

[Sayer]

I never used 'ar' to make static libs from object .o files. I used libtool and lipo (to make universal binaries).

 

[smcguffee]

Thanks for the tips. These look good. One thing I have found is that /usr/bin/ar seems to work, but then I have trouble with ranlib, but I'm working on that. There seems to be some architecture issues, so I especially appreciate the new idea of exploring lipo. I hadn't heard of it before, but it looks like it has a lot of potential. I just got turned on to 'port' which is like yum for mac. When I try to use libraries from it, I have been getting errors regarding architecture issues, but at least it is installing things for me to work with. I'm not sure, but I'm guessing that architecture issues mean something regarding whether the code is 64-bit verse 32-bit, but could it have something to do with icc vs. gcc? I don't know much about architecture.

 

[smcguffee]

ok, now I'm getting a better description of some of my library issues. one of them happens to be that I need an x86_64 architecture library file, but I only have an i386 type file. I tried using lipo to change them, but I couldn't get the results I wanted. Here's what I tried that didn't work: Is there a better way to do it?
lipo -create -arch x86_64 bin/libjuce.a -output lib/libjuce.a
lipo: architecture specifed for fat input file: bin/libjuce.a (architectures can't be specifed for fat input files)

 

[Michael Belisle]

Can you explain more clearly what you're trying to do and how you got here?

0) What is your goal?
1) How did you compile the object files that you're trying to put in a library?
2) Where did the libraries (e.g. libjuce.a) come from that you're trying to operate on?
3) Did you install compilers other than the Xcode tools?

You can't "change" the architecture on a library. You can recompile the library for a different architecture, or extract a particular architecture from a fat library, but if you have an i386 library and you need a x86_64 one, the only way to get it is to compile an x86_64 library. If libjuce.a is a fat library and you're trying to extract the x86_64 code from it for some reason, you're doing it wrong.

 

[smcguffee]

Ok, well, I've been using scripts to compile software that come in tar.gz type files from the net, and I had no idea there were two types of architecture on one machine. What seems to be going on is that code coming out of icc is 64 bit and code coming from the Mac OSX operating system such as Carbon stuff is 32 bit. Is there a way for me to make the Carbon stuff 64 bit or do I have to use 32 bit code to be compatible? If so, will that have a cut in performance? Not that I will necessarily have a choice. If I do have to find a way to get everything in 32 bit to match, is there a way to make icc produce 32 bit code? To be more specific, say for example right now when I'm trying to compile JUCE. It's really impressing me as a GUI so far, and I suppose a 32 bit version that runs directly on my machine would still perform better than java. Anyway, I can compile everything of JUCE in 64 bit code except for the architecture-specific calls in Carbon in some of the most valuable parts of the code, say for example in a file browser. I'm looking through the header files for Carbon/Carbon.h, but I'm not sure if it will help. My current error is that "
juce_mac_FileChooser.cpp(94): error: identifier "SetWindowGroup" is undefined
SetWindowGroup (callbackParms->window,
"
I might be able to get it all to compile by defining functions, but then linking may be an issue if it rejects carbon libraries on architectural bias. We'll see. It looks like an easy way out would be if I could find a way to deliberately direct all compilations to be in 32 bit, but so far I don't know how to do that.

 

[Michael Belisle]

I have tried to install binutils from gnu, but they require the ar to work to compile their ar program. I have no idea what to do at this point.

Ah.

4) Why are you trying to install GNU binutils? I can't see why you'd need them.
5) Can you focus on just one piece of code you're trying to compile, instead of jumping back and forth and giving us all these different errors for all sorts of different things you're trying to compile?

 

[Michael Belisle]

Ok, well, I've been using scripts to compile software that come in tar.gz type files and I had no idea there were two types of architecture on one machine. What seems to be going on is that code coming out of icc is 64 bit and code coming from the Mac OSX operating system such as Carbon stuff is 32 bit. Is there a way for me to make the Carbon stuff 64 bit or do I have to use 32 bit code to be compatible? If so, will that have a cut in performance? Not that I will necessarily have a choice. If I do have to find a way to get everything in 32 bit to match, is there a way to make icc produce 32 bit code?

Mac OS X supports four architectures: ppc, ppc64, i386, and x86_64. And yes, not everything in Mac OS X is 64-bit, but i don't know if that's your problem. If you're trying to work with fat libraries, as previously mentioned, then ar is not the tool for the job.

There's probably a way to specify the architecture as a compiler option to icc.

 

[Michael Belisle]

To be more specific, say for example right now when I'm trying to compile JUCE. It's really impressing me as a GUI so far, and I suppose a 32 bit version that runs directly on my machine would still perform better than java. Anyway, I can compile everything of JUCE in 64 bit code except for the architecture-specific calls in Carbon in some of the most valuable parts of the code, say for example in a file browser.

I was able to compile libjuce.a in 32-bit fine in Xcode by hitting "build" after opening the juce/build/macosx/Juce.xcodeproj file.

I'm not familiar with the Intel C compiler, but if you don't need 64-bit code and you want to use JUCE, then it's probably easier to figure out how to get icc to output 32-bit code then to successfully compile JUCE in 64-bit.

But if you do want 64-bit JUCE, you'd probably be better off getting help from the JUCE folks.

 

[Michael Belisle]

I tried downloading the latest SVN version of JUCE (729) and got the following error after trying to switch the architecture to 64-bit:

CoreServices.h:20:6: error: #error 64-bit not supported

Not much you can do about that, but maybe JUCE can help you since at least one person has a built a 64-bit version of it