RE: Libtool HEAD testsuite

[Duft Markus]

Ralf Wildenhues  wrote:
> Hello Markus,
> 
> * Duft Markus wrote on Fri, Jan 19, 2007 at 05:28:41PM CET:
>> 
>> Sorry, i must correct myself. $EXEEXT *is* used *sometimes* and as
>> far as my situation is concerned, completely in the wrong places...
> 
> Well, it matches the Cygwin semantics of .exe interpolation:
> .
> 
> The other missing bit of data is that on Cygwin and MinGW, a C wrapper
> foo/tagdemo.exe for foo/.libs/tagdemo.exe is also created in addition
> to the shell wrapper foo/tagdemo.
> 
> You don't describe your situation sufficiently well for somebody
> else to do anything about it.  Do you use Cygwin, MinGW, or Interix?
> Native or cross-compile + simulator?  What semantics does the system
> in question have wrt. suffix interpolation?  Find out about those
> semantics and post the link to its documentation.  How come you don't
> post the actual verbose test failure output, so we could see which
> tests have the problem?
> 

The compiler i use is WGCC (still @ sourceforge ;o)) which i wrote
myself. The sematics for executable extensions are configurable, which
means one can set the default output filename in a configuration file.
The current default set by me is a.exe (like gcc...). It was a.out, but
that cause lots and lots of troubles with windows ;o// i will look
further into porting my patches to Interix/WGCC.

>> I don't claim to have found a solution for this, but at least for
>> now, and for me i got a workaround
> 
> Which you didn't post either (as a patch).  :-(
> 

The workaround is to remove $EXEEXT from all the test files and
therefore patch defs.in to check for both files, one with and one
without exe extension. I know thet this is probably not a really good
solution (i attached the patch...). I didn't look at all tests by now,
so there may be others still having EXEEXT in them. I additionally don't
know if i can use $EXEEXT or @EXEEXT@ on defs.m4sh so i for now just
hardcoded the .exe...

Cheers, Markus

> Cheers,
> Ralf



test-suite.patch
Description: test-suite.patch
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool HEAD testsuite

[Ralf Wildenhues]

* Duft Markus wrote on Tue, Jan 30, 2007 at 09:02:24AM CET:
> Ralf Wildenhues  wrote:
> > * Duft Markus wrote on Fri, Jan 19, 2007 at 05:28:41PM CET:
> >> 
> >> Sorry, i must correct myself. $EXEEXT *is* used *sometimes* and as
> >> far as my situation is concerned, completely in the wrong places...
> > 
> > Well, it matches the Cygwin semantics of .exe interpolation:
> > .
[...]
> > You don't describe your situation sufficiently well for somebody
> > else to do anything about it.  Do you use Cygwin, MinGW, or Interix?
> > Native or cross-compile + simulator?  What semantics does the system
> > in question have wrt. suffix interpolation?

With the above question ...

> The compiler i use is WGCC (still @ sourceforge ;o)) which i wrote
> myself. The sematics for executable extensions are configurable, which
> means one can set the default output filename in a configuration file.

... I meant the system (shell, libc), rather than the compiler here.
Your compiler isn't going to try to execute those files.

So, the question still stands: which system fails to execute
  ./foo

if there is an executable foo.exe in the current directory?  Since
apparently I don't know it, and apparently it's not Cygwin nor MinGW,
I'd like to see documentation for it, so I can fix the ChangeLog entry
below.

The func_exec change shouldn't be needed, something like the patch below
should be sufficient.  EXEEXT should be set when you run the test suite.

Cheers,
Ralf

2007-01-30  Ralf Wildenhues  <[EMAIL PROTECTED]>

* tests/defs.m4sh (func_require, func_exec_check): When testing
for existence of required files, also try the $EXEEXT extension.
This is apparently needed on Interix.
* THANKS: Update.
Report by Markus Duft.

