The buildfaq claims that OPT= will add parameters to every compiler commandline. Unfortunately it doesn't seem to actually do that. The options are added when building the compiler and RTL but it seems they aren't added when building fpmake.

This is a problem for me as to successfully build fpmake on a multiarch arm system I need to tell it where to find crti.o (it seems freepascal can successfully build stuff linked against c libraries without finding crti.o on some architectures but not others).

For now i've created a symlink at /usr/lib/crti.o to /usr/lib/arm-linux-gnueabihf/crti.o to make things work but i'd rather not have to mess with my system in that way. Is there some way of specifying options so that they actually get passed to ALL compiler invocations in the build process?

I had to fiddle around like this, too, unfortunately. Does the compiler read fpc.cfg when it's building? It may work when adding it there. Reading /etc/ld.so.conf needs to be fixed, too. At the moment the Makefile adds the contents to -Fl, which doesn't work when there are wildcards.

Henry

In our previous episode, peter green said:

Sounds like a fpmake bug. Please file a bugreport if you haven't done so.

peter green wrote

The buildfaq claims that OPT= will add parameters to every compiler commandline. Unfortunately it doesn't seem to actually do that. The options are added when building the compiler and RTL but it seems they aren't added when building fpmake. This is a problem for me as to successfully build fpmake on a multiarch arm system I need to tell it where to find crti.o (it seems freepascal can successfully build stuff linked against c libraries without finding crti.o on some architectures but not others).

The compiler should find the crt*.o files on its own, especially if you create a special compiler binary for the hard float ABI (there is no point in creating a special binary if you still need to separately specify a bunch of additional options to get the correct behaviour). Or are they in distribution-specific directories for the hard float ABI?

Jonas

Jonas Maebe wrote

The compiler should find the crt*.o files on its own, especially if you create a special compiler binary for the hard float ABI (there is no point in creating a special binary if you still need to separately specify a bunch of additional options to get the correct behaviour). Or are they in distribution-specific directories for the hard float ABI?

debian/ubuntu are introducing (ubuntu have had support for a while, debian have been a bit slower on the uptake) something called multiarch. The idea of multiarch is that one system will be able to have packages from a mix* of architectures installed at the same time. This is not something specific to armhf (though armhf does of course have a multiarch triplet).

As a result of this many libraries (including crt*.o) are now located in /usr/lib/<multiarch triplet*> (or lib/<multiarch triplet>). See debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636802 for previous discussion of this. Debian currently handles this through an entry in the default config file (though the entry they are using right now is likelt to be problematic on a multiarch system with both armel and armhf since it will match the lib directories for both).

A key thing about the way multiarch works is that libraries that are packaged to support multiarch will be located in multiarch directories even if the system they are installed on only has packages from one architecture installed.

Multiarch is a debian/ubuntu creation. I believe someone is attempting to push support to upstream gcc. I'm not aware of any distros outside the debian family that are currently using it,

I am quite happy to prepare a patch that adds the multiarch locations for each architecture to the hardcoded default search paths if you believe that is an appropriate thing to do.

* A multiarch triplet represents an ABI. They are based on GNU triplets but not nessacerally identical to them because sometimes one GNU triplet can convert multiple ABIs and sometimes there can be more than one GNU triplet in use for the same ABI. http://wiki.debian.org/Multiarch/Tuples ** in practice most multiatch systems will probally be combinations like i386/amd64 or ppc/ppc64 or maybe armel/armhf but in principle any combination is possible as long as you can find a way (e.g. binfmt-misc with qemu) to make the biniaries run