autotools not suited to proprietary development?

[Ryan McDougall]

Hello,

 First of all, Im only looking for serious answers, and I dont want to
start any flamewars, so Ill start out by saying that quite likely the
only problem here is my lack of knowledge of autotools, and the other
the issues involved. Please correct me at any point you disagree with.

 After some cajoling of new company from myself -- a linux and free
software buff, and a lonely professor who wants to use one of our SDKs
on linux, it was finally decided to make a linux port of our
SmartCollision SDK.
 The C++ code is clean and portable, so "porting" really just consists
of building the binaries, and putting them in a friendly distributable.

 In windows the deliverable is a zip file with .DLLs, .LIBs, and header
files that should work on any modern widows. The linux deliverable
should be the same, however, given the large amount of variability in
the linux world, I would like to have autoconf do as much work as
possible, which I think means getting the code to compile on my build
machine, and link on the users environment.

 With my inexperience with doing proprietary development, I chose to use
autotools since I was the only tool I was familiar with from open source
projects. The problem is the major assumption in autotools is that the
source code is being shipped to the end user, and thus the distributable
package is the same as the source tarball. I was unable, in the time
allowed, to come up with a way to easily (ie clean, without many hacks)
give me the sort of solution I was looking for, which would look
something like:
'./configure && make && make bindist' on the build machine
and
'./configure && make && make install' on the end users machine

As it is we just 
'./configure --prefix=/package/dir/ && make && make install' 
then manually package the static libA.a libraries and headers there. We
couldnt do shared libraries since libtool wanted to link the .so to the
build machine's prefix (via -rpath switch).

Has this problem been solved before with autotools? Or is this just not
a problem autotools wants to solve? If so, does anyone have alternative
recommendations?

I ask because I have hope we can port our remaining products to linux,
and that I can learn how to do this sort of thing properly next time.
But if it gets too expensive for my boss, he wont be likely to approve
it.

Cheers,