Index: THANKS
===
RCS file: /cvsroot/libtool/libtool/THANKS,v
retrieving revision 1.57
diff -u -r1.57 THANKS
--- THANKS  21 Jan 2007 16:15:36 -  1.57
+++ THANKS  30 Jan 2007 20:12:07 -
@@ -101,6 +101,7 @@
   Marc Espie   [EMAIL PROTECTED]
   Marc J. Fraioli  [EMAIL PROTECTED]
   Mark Kettenis[EMAIL PROTECTED]
+  Markus Duft  [EMAIL PROTECTED]
   Olly Betts   [EMAIL PROTECTED]
   Patrick Welche   [EMAIL PROTECTED]
   Paul Eggert  [EMAIL PROTECTED]
Index: tests/defs.m4sh
===
RCS file: /cvsroot/libtool/libtool/tests/defs.m4sh,v
retrieving revision 1.16
diff -u -r1.16 defs.m4sh
--- tests/defs.m4sh 12 Nov 2005 09:16:56 -  1.16
+++ tests/defs.m4sh 30 Jan 2007 20:35:05 -
@@ -5,7 +5,7 @@
 # Gord Matzigkeit <[EMAIL PROTECTED]>, 1996
 # Gary V. Vaughan <[EMAIL PROTECTED]>, 2003
 
-# Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc.
+# Copyright (C) 2003, 2004, 2005, 2007 Free Software Foundation, Inc.
 # This is free software; see the source for copying conditions.  There is NO
 # warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
 
@@ -167,7 +167,7 @@
 my_files=${1+"$@"}
 
 for my_file in $my_files; do
-  test -f "$my_file" \
+  { test -f "$my_file" || test -f "$my_file$EXEEXT"; } \
 || func_skip "You must run ${my_prereq}.test before running $0"
 done
 }
@@ -291,7 +291,7 @@
 $opt_debug
 my_program="$1"
 
-if test -f "$my_program"; then :
+if test -f "$my_program" || test -f "$my_program$EXEEXT"; then :
 else
   shift
   func_error "$0: $my_program did not build [EMAIL PROTECTED]"


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

Re: how to give dependency library in libtool on hpux PA

[Ralf Wildenhues]

Hello Joseph,

* joseph kanagaraj wrote on Tue, Jan 30, 2007 at 08:03:47AM CET:
> 
>  I am facing problem on giving dependency path through automake on hpux
> PA 32 bit . 
> When i genreating shared library libsample2.sl which is dependent on
> libsample1.sl which genreated but not installed in the mcahine.so while
> generating libsample2.sl i have given the 
>  libfmkmgr_la_LIBADD ../../src/.libs/libsample1.la
> 
> With this Iam able to generate the shared library libsample2.sl. but when i
> do chatr on the library, it shows dependend path as static for
> libssampl1.sl. This problem  iam facing on  HPUX 11.i PA 32 bit only. how to
> change the dependend path as dyanmic.  please find the sample Makefile.am .
> 
> 
> lib_LTLIBRARIES = libsample2.la
> 
>  libfmkmgr_la_LIBADD ../../src/.libs/libsample1.la

I think the line above should be

  libsample2_la_LIBADD = ../../src/libsample1.la

Note the three changes:
1) add a dependency to libsample2, not to libfmkmgr.  
2) add a missing equals sign.
3) remove the .libs/ from the path.

I assume the first two are a cut-and-paste typo and are correct in your
code, but the last one is hopefully the one that will fix your problems.
If that's not the case, then please post the output
  ./libtool --config

Another note:

> libsample2_la_SOURCES = *.c

Automake recommends listing all sources explicitly.  The above will fail
if you (or your users) try to use a build tree separate from the source
tree; also, it may include sources that you may not want included (I do
  cp foo.c foo.bak.c

sometimes when I would like to keep some version intermediately, for
example).

Hope that helps.

Cheers,
Ralf


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

Re: no .so file on HPUX platform?

[Ralf Wildenhues]

Hi Ed,

