Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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 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 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). 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 change I didn't add it for the other architectures. How do I workaround it? 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 remember having to add a library path to FPCMAKEOPT, for and early debian arm multilib system. Does this work? Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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. 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 :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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. 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. 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. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 have to add the library path for armhf, I assumed it was fixed for all architectures. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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. 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. 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. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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? 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. 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 `/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. 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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, 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. 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. The linker cannot find crt*.o files. Try adding -Fl/usr/lib/sparc-linux-gnu to compilation options (OPT param). Thomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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? On 10/26/2012 12:29 PM, 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 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. -- Ewald Events don't necessarily happen in chronological order; yet somehow they do persist to happen. Sometime. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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). . . 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. 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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). -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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. 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. See also https://wiki.ubuntu.com/MultiarchSpec ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing
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 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. 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
