Hi,

after unpacking the brand new lazarus 1.0.10 and compiling it anything works fine. The next step was to install the lazreport package into the IDE. Compilation worked up to the linking process:

/usr/bin/ld: cannot find -lc_r
lazarus.pp(135) Error: Error while linking
lazarus.pp(135) Fatal: There were 1 errors compiling module, stopping

This is pretty old and I had this once while FreeBSD was swapping one threading library for another. Nowadays "-lc_r" is unsupported AFAIK and one should use "-lpthread" instead.

I have searched lazarus' Makefiles, my personal configuration in ".lazarus" and checked there is no mapping file for the linker messing things up. The fpc.cfg seems to be fine (an unaltered by me) too.

Where does this come from?
Where should I search to find the error?

TIA,
Marc

FreeBSD 9.1-STABLE amd64
fpc 2.6.0
lazarus 1.0.10

The default widgetset on FreeBSD is gtk2. The gtk2int.pp has {$linklib pthread}.

I guess from one of the fpc units.

Where should I search to find the error?

You can grep for linklib directives in the sources. And you can use the ppudump tool on all .ppu files and grep for c_r.

Mattias

Got a frsh 2.6.2, but that didn't help as expected.

> Where should I search to find the error? You can grep for linklib directives in the sources. And you can use the ppudump tool on all .ppu files and grep for c_r.

This helped me thinking. The error must come from one of the installed ide packages if a clean IDE compiles. So I started kicking out all custom packages and the error is gone. I'll go fixing those now.

Thank you!

Marc

Sounds like a -Xf parameter problem. Without this parameter, pthread is chosen, with libpthread.

So probably you have some stale -Xf in the project, probably in a *really* old project.

Really old versions worked the other way around (c_r default, + -Xf -> libpthread)

This is pretty old and I had this once while FreeBSD was swapping one threading library for another. Nowadays "-lc_r" is unsupported AFAIK and one should use "-lpthread" instead.

A year ago, there were still people with 4.x servers. But the rarety is why the default was changed. Just kill all -Xf parameters.

Mattias Gaertner wrote

You can grep for linklib directives in the sources. And you can use the ppudump tool on all .ppu files and grep for c_r.

Afaik this won't work fool proof. It will work if there is a {$linklib c_r}, but it is also possible that a {$linklib pthreads} was changed to c_r by -Xf. (which is equal to -XLApthreads=c_r )

The c_r/pthreads substitution, like the library substitution system it uses (-XLA, XLO) operates on the list of static libs just before linking, generating a new list.

IOW in the ppu, the names are the same as the linklib, and not necessarily the same as passed to the linker.

I'm very close to absolutely sure that one of the components I kicked out of the IDE has a dependency to very old stuff. There was no [time| need] to fix it yet, but that will be easy (I hope;). Plan is to clean up old sources for not beeing thrown into problems again ...

Thanks for explaning the swapping trick using -Xf.

Regards,
Marc

-Xf and -XL are both not mentioned in the compiler -h help.

That means that either the user or the fpc.cfg passes some special parameters to the compiler, right?

Mattias

No. -Xf is pretty much legacy (since FreeBSD4 is out of support 4 or 5 years now), so it was removed to save space.

-XL is officially still beta. There is some description in the buildfaq, but that was never merged with the documentation

configfile or direct parameter (via whatever means), yes, that's what it sounds like.