* Ed Hartnett wrote on Tue, Jan 30, 2007 at 12:11:07AM CET:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> > * 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.
> 
> OK, this gave me the clue to try with with CXX=g++. This allows
> libtool to continue to build shared libraries. But there is still a
> problem, alas!

Which compiler is `cc'?  Is that the bundled one or the ANSI compliant
one?  Because on HP-UX 11.0 HPPA, the bundled one gives me:

$ /usr/ccs/bin/cc -b -o a a.o
| (Bundled) cc: warning 422: Unknown option "b" ignored.

(see also )

whereas the "real" one has the following in the manpage: (don't be
fooled by the web page: "online" for HP means on the computer, not on
the interweb)

|-b Generate shared library as output. Compiler generates
|   position-independent code (PIC). Is not compatible with
|   the +ESrel, -dynamic, -noshared options.

and accepts -b.  Version tested is:
$ /opt/ansic/bin/cc -V -c a.c
| ccom: HP92453-01 B.11.X.35098-35101.GP HP C Compiler

whereas the bundled one was:
$ /usr/ccs/bin/cc -V -c a.c
| ccom: HP92453-01 A.11.00.00 HP C (Bundled) Compiler

AFAIR the bundled one is unusable.  Either use the real thing, e.g., by
adjusting PATH so it comes first, or `./configure CC=/ansic/bin/cc';
or simply use gcc.  ;-)

> libtool: link: cc -b -Wl,+h -Wl,libnetcdf.sl.4 -Wl,+b
> -Wl,/usr/local/lib -o .libs/libnetcdf.sl.4.0  .libs/attr.o .l\
> ibs/ncx.o .libs/putget.o .libs/dim.o .libs/error.o .libs/libvers.o
> .libs/nc.o .libs/string.o .libs/v1hpg.o .libs/va\
> r.o .libs/posixio.o   -lc
> cc: warning 422: Unknown option "b" ignored.
> /usr/ccs/bin/ld: Unsatisfied symbols:
>main (Not referenced yet! Probably due to -u option)
> *** Error exit code 1

Cheers,
Ralf


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

Re: no .so file on HPUX platform?

[Albert Chin]

On Mon, Jan 29, 2007 at 04:11:07PM -0700, Ed Hartnett wrote:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > * 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.
> 
> OK, this gave me the clue to try with with CXX=g++. This allows
> libtool to continue to build shared libraries. But there is still a
> problem, alas!
> 
> Can anyone tell me why this link is failing?
> 
> /bin/sh ../libtool --tag=CC--mode=link cc  -g
> -version-info 4:0:0 -no-undefined   -o libnetcdf.la -rp\
> ath /usr/local/lib attr.lo ncx.lo putget.lo dim.lo error.lo libvers.lo
> nc.lo string.lo v1hpg.lo var.lo   posixio.l\
> o
> libtool: link: cc -b -Wl,+h -Wl,libnetcdf.sl.4 -Wl,+b
> -Wl,/usr/local/lib -o .libs/libnetcdf.sl.4.0  .libs/attr.o .l\
> ibs/ncx.o .libs/putget.o .libs/dim.o .libs/error.o .libs/libvers.o
> .libs/nc.o .libs/string.o .libs/v1hpg.o .libs/va\
> r.o .libs/posixio.o   -lc
> cc: warning 422: Unknown option "b" ignored.
> /usr/ccs/bin/ld: Unsatisfied symbols:
>main (Not referenced yet! Probably due to -u option)

While you set CXX=g++, did you set CC=gcc? If not, then the default
bundled compiler, cc, would be selected. And, it cannot be used to
build shared libraries. So, just add CC=gcc.

-- 
albert chin ([EMAIL PROTECTED])


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

Re: how to give dependency library in libtool on hpux PA

[joseph kanagaraj]

