[gentoo-amd64] Re: Problem emergin cdk

[Duncan]

Kirby Walborn posted <44043BB1.7020703@×××××××××××××.com>, excerpted
below,  on Tue, 28 Feb 2006 05:01:53 -0700:

> Lorenzo Milesi wrote:
>> It's nearly 1 week I'm trying to upgrade CDK but the compile fails.
>>
>> x86_64-pc-linux-gnu-g++ -shared -nostdlib
>> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/crti.o
>> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/crtbeginS.o  .libs/dscale.o
>> .libs/fscale.o .libs/fslider.o .libs/scale.o .libs/slider.o
>> .libs/uscale.o .libs/uslider.o .libs/alphalist.o .libs/binding.o
>> .libs/button.o .libs/buttonbox.o .libs/calendar.o .libs/cdk.o
>> .libs/cdk_compat.o .libs/cdk_objs.o .libs/cdk_params.o .libs/cdkscreen.o
>> .libs/debug.o .libs/dialog.o .libs/draw.o .libs/entry.o .libs/fselect.o
>> .libs/get_index.o .libs/get_string.o .libs/graph.o .libs/histogram.o
>> .libs/itemlist.o .libs/label.o .libs/marquee.o .libs/matrix.o
>> .libs/mentry.o .libs/menu.o .libs/popup_dialog.o .libs/popup_label.o
>> .libs/position.o .libs/radio.o .libs/scroll.o .libs/selection.o
>> .libs/swindow.o .libs/select_file.o .libs/template.o .libs/traverse.o
>> .libs/version.o .libs/view_file.o .libs/view_info.o .libs/viewer.o
>> -L/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4
>> -L/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/lib
>> -L/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64
>> -L/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../.. -L/lib/../lib64
>> -L/usr/lib/../lib64 -lstdc++ -lm -lc -lgcc_s
>> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/crtendS.o
>> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/crtn.o
>> -Wl,-soname -Wl,libcdk.so.1 -o .libs/libcdk.so.1.2.1
>> x86_64-pc-linux-gnu-g++:
>> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/crti.o: No such
>> file or directory
>> x86_64-pc-linux-gnu-g++:
>> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/crtbeginS.o: No such file or
>> directory
>> x86_64-pc-linux-gnu-g++:
>> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/crtendS.o: No such file or
>> directory
>> x86_64-pc-linux-gnu-g++:
>> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../lib64/crtn.o: No such
>> file or directory
>> make: *** [libcdk.la] Error 1
>>
>> !!! ERROR: dev-libs/cdk-5.0.20060220 failed. Call stack:
>>   ebuild.sh, line 1928:   Called dyn_compile ebuild.sh, line 966:
>>   Called src_compile
>>
>> !!! (no error message)
>> !!! If you need support, post the topmost build error, and the call
>> stack if relevant.
>>
>>
>> It fails because it cannot find crti.o and crtn.o, but I have them in
>> /usr/lib64!
>>
> I had the same problem and fixed it by doing this:
>
> emerge --oneshot libtool
>
> After doing the above cdk emerged fine.  I found the answer in the forums
> but not the reason why this fixes it.

It's looking for libraries, aka *.so (so=shared object, the MSWormOS
parallel is *.dll, dynamic link library).  That's what would normally be
found in lib(64) dirs and what is normally linked against.

libtool is, I /believe/, the "library tool" (real smart there, eh? <g>)
that creates all those *.la (not sure what that stands for but linker
advice fits) text files, that in turn give gcc some help figuring out
libraries.  I've never happened to come across the details and haven't
gotten around to looking them up either, but I HAVE seen a Gentoo dev
remark that libtool was a solution to one problem that ended up creating
another -- PARTICULARLY for a frequently updated from-source distro like
Gentoo.

Anyway, piecing together the various bits of information, apparently a bad
libtool version screwed up and missed the "s" in .so, so things weren't
fitting together correctly.

Complicating matters is that *.o files are binary object files -- pieces
of binary executables and libraries that gcc creates from C and C++ source
files, as a mid-stage, before combining them into the various libraries
and executables they form.

So... *.o object files should exist in the portage working dirs, for a
short time until the package is fully created and merged, after which
portage usually cleans them up; they should **NOT** exist in the library
dirs.  Correspondingly, *.so files will be the most common file in the
library dirs, and would be what gcc was wanting.

How you got *.o files in your library dirs, I don't know (unless you put
them there manually trying to fix the error).  Perhaps the defective
libtool had a part in that as well.  In any case, they didn't belong
there, and it's no surprise gcc was erring out even with them there,
because that's  not what it wanted or expected, and was only what it was
asking for because that's what the defective libtool told it it needed.

To anybody the least bit familiar with compilers, libraries, and object
files, an error such as that is a *HUGE* *FLASHING* *RED* *FLAG*!!! 
Something is *TERRIBLY* wrong.  I don't know that I would have traced it
to libtool, altho I might, as one of the first things I would have done
would be to go looking in the *.la file for that library to see if it had
*.o instead of *.so for the library, as I suspect it was listed wrong
there and  I know that libtool handles those, but in any case, I would
have been VERY careful right about then trying to compile anything else,
because if gcc gets screwed up bad enough to be looking for *.o files
instead of *.so files, it's potentially screwed up bad enough to trash an
entire system, if you don't tread carefully.

Anyway, I learned something too, in reading this.  If I ever have
something similar happen, I'll immediately check my libtool.  I might have
gotten there before, but now  I know to check it first.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list