still unhosing my compiler
So my compiler is still hosed. I've written pretty detailed info to this list already about it, and got some helpful suggestions (thanks!). However, my compiler is still hosed. I can't link even the most trivial program--I get this sort of smack: /tmp/cca278371.o: In function `main': /tmp/cca278371.o(.text+0xe): undefined reference to `_stdprintf' This is *not* an error related to this program (or makefile, command line for gcc, etc). This is a hosed compiler and/or linker problem. Reinstalling binutils, gcc, libc, libc-dev, libbfd, and just about everything else under the sun does not seem to fix the problem. However, I would like much to get my compiler back on-line. If I don't get any other suggestions, I guess I'll have to reinstall from _scratch_ But there has to be a better way, right? Is there a way for me to force dpkg into reinstalling _everything_? Debian GNU/Linux 1.3 Linux 2.0.27 #1 Thu May 22 00:05:30 CDT 1997 i686 unknown thanks --sf -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: unhosing my compiler
>On Fri, 6 Jun 1997, stephen farrell wrote: >> >> I wrote: >> > >> >Normally there is a .so link, a .so.X link and a .so.X.YY dynamic library. >> >The linker will sometimes not follow a symbolic link more than one link, >> >so, if the .so link is to .so.X with .so.X linked to the actual library, >> >the linker will fail to find the library. Change the .so link to point >> >to the acutal .so.X.YY library and the compilation should get much better. >> >> For which .so? >> >> Here's libc.so.5: >> >> libc.so.5 -> libc.so.5.4.23* >> >I assume that these are in /lib. There should also be a link from >/usr/lib/libc.so back to /lib/libc.so.5.4.23. yep. >You should probably also check the like in /usr/lib/libm.so and make sure >it points to the correct file. this looks normal, besides the trivial little programming i'm trying to compile (it's the one called gccvers.c and it's part of the perl configuration process) doesn't use libm, or curses.. >Other libs in /usr/lib like ncurses and >others will only be necessary if their features are included in the >program. >I'm not clear on just how you got into this situation. Usually No, it's not. It's likely to me that it had something to do with upgrading to debian 1.3. Also, I should mention that I did a little bit of monkeying around with libpthread.so. Whenever I ran ldconfig, it whined that libpthread.so didn't exist. For some reason I had a dangling link and I deleted it. I also tried at that point to reinstall libpthread. This didn't go particularly well b/c (a) dselect thought I still had libpthread installed on my maching and went ape-shit with dependencies when I tried to remove it (b) dselect kept on trying to get me to install libc6. I think I thwarted it's efforts, but in the process it uninstalled a "bunch of stuff" which I'm still trying to get reinstalled correctly like kernel headers and such. (it keeps looking on debian ftp server for something like kernel-headers_2.0.30_2.0.30-x.deb, which appears to be a mistake to both myself and it, b/c it can never find this). So yes, I screwed around quite a bit. But I'm *sorry* and I'm done =). I'd really just like at this point to do a make world or equivalent and restore my system to ok state. >re-installing the various development libraries tends to fix these kind of >linker problems. That's what I'd hoped. > >BTW, did you try upgrading binutils? Yep. Just did it now (including reinstall of gcc again) and still no go. Nothing will compile. --sf -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: unhosing my compiler
{
*(.ctors)
}
.dtors :
{
*(.dtors)
}
.got : { *(.got.plt) *(.got) }
.dynamic : { *(.dynamic) }
/* We want the small data sections together, so single-instruction offsets
can access them all, and initialized data all before uninitialized, so
we can shorten the on-disk segment size. */
.sdata : { *(.sdata) }
_edata = .;
PROVIDE (edata = .);
__bss_start = .;
.sbss : { *(.sbss) *(.scommon) }
.bss :
{
*(.dynbss)
*(.bss)
*(COMMON)
}
_end = . ;
PROVIDE (end = .);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
/* These must appear regardless of . */
}
==
attempt to open /usr/lib/crt1.o succeeded
/usr/lib/crt1.o
attempt to open /usr/lib/crti.o succeeded
/usr/lib/crti.o
attempt to open /usr/lib/crtbegin.o succeeded
/usr/lib/crtbegin.o
attempt to open /tmp/cca069521.o succeeded
/tmp/cca069521.o
attempt to open /usr/lib/gcc-lib/i486-linux/2.7.2.1/libgcc.so failed
attempt to open /usr/lib/gcc-lib/i486-linux/2.7.2.1/libgcc.a succeeded
attempt to open /usr/lib/gcc-lib/i486-linux/2.7.2.1/libc.so failed
attempt to open /usr/lib/gcc-lib/i486-linux/2.7.2.1/libc.a failed
attempt to open /lib/libc.so failed
attempt to open /lib/libc.a failed
attempt to open /usr/lib/libc.so succeeded
-lc (/usr/lib/libc.so)
attempt to open /usr/lib/gcc-lib/i486-linux/2.7.2.1/libgcc.so failed
attempt to open /usr/lib/gcc-lib/i486-linux/2.7.2.1/libgcc.a succeeded
attempt to open /usr/lib/crtend.o succeeded
/usr/lib/crtend.o
attempt to open /usr/lib/crtn.o succeeded
/usr/lib/crtn.o
/tmp/cca069521.o: In function `main':
/tmp/cca069521.o(.text+0xe): undefined reference to `_stdprintf'
>- does compiling work when you add '--static'?
no.
>
>libc.a is only used when compiling "-static"; otherwise the dynamic library
>/lib/libc.so* is used)
This makes sense.
>
>> Thoughts on unhosing my compiler very welcome...
>
>It looks like a linker problem; you might try to install a different version
>of "binutils" (don't forget the matching "libbfd*" package).
I've replaced ld.so, binutils, and libc with the original debian
packages to no avail.
>
>Ray
thnks
--sf
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: unhosing my compiler
On Fri, 6 Jun 1997, J.H.M.Dassen wrote:
> On Jun 5, stephen farrell wrote
> > Oh geez... what have I done? I can't seem to figure out which library
> > is missing, but if I try to compile, e.g.:
>
> > /tmp/cca027141.o: In function `main':
> > /tmp/cca027141.o(.text+0xe): undefined reference to `_stdprintf'
>
> OK. Linker errors. Please provide us with the following information:
> - the version of binutils (binutils contains the linker) ("dpkg -l binutils").
> - the output of trying to compile your program with "-Wl,--verbose"
> - does compiling work when you add '--static'?
>
> > And you can imagine it gets worse for something bigger! I figured I'd
> > hosed libc.a or similar?
>
> libc.a is only used when compiling "-static"; otherwise the dynamic library
> /lib/libc.so* is used)
>
Ray is correct here and I think, possibly closing in on the problem. I
have seen this problem when the .so links aren't built right.
Normally there is a .so link, a .so.X link and a .so.X.YY dynamic library.
The linker will sometimes not follow a symbolic link more than one link,
so, if the .so link is to .so.X with .so.X linked to the actual library,
the linker will fail to find the library. Change the .so link to point
to the acutal .so.X.YY library and the compilation should get much better.
Note: This is only likely if updating binutils (as suggested by Ray)
doesn't fix the problem. You should try that idea first.
Luck,
Dwarf
--
_-_-_-_-_-_- _-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: unhosing my compiler
On Jun 5, stephen farrell wrote
> Oh geez... what have I done? I can't seem to figure out which library
> is missing, but if I try to compile, e.g.:
> /tmp/cca027141.o: In function `main':
> /tmp/cca027141.o(.text+0xe): undefined reference to `_stdprintf'
OK. Linker errors. Please provide us with the following information:
- the version of binutils (binutils contains the linker) ("dpkg -l binutils").
- the output of trying to compile your program with "-Wl,--verbose"
- does compiling work when you add '--static'?
> And you can imagine it gets worse for something bigger! I figured I'd
> hosed libc.a or similar?
libc.a is only used when compiling "-static"; otherwise the dynamic library
/lib/libc.so* is used)
> Thoughts on unhosing my compiler very welcome...
It looks like a linker problem; you might try to install a different version
of "binutils" (don't forget the matching "libbfd*" package).
Ray
--
ART A friend of mine in Tulsa, Okla., when I was about eleven years old.
I'd be interested to hear from him. There are so many pseudos around taking
his name in vain.
- The Hipcrime Vocab by Chad C. Mulligan
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
unhosing my compiler
Oh geez... what have I done? I can't seem to figure out which library
is missing, but if I try to compile, e.g.:
#include
int main() {
#ifdef __GNUC__
#ifdef __VERSION__
printf("%s\n", __VERSION__);
#else
printf("%s\n", "1");
#endif
#endif
exit(0);
}
I'll get:
/tmp/cca027141.o: In function `main':
/tmp/cca027141.o(.text+0xe): undefined reference to `_stdprintf'
And you can imagine it gets worse for something bigger! I figured I'd
hosed libc.a or similar? But it seems to be intact. I've reinstalled
the gcc from frozen to no avail I've also monkeyed with dselect
for an hour or so trying to figure out the glitch
(uninstalling/installing gcc, libc5-dev, libpthreads), but no luck.
Thoughts on unhosing my compiler very welcome...
This is a 1.2.x upgraded to frozen system. gcc 2.7.2.1-8. libc5.4.23.
Thanks
--sf
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
