Re: autotools not suited to proprietary development?

[Ryan McDougall]

On Wed, 2006-10-04 at 21:33 -0700, Andre Stechert wrote:
> On Oct 4, 2006, at 8:55 PM, Ryan McDougall wrote:
> 
> > However the problem remains that Im at a bit of a loss how to ship a
> > shared .SO library easily. If I build on my machine (or a set of
> > supported build machines) then the build will link to my prefix (lets
> > say /usr/lib) and the end user has no choice where he wants to  
> > place his
> > library?
> 
> This can be hard to do portably but not because of the autotools.  I  
> think it
> boils down to two kinds of problems:
> 
> 1) If your build is libtoolized, then you may end up with -rpath  
> references
> in your .la files (Google for "debian rpath" to get a sense of the  
> drama that's
> followed this issue over the years).  If you're just distributing  
> the .so's, then
> this isn't so much of a problem, as you can fix it by having your  
> users install
> the .so wherever they want, but they have to reference by augmenting  
> their
> LD_LIBRARY_PATH appropriately. 


> In summary, if you're careful about it, you can do exactly what you  
> propose.
> 
> Cheers,
> Andre

Apologies if this is starting to wander off course, but Im really trying
to learn all this stuff so I can port more programs to linux, so I hope
you dont mind being the ones to give me a clue but ...

should I understand that (for example) when redhat/debian build lets say
libc for packaging as a binary, they download a tarball and do a
complicated form 
'./configure --prefix=/usr && make && make install' on a bare machine
without any libc, then tar up the result for an RPM or DEB?

I have looked briefly how to make RPMs, but Ive got some missing pieces
here...

Im well aware this is getting offtopic, so if possible could you spare a
clue and a link to a place where I can research the problem more myself?

Cheers,