Oh, no not again: Error when making


I got this program that I really want to run on my PB G4. It has a simple command-line interface - but I can't get it to compile (or link, actually). It's delivered with a make file but not with a configure script. Works fine on Linux. I'd be grateful for any lead that can let me get it running.

The modules compile ok but then I get:

/usr/bin/ld: can't locate file for: -lcrt0.o
make: *** [mb] Error 1

I have looked around for leads into what crt0.o is and I've sen vague things about "startup modules". Doesn't help me, that's for sure. There doesn't seem to be any reference to this in the c code or in the header files.



Just because....or maybe especially because it runs in Linux, it doesnot necessarily run on OSX

looking for crt0.o

sounds like an Xwindows thing,

or it is a c runtime???
whatever... maybe a clue to what the mystery program is and a link pointing to the source would be helpful to anyone seriously trying to help you.

the reference in the Makefile is enough

and the functions in the other source files are depending on that object to be available.


I get the problem with simple c or c++ command-line interface programs. There shouldn't be any platform or x-windows things in there.

This (found on the web) sounds pretty serious:

"By default, each program linked by the compiler is linked with `crt0.o' and `libgcc.a'. `crt0.o' initializes the stack and calls `main()'."

My computer has no file crt0.o on it. I checked another one with Mac OS 10.1 on it. Nothing there either. The program compiles fine on a Linux box. There I have:

So, am I lacking something? Can someone check to see if they have a crt0.o file on their 10.1 or older? Never got this error under 10.0.4.



I've had that same issue. I'm compiling a "just" c program for comand line interface. I just posted a question to this effect as well. I did find some info though in the cc man (pdf version). Check this out:

$make IEEE-NaN
cc -no-cpp-precomp -fno-common -arch ppc -static -D__macosx -D_BSD_TYPES TestNaN.c -lm -lgdbm -ldl
/usr/bin/ld: can't locate file for: -lcrt0.o
make: *** [IEEE-NaN] Error 1

I've read in the cc man that
"If GCC_EXEC_PREFIX is set, it specifies a prefix to use in the names of the
subprograms executed by the compiler. No slash is added when this prefix
is combined with the name of a subprogram, but you can specify a prefix
that ends with a slash if you wish.

If GNU CC cannot find the subprogram using the specified prefix, it tries
looking in the usual places for the subprogram.

The default value of GCC_EXEC_PREFIX is prefix/lib/gcc-lib/ where prefix is the
value of prefix when you ran the configure script.

Other prefixes specified with -B take precedence over this prefix.

This prefix is also used for finding files such as crt0.o that are used for linking."

However, I'm not sure how to use this as I'm still learning how to do all this stuff.

Any suggestions?


Originally posted by resglowing
I don't quite know exactly what they are doing here, but they definitely use crt0.o for something.
After looking some more, I've realised that crt0.o is a very basic routine which is apparently called to set up the stack before even main() is called at the start of the application. This kind of routine can't be missing. It has to be some problem with headers or something. Some header files are being used for i386 and ppc alike and there are "defines" that distinguish the definitions. Could this be a mix somehow. I may be on the wrong track here, but it's the only lead I have right now.

Would anyone know of a "macro" or whatever it's called that might force the compiler to select the ppc definitions. Something like: -D_TARGET=ppc. I know nothing of these things and I haven't been able to find any description either.

Grateful for any help.


any way... it is the initial c-runtime object
there is a crt1 in the lib.

and it does come down to a configuration problem

this bad configuration is not limited to macOSX as there are plenty of reference on google which show other people having the similar problem.

I don't know the exact location but it may be in the libcc.dylib

which indicates the problem that you are trying to static link to the system or standard c library....

these are still guesses and the proper way to discuss these is to either post a link to the source which you are having problems with or post a small example which demonstrates the problem with instructions that you are using to compile.

inclusion of the crt0.o "should" be automatic if you have the right flags set...

to date, there is no "appropriate" information on this topic thread.

just a bunch of idle speculation.

so if you are having a problem involving the compiler, please post all details and then you could possibly get some relevant help.

Otherwise, I have already successfully compiled so many packages....just one package which doesn't have some flag set will give other people the wrong impression.

The correct thing to do is to read the makefile and the source before compiling so that you can know what to expect. and then...maybe...you see that some standard flag has not been set....

and read the docs and the man pages while you are at it...


Originally posted by jimr
The correct thing to do is to read the makefile and the source before compiling so that you can know what to expect. and then...maybe...you see that some standard flag has not been set....

and read the docs and the man pages while you are at it...
Thanks for the helpful suggestions. To check out the problem, get the UNIX version of the program at http://morphbank.ebc.uu.se/mrbayes/

and run make.

I apologise for not having enough knowledge before learning. It's more of a problem for me than for you though, so please stop bitching. ;)


Proclus (GNU-Darwin) suggested I use the -dynamic flag. It resolved the problem! Thanks for putting up with my idle speculating.