Re: no .so file on HPUX platform?

[Ralf Wildenhues]

* Ed Hartnett wrote on Mon, Jan 22, 2007 at 09:31:36PM CET:
> 
> I only have this one HPUX system to test on, and it's pretty out of
> date, I suspect. But if I ask them to upgrade it, they'll probably
> just say "Nah, let's just get rid of it..."

Do you have aCC installed there?  If yes, could you try to build netcdf
with it?  Over here it's chosen, rather than CC, as C++ compiler.

> I have put the output here:
> 
> ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/hpux_shared_issue_configure.txt.gz

It shows two things: libtool doesn't support shared libs with CC on
hpux1[01]:
| CC*)
|   # FIXME: insert proper C++ library support
|   ld_shlibs_CXX=no

Second, shared libraries are turned off if either compiler used in the
configuration doesn't support them.  (Whether the latter is a bug or
limitation in Libtool is another question; but I hope we can postpone
that one to another day.)

Good to know this one is settled for now.  Only one major HPUX-related
bug in Libtool to go.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: no .so file on HPUX platform?

[Ed Hartnett]

Ralf Wildenhues <[EMAIL PROTECTED]> writes:

> * Ed Hartnett wrote on Fri, Jan 19, 2007 at 03:02:01AM CET:
>> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>> > * Ed Hartnett wrote on Wed, Jan 03, 2007 at 05:50:38PM CET:
>> >> 
>> >> On our HPUX platform however, no libnetcdf.so file results. Yet the
>> >> build seems to work OK. 
>> >
>> > The shared library extension should be '.sl'.  Please show
>> >   ./libtool --config
>> >
>> > and
>> >   ./libtool --features
>> 
>> Here they are:
>> 
>>  ./libtool --config
>> 
>> # Whether or not to build shared libraries.
>> build_libtool_libs=no
> [...]
>
>> bash-2.04$ ./libtool --features
>> host: hppa2.0w-hp-hpux11.00
>> disable shared libraries
>> enable static libraries
>
> So something decided that shared libraries were not ok.  So we need to
> take a closer look what did that.  I tried to build this:
>
>> ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/netcdf-daily.tar.gz
>
> on a hppa2.0w-hp-hpux11.00 system using this:
>
>> ./configure --enable-shared --enable-c-only
>
> (but with a VPATH setup).  And I get
>   enable shared libraries
>   enable static libraries
>
> and I get a nice library 'libsrc/.libs/libnetcdf.sl.4.0'.  'make check'
> succeeds as well.

That's wonderful news!

I only have this one HPUX system to test on, and it's pretty out of
date, I suspect. But if I ask them to upgrade it, they'll probably
just say "Nah, let's just get rid of it..."

So I say nothing and use what I have. ;-)

> So, we're still at the head scratching stage.  Ed, could you provide
> a build log, including config.log and configure output.  Probably that
> won't even show it either, so if you have time, go and put
>   set -x
>
> in the second line of 'configure', rerun that and upload the output
> somewhere.  If you must post it, be sure to bzip2-pack.
>

I have put the output here:

ftp://ftp.unidata.ucar.edu/pub/netcdf/snapshot/hpux_shared_issue_configure.txt.gz

Thanks,

Ed


-- 
Ed Hartnett  -- [EMAIL PROTECTED]



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Problem with post(un)install cmds

[Ralf Wildenhues]

Hello Markus,

* Duft Markus wrote on Mon, Jan 22, 2007 at 08:22:04AM CET:
> 
> I wrote the following two for libtool 1.5.22 and they worked perfectly.
> Now i just copied them over to libtool 2.1a (CVS HEAD), and it doesn't
> seem to work

Please read 
under "it doesn't work".  Show what you did, how it failed, please.
Copy and paste, don't only describe failure.  Post the command that
caused the failure.

> I believe that there is a difference in how libtool executes these
> code snippets, is this correct?? If yes, how can i adapt this, so it
> works with  libtool 2?

Probably the globbing happens too early.

> postinstall_cmds='base_file=`basename \${file}`~
> dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo
> \$dlname'\''`~
> dldir=$destdir/`dirname \$dlpath` ~
> set dummy `ls -l $dir/\$dlname*.dll` ~

What's this line supposed to set $2 and $3 to?  If that's not one of
your problems, then surely it will be for cross-compilation.

> while test -n "\${3}" ; do shift; done ~
> dllname=`basename ${2}` ~

How come in these two lines you escape $2 and $3 differently?
Why do you even do all this shifting and ls -l?  Why not just
set dummy $dir/\$dlname*.dll
[dlname=`basename \${\$#}`]

(I haven't tested the escaping here; you probably need a set of [] for
M4-escaping the $#, and the backslashes so that the shell doesn't
interpret too early.)

But still I don't understand what the code is intended to achieve.
There could be unrelated files lying around there matching
  $dlname*.dll

for example a library whose first part of the name equals $dlname.

> test -d \${dldir}/../bin || mkdir -p \${dldir}/../bin ~
> $install_prog $dir/$dllname \$dldir/../bin/$dllname ~
> chmod a+x \$dldir/../bin/$dllname'

> postuninstall_cmds='dlpath=`$SHELL 2>&1 -c '\''. $file; echo
> \$dlname'\''`~
> set dummy `ls -l $dir/../bin/\$dlname*.dll` ~
> while test -n "\${3}" ; do shift; done ~
> $rm ${2}'

Likewise here.

Hope that helps.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

(no subject)

[Bob Stemper]

Is there a newer version of libtool for Solaris 10?  I tried the  1.5.22
version but had  make errors (with libltdl.a and ltdl.o) 

 

Thanks,

Bob

 

 

___
http://lists.gnu.org/mailman/listinfo/libtool