Ralf Wildenhues wrote:
> 
> Hello Joseph,
> 
> * joseph kanagaraj wrote on Tue, Jan 30, 2007 at 08:03:47AM CET:
>> 
>>  I am facing problem on giving dependency path through automake on
>> hpux
>> PA 32 bit . 
>> When i genreating shared library libsample2.sl which is dependent on
>> libsample1.sl which genreated but not installed in the mcahine.so while
>> generating libsample2.sl i have given the 
>>  libsample2_la_LIBADD=../../src/libsample1.la
>> 
>> With this Iam able to generate the shared library libsample2.sl. but when
>> i
>> do chatr on the library, it shows dependend path as static for
>> libssampl1.sl. This problem  iam facing on  HPUX 11.i PA 32 bit only. how
>> to
>> change the dependend path as dyanmic.  please find the sample Makefile.am
>> .
>> 
>> 
>> lib_LTLIBRARIES = libsample2.la
>> 
>>  libsample2_la_LIBADD =../../src/libsample1.la
> 
> I think the line above should be
> 
>   libsample2_la_LIBADD = ../../src/libsample1.la
> 
> Note the three changes:
> 1) add a dependency to libsample2, not to libfmkmgr.  
> 2) add a missing equals sign.
> 3) remove the .libs/ from the path.
> 
> I assume the first two are a cut-and-paste typo and are correct in your
> code, but the last one is hopefully the one that will fix your problems.
> If that's not the case, then please post the output
>   ./libtool --config
> 
> Another note:
> 
>> libsample2_la_SOURCES = samplle.c sample2.c
> 
> Automake recommends listing all sources explicitly.  The above will fail
> if you (or your users) try to use a build tree separate from the source
> tree; also, it may include sources that you may not want included (I do
>   cp foo.c foo.bak.c
> 
> sometimes when I would like to keep some version intermediately, for
> example).
> 
> Hope that helps.
> 
> Cheers,
> Ralf
> 
> Thanks lot Ralf for ur message.  It is an cut and pate typo. please find
> the correct one.
>  
>   lib_LTLIBRARIES = libsample2.la
>   libsample2_la_LIBADD = ../../src/libsample1.la
>   libsample2_la_SOURCES = samplle.c sample2.c
>   
> Iam able to generate the shared library libsample2.sl . i have given
> -rpath as /usr/lib ( for both libsample1.sl & libsample2.sl ) .I installed
> the library in /usr/lib. when i do ldd on libsample2.sl , it shows the
> path for libsample1.sl as ../../src/.libs/libsample1.sl .when i removed
> the library from ../../src/.libs/libsample1.sl , it is not taken from
> /usr/lib/libsample1.sl. 
> 
> chatr on library libsample2.sl shows path as static
> shared library 
>shared library dynamic path search: 
>  SHLIB_PATH enabled   second 
>  embedded path  enabled   first  /usr/lib 
>   internal name: 
>   libsample2.sl.0 
>  shared library list: 
>  static../../src/.libs/libsample1.sl
> 
> 
>  
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool
> 
> 

-- 
View this message in context: 
http://www.nabble.com/how-to-give-dependency-library-in-libtool-on-hpux-PA-tf3140847.html#a8724473
Sent from the Gnu - Libtool - Discuss mailing list archive at Nabble.com.



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

RE: Libtool HEAD testsuite

[Duft Markus]

Ralf Wildenhues  wrote:
> * Duft Markus wrote on Tue, Jan 30, 2007 at 09:02:24AM CET:
>> Ralf Wildenhues  wrote:
>>> * Duft Markus wrote on Fri, Jan 19, 2007 at 05:28:41PM CET:
 
 Sorry, i must correct myself. $EXEEXT *is* used *sometimes* and as
 far as my situation is concerned, completely in the wrong places...
>>> 
>>> Well, it matches the Cygwin semantics of .exe interpolation:
>>> .
>>> [...] You don't describe your situation sufficiently well for
>>> somebody else to do anything about it.  Do you use Cygwin, MinGW,
>>> or Interix? Native or cross-compile + simulator?  What semantics
>>> does the system in question have wrt. suffix interpolation?
> 
> With the above question ...
> 
>> The compiler i use is WGCC (still @ sourceforge ;o)) which i wrote
>> myself. The sematics for executable extensions are configurable,
>> which means one can set the default output filename in a
>> configuration file. 
> 
> ... I meant the system (shell, libc), rather than the compiler here.
> Your compiler isn't going to try to execute those files.

