Re: Has ar a limit?

["Orlando P. Hevia" <heviaop at ssdfe dot com dot ar>]

Ian Lance Taylor wrotes:

> "Orlando P. Hevia" <heviaop@ssdfe.com.ar> writes:
> 
> > I am using ar to generate a library with a big .o file
> > (640kB).
> > 
> > The object is generated by gcc, and it works properly when
> > it is linked to the binary.
> > 
> > The .c file is obtained with f2cx from a FORTRAN file,
> > because g77 cannot compile too big COMMONs. The FORTRAN
> > file is a block data (no sentences in it).
> > 
> > ar produces a library with the object, but the binary
> > obtained linking with the library runs erratically, or
> > aborts.
> > 
> > I found the same problem with djgpp (2.03), Mingw32
> > (2.02), and Linux. 
> > 
> > I solved the problem linking with the .o file, but I am
> > interested in include it in a library.
> 
> Perhaps the problem has to do with how common symbols are
> handled in an archive.  Are you certain that the object file
> is being pulled in from the archive at all?  If the symbols
> are common in the main program and common in the .o file,
> the .o file will probably not be pulled in; objects are only
> brought in from archives to satisfy undefined symbol
> references, not because they happen to define the same
> common symbols.  You should be able to use the linker -t or
> -Map option to find out.  It might also be interesting to
> observe the output from the -warn-common option in both
> cases.
> 

I found the cause of my problem: an object in library is 
not inserted if it is no called...and a block data object 
is never called.

I changed the block data to a subroutine with only the 
640kB of data in it, and call the subroutine very early in 
the main program. 

The resulting module can be included in the library, it 
will be included in binary, and my time test is successful: 
no extra time to pay with the change. 

Thanks you.

OPH. 2001-6-8 5:02

Ing. Orlando P. Hevia   
heviaop@ssdfe.com.ar
Santa Fe-Argentina