On 05.11.2012 18:00, Jonas Maebe wrote:
On 05 Nov 2012, at 14:40, Vincent Snijders wrote:
I found out the cause of *my* problem. The ld provided by Ubuntu
(version 2.22) was in /usr/bin. There was also an older version 2.21
in /usr/local/bin which was actually chosen. Fixing that solved my
First I added -Fl/usr/lib/i386-linux-gnu to the fpc.cfg. But for building fpc
that doesn't help, because of the -n parameter added by make all. So I did
make all OPT=-Fl/usr/lib/i386-linux-gnu. That works for trunk, but not for
fixes_2_6 because OPT is not passed when building fpmake.pp in
On 05/11/12 13:16, Vincent Snijders wrote:
2012/10/27 Florian Klämpfl flor...@freepascal.org
mailto:flor...@freepascal.org
I added already several weeks ago the new multi-arch pathes as
additional default search pathes to armhf-linux but since people didn't
like this
On 05 Nov 2012, at 14:40, Vincent Snijders wrote:
I found out the cause of *my* problem. The ld provided by Ubuntu
(version 2.22) was in /usr/bin. There was also an older version 2.21
in /usr/local/bin which was actually chosen. Fixing that solved my
problem.
Yes, the default system linker's
Vincent Snijders wrote:
First I added -Fl/usr/lib/i386-linux-gnu to the fpc.cfg. But for building fpc that
doesn't help, because of the -n parameter added by make all. So I did make all
OPT=-Fl/usr/lib/i386-linux-gnu. That works for trunk, but not for fixes_2_6
because OPT is not passed when
In our previous episode, Mark Morgan Lloyd said:
... and got bogged down in gdbint issues.
Trust me, you are not the only one :-)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Am 26.10.2012 23:28, schrieb Mark Morgan Lloyd:
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
On Oct 27, 2012 9:18 AM, Florian Klämpfl flor...@freepascal.org wrote:
I added already several weeks ago the new multi-arch pathes as
additional default search pathes to armhf-linux but since people didn't
like this change I didn't add it for the other architectures.
Ah, this is why I didn't
Florian Klämpfl wrote:
Am 26.10.2012 23:28, schrieb Mark Morgan Lloyd:
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 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 ./Makefile.fpc
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 directory
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 module,
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
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 had
a
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
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 to the
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 same direction as
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
19 matches
Mail list logo
