Over the last few days I've brought my first Debian "Wheezy" (currently
AKA "testing") system up and find I can no longer compile gdbint. This
prevents build completing on both 2.6.0 and trunk, even with NOGDB=1,
fiddling with ./Makefile.fpc and ./packages/Makefile.fpc to remove ide
and gdbint
On Fri, October 26, 2012 12:29, Mark Morgan Lloyd wrote:
> Over the last few days I've brought my first Debian "Wheezy" (currently
> AKA "testing") system up and find I can no longer compile gdbint. This
> prevents build completing on both 2.6.0 and trunk, even with NOGDB=1,
> fiddling with ./Makef
Am 26.10.2012 12:29, schrieb Mark Morgan Lloyd:
> (.text+0x68): undefined reference to `_fini'
> gdbver.pp(95,33) Error: Error while linking
> gdbver.pp(95,33) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
> make[4]: *** [gdbver] Error 1
> make[4]: Leaving direc
Florian Klämpfl wrote:
Am 26.10.2012 12:29, schrieb Mark Morgan Lloyd:
(.text+0x68): undefined reference to `_fini'
gdbver.pp(95,33) Error: Error while linking
gdbver.pp(95,33) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
make[4]: *** [gdbver] Error 1
make[4]:
Hi,
On Fri, 2012-10-26 at 17:13 +, Mark Morgan Lloyd wrote:
> Florian Klämpfl wrote:
> > Am 26.10.2012 12:29, schrieb Mark Morgan Lloyd:
> >> (.text+0x68): undefined reference to `_fini'
> >> gdbver.pp(95,33) Error: Error while linking
> >> gdbver.pp(95,33) Fatal: There were 1 errors compiling
Hello,
I believe Tomas is right saying that there are some symbols missing.
These funcions appear to be part of gcc's initialization/finalization
equivalent for shared objects (a quick search told me this). I once had
a similar issue with a symbol called `__dso_handle`, the fix for it was
to decla
Ewald wrote:
Hello,
I believe Tomas is right saying that there are some symbols missing.
These funcions appear to be part of gcc's initialization/finalization
equivalent for shared objects (a quick search told me this). I once had
a similar issue with a symbol called `__dso_handle`, the fix for
On 26 Oct 12, at 19:46, Mark Morgan Lloyd wrote:
> Ewald wrote:
> > Hello,
> >
> > I believe Tomas is right saying that there are some symbols missing.
> > These funcions appear to be part of gcc's initialization/finalization
> > equivalent for shared objects (a quick search told me this). I once
Thomas Schatzl wrote:
[On Debian Wheezy/testing]
The linker cannot find crt*.o files.
Try adding -Fl/usr/lib/sparc-linux-gnu to compilation options (OPT
param).
Thanks Thomas, that fixes it (I wish I hadn't spent quite so long
agonising over what I'd done wrong before asking). I find I also
Hi,
On Fri, 2012-10-26 at 22:35 +0200, Tomas Hajny wrote:
> On 26 Oct 12, at 19:46, Mark Morgan Lloyd wrote:
> > I'm trying Thomas's suggestion first, pending Florian's comments.
> .
> .
>
> I'd say that Thomas' suggestion points to the same direction as
> Florian. Your output sent in response
Am 26.10.2012 22:51, schrieb Thomas Schatzl:
> Hi,
>
> On Fri, 2012-10-26 at 22:35 +0200, Tomas Hajny wrote:
>> On 26 Oct 12, at 19:46, Mark Morgan Lloyd wrote:
>>> I'm trying Thomas's suggestion first, pending Florian's comments.
>> .
>> .
>>
>> I'd say that Thomas' suggestion points to the sam
Thomas Schatzl wrote:
Florian's suggestion is correct: debian is changing some paths beginning
with debian wheezy to improve multi-arch support.
While on sparc this may not matter and maybe not needed, it's probably
done on all platforms to reduce maintenance.
I.e. libc startup files and such
12 matches
Mail list logo
