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 allows the build to complete.

If gdbint is only used by the ide, shouldn't it be excluded if NOGDB is defined or if ide is removed at the top level?

I'm reluctant to bug-report the build failure since at present I'm testing on SPARC/Linux, and the build failure (as distinct from the dependency) could be platform-specific. For the record the failure point is as below with 2.6.0:

..
make -C gdbint smart
make[3]: Entering directory
`/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/packages/gdbint' make all LINKSMART=1 CREATESMART=1
make[4]: Entering directory
`/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/packages/gdbint' /bin/mkdir -p units/sparc-linux
/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/compiler/ppcsparc -XX -CX -Ur -Xs -O2 -n
-Fu/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux -Fl/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/libgdb/linux/sparc -Fo/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/libgdb/linux/sparc -Fi/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/libgdb/linux/sparc -Fisrc -FE. -FUunits/sparc-linux -Fl/usr/lib/gcc/sparc-linux-gnu/4.6 -Flinclude -Fl/etc/ld.so.conf.d/*.conf -O- -gl -vt -dsparc -dRELEASE src/gdbver.pp Using assembler: /usr/bin/as
/usr/bin/ld: warning: ./link.res contains output sections; did you forget -T?
/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux/cprt0.o: In function `_start':
(.text+0x58): undefined reference to `_init'
/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux/cprt0.o: In function `_start':
(.text+0x5c): undefined reference to `_fini'
/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux/cprt0.o: In function `_start':
(.text+0x64): undefined reference to `_init'
/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/rtl/units/sparc-linux/cprt0.o: In function `_start':
(.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
`/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/packages/gdbint' make[3]: *** [fpc_smart] Error 2
make[2]: *** [gdbint_smart] Error 2
make[3]: Leaving directory
`/usr/local/src/fpc/fpcbuild-2.6.0/fpcsrc/packages/gdbint'

There is no error on older Debian systems. I believe that I've got all prerequisites installed, noting that a build without ide and gdbint is OK.

gdbint is an import library package (similarly to packages like gtk2, httpd22, libgd, libpng, etc.). As it stands, it may be used not only by the IDE but possibly also by something created on the user side.

If I understand the error message correctly, the error message is related to cprt0.o not finding symbols expected there. These errors would probably appear when trying to compile any program using libc - if it is not gdbver, it would happen with something else, e.g. any program using cthreads or cwstring. From this point of view it seems to be completely unrelated to libgdb and having debugging support in the FP IDE or not.

Tomas

It is probably the problem that debian moved .o files to be prepared for multiarch support. Please compile a simple hello world c program with gcc --verbose ... and post the output.

0 1> gcc --verbose test.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/sparc-linux-gnu/4.6/lto-wrapper Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-11' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --with-long-double-128 --enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-11)
COLLECT_GCC_OPTIONS='-v' '-mcpu=ultrasparc'
/usr/lib/gcc/sparc-linux-gnu/4.6/cc1 -quiet -v -imultilib . -imultiarch sparc-linux-gnu -D__sparc_v9__ test.c -quiet -dumpbase test.c -mcpu=ultrasparc -auxbase test -version -o /tmp/ccSBAdgX.s GNU C (Debian 4.6.3-11) version 4.6.3 (sparc-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/local/include/sparc-linux-gnu" ignoring nonexistent directory
"/usr/lib/gcc/sparc-linux-gnu/4.6/../../../../sparc-linux-gnu/include" #include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/sparc-linux-gnu/4.6/include
/usr/local/include
/usr/lib/gcc/sparc-linux-gnu/4.6/include-fixed
/usr/include/sparc-linux-gnu
/usr/include
End of search list.
GNU C (Debian 4.6.3-11) version 4.6.3 (sparc-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 74f975d3998f132de369d57192c84870 test.c: In function ‘main’:
test.c:3:9: warning: incompatible implicit declaration of built-in function ‘printf’ [enabled by default]
COLLECT_GCC_OPTIONS='-v' '-mcpu=ultrasparc'
as -s -Av9a -32 -relax -o /tmp/ccwVPByX.o /tmp/ccSBAdgX.s COMPILER_PATH=/usr/lib/gcc/sparc-linux-gnu/4.6/:/usr/lib/gcc/sparc-linux-gnu/4.6/:/usr/lib/gcc/sparc-linux-gnu/:/usr/lib/gcc/sparc-linux-gnu/4.6/:/usr/lib/gcc/sparc-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/sparc-linux-gnu/4.6/:/usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu/:/usr/lib/gcc/sparc-linux-gnu/4.6/../../../../lib/:/lib/sparc-linux-gnu/:/lib/../lib/:/usr/lib/sparc-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/sparc-linux-gnu/4.6/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-mcpu=ultrasparc'
/usr/lib/gcc/sparc-linux-gnu/4.6/collect2 --sysroot=/ --build-id --no-add-needed --eh-frame-hdr -m elf32_sparc -Y P,//usr/lib -dynamic-linker /lib/ld-linux.so.2 -relax
/usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu/crt1.o /usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu/crti.o /usr/lib/gcc/sparc-linux-gnu/4.6/crtbegin.o
-L/usr/lib/gcc/sparc-linux-gnu/4.6
-L/usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu -L/usr/lib/gcc/sparc-linux-gnu/4.6/../../../../lib -L/lib/sparc-linux-gnu -L/lib/../lib -L/usr/lib/sparc-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/sparc-linux-gnu/4.6/../../.. /tmp/ccwVPByX.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/sparc-linux-gnu/4.6/crtend.o
/usr/lib/gcc/sparc-linux-gnu/4.6/../../../sparc-linux-gnu/crtn.o

Hi,

The linker cannot find crt*.o files.

Try adding -Fl/usr/lib/sparc-linux-gnu to compilation options (OPT param).

Thomas

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 declare the symbol (as there was apparantly noone using it, but a linker expecting it).

If I were you, I would try to declare these to functions; but I can give you no garanties that it will help you in any way:

    Procedure _init; cdecl; public name '_init';
    Begin
    End;
    Procedure _fini; cdecl; public name '_fini';
    Begin
    End;

Hope it helps.

BTW: Is this behaviour the same with gcc < version 4.6 insalled?

I'm trying Thomas's suggestion first, pending Florian's comments.

BTW: Is this behaviour the same with gcc < version 4.6 insalled?

Don't know, and since I'm also lining up various "errata" to raise with Debian- some of which are decidedly ripe- I'm very reluctant to do anything non-standard to the system.

.
.

I was hopefully right saying that the symbols were not found, but Florian was even more right saying that the most probable reason of those symbols not being found were object files not found due to different paths not known by the compiler.

No, that wouldn't help I'm afraid. The symbols are necessary for proper initialization and finalization of libc.

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 Florian's request contains a reference to "/usr/lib/gcc/sparc-linux- gnu/4.6/../../../sparc-linux-gnu/" as one of paths for searching the libraries - obviously, normalizing this path gives the path suggested by Thomas.

Tomas

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 have to do

make OPT='-Fl/usr/lib/sparc-linux-gnu' install

otherwise I get a similar error (at 2.6.0).

Hi,

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 are now in /usr/lib/<arch-triplet>. Debian based distros like Ubuntu also do that in recent versions already. At least on 12.10 here I have these files in /usr/lib/i386-linux-gnu although it's a 32 bit only system.

Thomas

See also https://wiki.ubuntu.com/MultiarchSpec

After Florian's suggestion I spent a few minutes reading Debian's comments on their multi-arch changes, and was struck by their admission that they anticipated that they would cause pain.

Trying to anticipate some of this, please could somebody with a (Linux) x86-64 system check that 32-bit fpc works reliably (i.e. using the facilities from the binfmt_misc kernel module). I tried running fpc on an IA-64 system a few days ago with partial success, and if pending changes are about to cause problems I think this is something worth sorting out.

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.

"Florian Klämpfl" 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 have to add the library path for armhf, I assumed it was fixed for all architectures.

Henry

I don't consider myself sufficiently experienced to have an opinion.

I find there's a build problem for 2.6.0 with the IDE debugger interface, affecting at least SPARC on multiple versions of Debian (i.e. it's not caused by the multi-arch changes). I'll take a look at it on x86 Linux and raise it separately.

2012/10/27 Florian Klämpfl

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 the packages/fastcgi dir.

Vincent

I remember having to add a library path to FPCMAKEOPT, for and early debian arm multilib system. Does this work?

Henry

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 the packages/fastcgi dir.

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.

Vincent

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 built-in linker script contains the search path for all system libraries. That is the reason why we don't use the "-T" option the linker complains about, because doing so would tell the linker to ignore the built-in linker script and hence also those system-specific library search paths.

We could also very easily get rid of the -T warning by getting rid of all the built-in linker scripts in the compiler, and replacing them with just the parts that are FPC-specific (basically keeping the ".fpc" section), but for reasons I still don't understand some people think this would cause problems.

The only argument in favour of keeping the compiler-internal linker scripts for Linux targets that I currently can think of is that it would probably make the built-in ELF linker harder to realise (it would probably have to ask the system linker for the default linker script then). We could also let the internal linker use a compiler- internal linker script and the external linker the system default one, but that's probably not a good idea (ideally the internal and external linker would use the same settings, both from a support and from a predictability perspective).

Jonas

Ouch. I started trying to look methodically at Wheezy on SPARC over the weekend, and got bogged down in gdbint issues. I was going to revert to an older OS for test purposes but have been overtaken by hardware failures etc. Save me a kipper :-)

In our previous episode, Mark Morgan Lloyd said:

... and got bogged down in gdbint issues.

Trust me, you are not the only one :-)

The current setup causes *everything* except sections (symbols, constants, etc) to be linked incorrectly, because the script is being executed twice, first time the built-in script, the second time FPC-supplied one. Fortunately, most linking is governed by built-in script, and most of FPC-supplied script is effectively ignored, that's why we get working executables in the end.

I've experimented with removing all but .fpc section from linker script on x86_64-linux and i386-linux targets, and encountered no issues. In the nearest future, I'm going to commit these changes, and also write a test that will fail if linking with current setup.

The internal ELF linker has been already implemented for x86 targets, it only misses appropriate RegisterInternalLinker calls in initialization section of t_linux.pas. It uses an internal script. Reusing the system-default script in its entirety would require closely following ld inner structure (e.g. ld composes .rela.dyn section from .rela.text,.rela.data,etc input sections, while internal linker writes it directly), and probably is not worth the trouble. At the same time, I had to implement a basic parser of ld script files anyway, so partially using the system-default script for e.g. search paths can be done fairly easily.

Regards,
Sergei