In our previous episode, Thomas Schatzl said: > The "_init" and "_fini" you need are the ones from libdl.so. The linker > message doesn't help here. Crt*.o etc. are startup files for gcc > programs. Can you explain how you got to the impression that you need a > crti.o that provides _init and _fini? Just curious.
compiler/systems/t_linux: if linklibc and (libctype<>uclibc) then begin { crti.o must come first } if librarysearchpath.FindFile('crti.o',false,s) then AddFileName(s); { then the crtbegin* } So when the compiler _knows_ it is linking to libc, it will generate a different link.res than without. The compiler knows simply if the "c" name appears in the libs to link. So there are actually four cases: 1. static FPC only application. 2. App that links to a library, but not to "c", and the library has no reference to libc. 3. App that links to a library, but not to "c", and the library has a reference to libc. 4. App links to library and C. Case 1 is all FPC. Case 2 strictly speaking too, just passes the linked library to the linker in link.res but both compiler and linker don't know libc is linked. So FPC generates a link.res for non libc linking, and ld probably doesn't link libc. In case 3, while FPC doesn't know about the libc linkage, it generates the link.res like (1). ld knows that something is wrong, and _might_ add c linking though. Case 4 is the normal situation for libc linking. So just to make sure that case 4 is always picked, every lib should have a reference to "c". When I reformed the unix lib, the idea was that simply using "initc" should force that. (thus not having the ifdef block with linklibs in _every_ header). _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel