Running Mac OS X 10.6.2 (Snow Leopard) ...
When running ranlib, I sometimes get error msgs saying that a particular
library entry has no symbols. This most recently happened with the FLTK
libraries, e.g.:
$ ranlib libfltk.a
ranlib: file: libfltk.a(Fl_x.o) has no symbols
ranlib: file: libfltk.a(fl_overlay_visual.o) has no symbols
ranlib: file: libfltk.a(fl_call_main.o) has no symbols
ranlib: file: libfltk.a(scandir.o) has no symbols
ranlib: file: libfltk.a(keysym2Ucs.o) has no symbols
ranlib: file: libfltk.a(utf8Input.o) has no symbols
ranlib: file: libfltk.a(utf8Utils.o) has no symbols
ranlib: file: libfltk.a(utf8Wrap.o) has no symbols
I did not have this problem with Mac OS X 10.5 (Leopard).
Has anybody run into this problem? If so, what's the fix?
Many thanks.
--
Art Werschulz (agw STRUDEL comcast.net)
... insert clever quote here ...
>Running Mac OS X 10.6.2 (Snow Leopard) ...
>When running ranlib, I sometimes get error msgs saying that a particular
>library entry has no symbols. This most recently happened with the FLTK
>libraries, e.g.:
Was the library stripped as part of it being built (cf man strip)?
--
Chris.
Chris McDonald <ch...@csse.uwa.edu.au> writes:
Not as far as I can tell.
I'm also getting the following msgs when trying to use these libraries:
ld: warning: in ../GUI/libbookgui.a, file is not of required architecture
ld: warning: in /usr/local/lib/libjpeg.dylib, file is not of required architecture
Again, this problem did not occur with Mac OS 10.5.
Suggestions? Thanks.
GreyCloud <mi...@cumulus.com> writes:
>>>> Running Mac OS X 10.6.2 (Snow Leopard) ...
>>>> When running ranlib, I sometimes get error msgs saying that a particular
>>>> library entry has no symbols. This most recently happened with the FLTK
>>>> libraries, e.g.:
>>> Was the library stripped as part of it being built (cf man strip)?
>>
>> Not as far as I can tell.
>>
>> I'm also getting the following msgs when trying to use these libraries:
>>
>> ld: warning: in ../GUI/libbookgui.a, file is not of required architecture
>> ld: warning: in /usr/local/lib/libjpeg.dylib, file is not of required architecture
>>
>> Again, this problem did not occur with Mac OS 10.5.
>>
>> Suggestions? Thanks.
>>
> Hmmm... do a file /usr/local/lib/libjpeg.dylib and see how many archs
> it was made for. Same for ../GUI/libbookgui.a
> At least it is a start.
agw@home:~$ file /usr/local/lib/libjpeg.dylib
/usr/local/lib/libjpeg.dylib: Mach-O 64-bit dynamically linked shared library x86_64
agw@home:~$ file /usr/local/lib/libbookgui.a
/usr/local/lib/libbookgui.a: current ar archive random library
Well, the first file only has one arch and the latest snowleopard files
have x86_64 and i386 archs in the dylibs. This is done for those that
are using Xcode and want to deliver a multiple arch package.
Strange that there weren't the usual three others of the G4, G5 and one
older one.
The libbookgui.a is a static library. The fact that the linker checked
the file associated with the current arch and what the library was
compiled to shows that they don't match.
Also, my system doesn't show these libs. What was the source of these
libs? It may help a lot in determing what is going on.
GreyCloud <mi...@cumulus.com> writes:
>> agw@home:~$ file /usr/local/lib/libjpeg.dylib
>> /usr/local/lib/libjpeg.dylib: Mach-O 64-bit dynamically linked
>> shared library x86_64
>> agw@home:~$ file /usr/local/lib/libbookgui.a
>> /usr/local/lib/libbookgui.a: current ar archive random library
>>
>
> Well, the first file only has one arch and the latest snowleopard
> files have x86_64 and i386 archs in the dylibs. This is done for
> those that are using Xcode and want to deliver a multiple arch
> package.
> Strange that there weren't the usual three others of the G4, G5 and
> one older one.
This may be leftover from Leopard.
> The libbookgui.a is a static library. The fact that the linker
> checked the file associated with the current arch and what the library
> was compiled to shows that they don't match.
It was compiled from source, as follows:
g++ -I -Wall -time -O3 -DNDEBUG -c -o GUI.o GUI.cc
g++ -I -Wall -time -O3 -DNDEBUG -c -o Graph.o Graph.cc
g++ -I -Wall -time -O3 -DNDEBUG -c -o Simple_window.o Simple_window.cc
g++ -I -Wall -time -O3 -DNDEBUG -c -o Window.o Window.cc
ar rcs libbookgui.a GUI.o Graph.o Simple_window.o Window.o
The source is Bjarne Stroustrup's simple GUI, associated with his new
textbook.
> Also, my system doesn't show these libs. What was the source of these
> libs? It may help a lot in determing what is going on.
Note that when I ran
ranlib /usr/local/lib/lib*.a | grep "no symbols"
gave the following results:
ranlib: file: /usr/local/lib/libfltk.a(Fl_x.o) has no symbols
ranlib: file: /usr/local/lib/libfltk.a(fl_overlay_visual.o) has no symbols
ranlib: file: /usr/local/lib/libfltk.a(fl_call_main.o) has no symbols
ranlib: file: /usr/local/lib/libfltk.a(scandir.o) has no symbols
ranlib: file: /usr/local/lib/libfltk.a(keysym2Ucs.o) has no symbols
ranlib: file: /usr/local/lib/libfltk.a(utf8Input.o) has no symbols
ranlib: file: /usr/local/lib/libfltk.a(utf8Utils.o) has no symbols
ranlib: file: /usr/local/lib/libfltk.a(utf8Wrap.o) has no symbols
FLTK was compiled from source, built via the usual
make configure
make
make install
Hey, thnx for the heads up. What's the books title?
>> Also, my system doesn't show these libs. What was the source of these
>> libs? It may help a lot in determing what is going on.
>
> Note that when I ran
> ranlib /usr/local/lib/lib*.a | grep "no symbols"
> gave the following results:
> ranlib: file: /usr/local/lib/libfltk.a(Fl_x.o) has no symbols
> ranlib: file: /usr/local/lib/libfltk.a(fl_overlay_visual.o) has no symbols
> ranlib: file: /usr/local/lib/libfltk.a(fl_call_main.o) has no symbols
> ranlib: file: /usr/local/lib/libfltk.a(scandir.o) has no symbols
> ranlib: file: /usr/local/lib/libfltk.a(keysym2Ucs.o) has no symbols
> ranlib: file: /usr/local/lib/libfltk.a(utf8Input.o) has no symbols
> ranlib: file: /usr/local/lib/libfltk.a(utf8Utils.o) has no symbols
> ranlib: file: /usr/local/lib/libfltk.a(utf8Wrap.o) has no symbols
> FLTK was compiled from source, built via the usual
> make configure
> make
> make install
>
Instead of using ranlib, use nm to list symbols in a library. Do a man nm.
Also use libtool as it is supposed to replace ranlib and ar... at least
that is what it says when doing man ranlib.
Then if no symbols are there, then the file was stripped.
You may have to look into that configure file to look for any commands
that will strip this library.
GreyCloud <mi...@cumulus.com> writes:
>> The source is Bjarne Stroustrup's simple GUI, associated with his new
>> textbook.
>
> Hey, thnx for the heads up. What's the books title?
>
Programming: Principles and Practice Using C++
The book's website is
http://www.stroustrup.com/Programming
I checked it out and it looks like an excellent book.
Hopefully, they also supplied the library code.
GreyCloud <mi...@cumulus.com> writes:
>> Programming: Principles and Practice Using C++
>> The book's website is http://www.stroustrup.com/Programming
>
> I checked it out and it looks like an excellent book.
> Hopefully, they also supplied the library code.
The library code is on the website, along with all the other code
examples from the text.
Were I of any help to you?
It turns out the fix was to downgrade to FLTK 1.1.10. Everything was
fine after that.
That is rather strange.
It could be that there were various versions of FLTK for different
platforms and I'm presuming that that one would've worked under a MS
windows.