Hi,

It's Interix's libc (kind of a pure POSIX implementation, which does not
know any windows paths or extensions). The shells in use are:
/bin/sh -> /bin/ksh which seems to be one or another version of PDKSH,
and a self built BASH (built with gcc 3.3 from interix. Both don't pay
attention to any extension so no matter where, the name(s) given must be
exact on interix.

The thing is, that there is a trick to make KSH recognize extensions
somehow, but it never worked for me. Additionally it would require some
special setup of the PATH variable, which i think is not very portable,
not even between different interix machines ;o//.

> 
> So, the question still stands: which system fails to execute
>   ./foo
> 
> if there is an executable foo.exe in the current directory?  Since
> apparently I don't know it, and apparently it's not Cygwin nor MinGW,
> I'd like to see documentation for it, so I can fix the ChangeLog entry
> below.

I digged into this again a little... The problem is that there could be
any shell in use that compiles on interix, not just ksh...
For example a CSH comes along with interix (ok, ok, it's not used for
script execution, that's still ksh... ;o))

FROM MAN KSH ON INTERIX
=

  PATH_WINDOWS

The Interix profile file sets the PATH_WINDOWS environment variable
in
which you can specify a suffix matching order. This is used to look
for
Windows commands with standard extensions, namely .com, .exe, .ksh,
.bat,
and .cmd. In the Interix Korn shell, if you type the echo
$PATH_WINDOWS
command, you will see the default value of PATH_WINDOWS set to the
following (or something similar):

 
/dev/fs/C/WINDOWS/system32/.com,.exe,.ksh,.bat,.cmd,:/dev/fs/C/SFU/commo
n/
.com,.exe,.ksh,.bat,.cmd,

The path name is in POSIX format, not Win32.

You can also specify your own suffix matching order. The value of
PATH_WINDOWS is a colon-separated list of directory names with the
following format:

pathname[/suffix-list][:pathname[/suffix-list]]

The suffix-list is a comma-separated list of suffixes. Each suffix
starts
with a period (.) and contains up to a total of three additional
characters, as illustrated in this example:

 
PATH_WINDOWS=/dev/fs/D/SFU/common/.exe,.ksh:/dev/fs/C/WINNT/system32/
.exe,.bat

In this example, .exe and .ksh files will be suffix matched in the
/dev/
fs/D/SFU/common directory, and .exe and .bat files in the
/dev/fs/C/WINNT/
system32 directory. A file with the .exe extension will be matched
in the
/dev/fs/C/WINNT/system32 directory only if it is not found in the
/dev/fs/
D/SFU/common directory.

If you specify only the directory, such as
PATH_WINDOWS=/dev/fs/C/WINNT/
system32 all the suffixes are matched in the following order:

* .com
* .exe
* .ksh
* .bat
* .cmd
* ""

The last example in the list is empty. This indicates the lack of a
suffix. For example, you can enter the following at an Interix shell
prompt:

PATH_WINDOWS=/dev/fs/C/WINNT/system32:/dev/fs/D/sfu/common/.exe
echo $PATH_WINDOWS

The echo $PATH_WINDOWS command displays:

 
/dev/fs/C/WINNT/system32/.com,.exe,.ksh,.bat,.cmd,:/dev/fs/D/SFU/common/
.exe

Note that the empty field between .cmd and : indicates that there is
a "no
suffix" entry in the search path.

FROM MAN KSH ON INTERIX
=

Again, this is for KSH, and nothing prevents peaople from using bash
(which anyway is a good idea ;o)) or any other shell that compiles on
interix.

Cheers, Markus

> 
> The func_exec change shouldn't be needed, something like the patch
> below should be sufficient.  EXEEXT should be set when you run the
>