[gentoo-amd64] Problem emergin cdk

[gentoo-amd64] Problem emergin cdk

[Lorenzo Milesi]

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!

Anyone experienced the same?

thanks
maxxer

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Problem emergin cdk

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

On Tuesday 28 February 2006 09:37, Lorenzo Milesi wrote:
> It's nearly 1 week I'm trying to upgrade CDK but the compile fails.

It seems that your gcc is hosed. Those files it complains about not 
finding. Those are internal files to gcc. You say you do have the files. 
Are they readable? Does anything else merge?

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-amd64] Problem emergin cdk

[Lorenzo Milesi]

> It seems that your gcc is hosed. Those files it complains about not
> finding. Those are internal files to gcc. You say you do have the files.
> Are they readable? Does anything else merge?

Yes, I can merge everything but cdk.
The files are located in /usr/lib64, attr -rw-r--r-- owned by root:root.

Shoud I recompile gcc?

Thanks
maxxer

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Problem emergin cdk

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

On Tuesday 28 February 2006 11:22, Lorenzo Milesi wrote:
> > It seems that your gcc is hosed. Those files it complains about not
> > finding. Those are internal files to gcc. You say you do have the
> > files. Are they readable? Does anything else merge?
>
> Yes, I can merge everything but cdk.
> The files are located in /usr/lib64, attr -rw-r--r-- owned by
> root:root.
>
> Shoud I recompile gcc?

You could try. It could also be that cdk just has a sucky link system.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-amd64] Problem emergin cdk

[Kirby Walborn]

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.

-- 

Kirby
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Problem emergin cdk

[Lorenzo Milesi]

> I had the same problem and fixed it by doing this:
> emerge --oneshot libtool

Thanks, it worked fine!

>  I found the answer in the
> forums but not the reason why this fixes it.

Shame on me for not looking there first :(

thanks again
maxxer

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Problem emergin cdk

[Duncan]

Kirby Walborn posted <44043BB1.7020703@walborncattle.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@gentoo.org mailing list

Re: [gentoo-amd64] Problem emergin cdk

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

On Tuesday 28 February 2006 13:01, Kirby Walborn wrote:
>
> 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.

Basically because libtool is often broken. Sometimes more than others. It 
does however always cause pain. And more than it is supposed to fix.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-amd64] Re: Problem emergin cdk

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

On Tuesday 28 February 2006 14:46, Duncan wrote:
> Kirby Walborn posted <44043BB1.7020703@walborncattle.com>, excerpted
>
> 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.

It actually does not let gcc figure out anything, but people use libtool 
to use gcc. Libtool then "fixes up" the call to gcc. In many cases 
deleting the .la files just works.

> 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.

These particular files are the default pieces of code that gcc in 
executable linking mode automatically adds to your executables (not your 
shared libraries). They take care that your "C" system behaves as you 
expect it to. They do things such as setting up the system in such a way 
that main gets called correctly, libraries are initialised, etc. As this 
code is common for all C files, gcc just links in these files instead of 
generating them all the time.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

[gentoo-amd64] Re: Re: Problem emergin cdk

[Duncan]

Paul de Vrieze posted <200602281553.53803.pauldv@gentoo.org>, excerpted
below,  on Tue, 28 Feb 2006 15:53:53 +0100:

> These particular files are the default pieces of code that gcc in
> executable linking mode automatically adds to your executables (not your
> shared libraries). They take care that your "C" system behaves as you
> expect it to. They do things such as setting up the system in such a way
> that main gets called correctly, libraries are initialised, etc. As this
> code is common for all C files, gcc just links in these files instead of
> generating them all the time.

Indeed.  I was wrong.  Seems I have those particular *.o files in lib64 as
well.  Learned something new 2day!  =8^)

-- 
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@gentoo.org mailing list