DGRIMES at scvl.com
Thu Mar 17 19:31:41 CET 2005
My problem is that libz on some of the remote systems is not current. I'm
compiling on the development server with 1.1.4 now and some of the older
remote systems have 1.1.3. I guess I have some recompiling to do to bring
all of the remote systems up-to-date.
From: David Champion [mailto:dgc at uchicago.edu]
Sent: Thursday, March 17, 2005 10:49 AM
To: Grimes, Dean
Cc: 'gnupg-users at gnupg.org'
Subject: Re: Porting gnupg
* On 2005.03.17, in
<59D747A62703354193CA17350FC3F7D9136A7F at telstar.scvl.com>,
* "Grimes, Dean" <DGRIMES at scvl.com> wrote:
> I have successfully compiled and installed gnupg-1.4.1 on SCO OpenServer
> everything works great. However, I have approximately 500 remote servers I
> need to install it on. I tried tarring up all of the installed binaries
> associated directories and installing it on one of the remote servers but
> won't run. These systems are identical in configuration except for the GNU
> development system not being installed on the remote system.
I'm taking a guess at your problem, based on something I've seen on
Solaris. Recent versions of gcc will configure themselves to use a
shared libgcc.so, and that library will then have to be in the runtime
on each target system. It seems rather a poor idea for gcc ever to
configure that way, unless it's the stock vendor-provided compiler for
the system. I'm not sure what the value is believed to be.
There are several solutions to this, if it's your problem. The easiest
is to delete libgcc.so from your gcc library directory. On my system, it
was at [/usr/local]/lib/gcc/sparc-sun-solaris2.9/3.4.1/libgcc.so* . You
also can modify the specs file.
You'll need to recompile gnupg (or distribute libgcc.so) in any case.
-D. dgc at uchicago.edu NSIT::ENSS
"So now, less than five years later, you can go up on a steep hill...
and with the right kind of eyes you can almost see the high-water
mark -- the place where the wave finally broke and rolled back." -HST
More information about the Gnupg-users