[fpc-devel] Re: Accepted fpc 2.6.2-1 (source amd64 all)

[peter green]

Marco van de Voort wrote:
>
> After some discussion, something to try:
>
> try adding -dNO_THREADING to CROSSOPT (for target) and maybe also to OPT
> (for host)
>   
Unfortunately it seems that at least when building natively (note: 
debian is and always has been natively built) neither OPT or CROSSOPT is 
passed to the build of fpmake. I asked about this in the past ( 
http://bugs.freepascal.org/view.php?id=21547 ) and was told it was by 
design.
> It will disable threading inside fpmake by not USESing cthreads, eliminating
> the need for cross-linking to work at all.
>   
Disabling threading is the last resort option but really I just want to 
pass the path to the compiler, I know where it should be looking. The 
bug report I mentioned above  claims there is a FPMAKEOPT variable but I 
couldn't find any evidence of it in the 2.6.2 source tree. Maybe it 
appeared after the 2.6 series was branched (last time I ran into this 
issue I was dealing with trunk)

The good news is I found out I can pass the setting in through the 
"FPCFPMAKE" variable. fpmake was then built successfully.

I then ran into the same link problem building fpdoc. I was able to work 
arround that one through the "OPT" variable.

While i've managed to get the debian 2.6.2 package to build I still feel 
that the best soloution long term is to add the multiarch library paths 
to the compiler itself. Debian/ubuntu are two of the biggest linux 
distros, their use of multiarch paths isn't going to go away and while 
we distro packagers can work arround the fact that the compiler looks 
there by default end users who use the upstream release directly are 
likely to be somewhat phased by it (especially because of the way the 
compiler fails in a non-obvious way). I got a fairly negative response 
to that last time I suggested it to you guys (don't remember if it was 
on irc or the mailing list) but since then I notice someone has gone 
ahead and added the multiarch paths for armel and armhf to the default 
search path in trunk.

root at debian:/fpc-trunk# grep -r arm-linux-gnu *
compiler/systems/t_linux.pas:    
LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/arm-linux-gnueabihf',true);
compiler/systems/t_linux.pas:    
LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/arm-linux-gnueabi',true);
Binary file tests/test/cg/obj/linux/arm-eabi/tcext6.o matches
root at debian:/fpc-trunk#

If they are going to be added for armel and armhf shouldn't they be 
added for other ports too?

> That being said, I don't like FPC simply silently dropping those
> objectfiles.  That should be improved, please file a bug (but I think that
> is more something long term for trunk, not 2.6.2
http://bugs.freepascal.org/view.php?id=24518