RE: Libtool HEAD testsuite
Ralf Wildenhues mailto:[EMAIL PROTECTED] 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: http://cygwin.com/cygwin-ug-net/using-specialnames.html#id4729824. 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
Re: libltdl exports no symbols (cygwin)
Hi Ralf, Chuck, I am a bit wary that it may cause regressions in users' packages, as they may be using LT_SCOPE. But I see that with the other change, this is needed. User-package use of internal libtool macros (e.g. LT_SCOPE) is outside libtool's control. Hmm, yes. I've never been certain whether LT_SCOPE was *intended* to be purely internal, or for the user to use. The latter seems inappropriate to me now, but I don't think people were aware of this all the time. Indeed - ever since this patch, CVS M4 is now broken on cygwin. I am getting all sorts of link errors along the lines of: libtool: link: gcc -shared modules/.libs/gnu.o m4/.libs/libm4.dll.a-o modules/.libs/gnu-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker modules/.libs/gnu.dll.a modules/.libs/gnu.o: In function `m4_regexp_compile': /home/eblake/m4-head/modules/gnu.c:140: undefined reference to `_rpl_re_set_syntax' This is because M4 was relying on auto-imports, and now that libltdl has an explicit export, the auto-import mechanism is disabled. I still think the fix to libtool was the correct thing to do, but in order to fix M4, I need some help. It looks like I need to properly mark for export all symbols intended for clients of libm4.dll to use, since libm4.dll utilizes libltdl. Eventually, we should do something about this by offering a portable way to decorate imports/exports for users of libtool. Not right now. That's a shame. Until libtool provides helper macros that automatically do the right thing when compiling with libtool, making M4 work on cygwin will be a tougher process. I'm still wondering what to put in NEWS for this and the depending change. We should mention this somehow. Suggestions appreciated. Fix regression in libltdl symbol exports on Cygwin. Side effect: LT_GLOBAL_DATA and LT_SCOPE are now explicitly defined as declspec(dllexport), bypassing auto-export logic on Cygwin. This tracks existing behavior on MinGW. Should we also mention the side effect that you must now mark explicit exports, since you can no longer rely on auto-imports? -- Eric Blake -- View this message in context: http://www.nabble.com/libltdl-exports-no-symbols-%28cygwin%29-tf2459886.html#a8713036 Sent from the Gnu - Libtool - Patches mailing list archive at Nabble.com.
Re: libltdl exports no symbols (cygwin)
Hello Eric, Charles, all, * Eric Blake wrote on Tue, Jan 30, 2007 at 06:00:00PM CET: Should we also mention the side effect that you must now mark explicit exports, since you can no longer rely on auto-imports? This whole issue seems not good for branch-1-5. I'm pondering backing out all related changes from branch-1-5; that is, the NEWS update and the LT_GLOBAL_DATA/LT_SCOPE change of 2007-01-28, as well as the DLL_EXPORT change of 2006-06-01. We cannot do such a big change for 1.5.24, that will affect all users of --with-included-ltdl. The patches were not introduced to fix a regression, rather something that we can see as an improvement, i.e., a /new/ feature, but they cause regressions for others. I would like 1.5.24 to be a no-brainer for users, and I would like to do it soon if possible. If we require changes in user's code, then it's better to make the change when going to 2.0; it's easier for them if all changes occur at once. And I'm easier with having Gettext require HEAD Libtool than all users of libltdl. For HEAD, guys, if you want this really fixed then may I suggest to take another look at Bruno's suggestions: http://lists.gnu.org/archive/html/bug-gnu-utils/2006-05/msg00026.html Any way we go, we should do something more consistent than you cannot rely on auto-imports if you use libltdl. And certainly we should document user-level-required changes in NEWS. Comments and suggestions appreciated. Cheers, and thanks, Ralf
Re: Libtool HEAD testsuite
* Duft Markus wrote on Tue, Jan 30, 2007 at 09:02:24AM CET:
Ralf Wildenhues mailto:[EMAIL PROTECTED] 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:
http://cygwin.com/cygwin-ug-net/using-specialnames.html#id4729824.
[...]
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]
Re: libltdl exports no symbols (cygwin)
Ralf Wildenhues wrote: Hello Eric, Charles, all, * Eric Blake wrote on Tue, Jan 30, 2007 at 06:00:00PM CET: Should we also mention the side effect that you must now mark explicit exports, since you can no longer rely on auto-imports? This whole issue seems not good for branch-1-5. I'm pondering backing out all related changes from branch-1-5; that is, the NEWS update and the LT_GLOBAL_DATA/LT_SCOPE change of 2007-01-28, as well as the DLL_EXPORT change of 2006-06-01. We cannot do such a big change for 1.5.24, that will affect all users of --with-included-ltdl. And this decision solves the problem for MinGW how? Remember that part of the justification for the 2006-06-01 change was that at least that way, we have the same behavior on all win32 variants. If you revert 2006-06-01, cygwin != mingw, and mingw still #defines DLL_EXPORT for all PIC -- which would simply push CVS M4's problems into the future, when somebody tries to compile it on MinGW. And if you try to switch MinGW libtool to not define DLL_EXPORT...hoo boy. A *LOT* of MinGW ports rely on that behavior... So, on one side we have (a) a bunch of MinGW ports, (b) every cygwin port *I* know of except *CVS* m4, plus *released* versions of gettext. On the other...*CVS* m4. The patches were not introduced to fix a regression, rather something that we can see as an improvement, i.e., a /new/ feature, but they cause regressions for others. I would like 1.5.24 to be a no-brainer for users, and I would like to do it soon if possible. If we require changes in user's code, then it's better to make the change when going to 2.0; it's easier for them if all changes occur at once. And I'm easier with having Gettext require HEAD Libtool than all users of libltdl. Wait, you're contradicting yourself. The 2006-06-01 changes were there to fix a regression that popped up with gettext -- not some random pseudo-improvement that C. Wilson made up. By reverting the change (e.g. because it causes regressions for *CVS* M4) to fix *CVS* M4[*], you cause a regression with *released* gettext. Why is THAT ok? Why can't we say that *CVS* M4 should require CVS libtool, and fix this issue there? [*] BTW, I have a longer email I was putting together concerning the root cause of M4's problems w.r.t. LT_SCOPE, DLL_EXPORT, and friends. To wit: CVS M4 has been borked on cygwin for YEARS. Breakage now is nothing new...and reverting cygwin libtool to its broken state vis-a-vis gettext simply to help CVS M4 -- which is borked anyway -- is nonsensical. --- Do what you want, but I am strongly inclined to continue future official cygwin releases of libtool RETAINING the 2006-06-01 and 2007-01-28 changes. I do not look favorably on releasing yet ANOTHER backwards-incompatible version of libtool/libltdl on the cygwin platform, while pretending that it is still compatible. BTW -- it's obvious to me that the reason Eric never noticed this problem until Ralf committed the change to libtool CVS HEAD, was because he has NOT actually been using cygwin official released (e.g. libtool-1.5.23a) libtool. He's been using libtool CVS HEAD to develop CVS M4. So don't use CVS M4 breakage observed with libtool CVS HEAD as a justification for re-breaking cygwin libtool 1.5.24. For HEAD, guys, if you want this really fixed then may I suggest to take another look at Bruno's suggestions: http://lists.gnu.org/archive/html/bug-gnu-utils/2006-05/msg00026.html For 2.2, I tentatively agree (but...[**]). For 2.0 -- GOOD GREIF, PEOPLE, can't we just release the G-D thing and be done? I remember in Jan 2005 we were gonna release 2.0 real soon now. This is freakin' ridiculous. [**] I'm starting to see some support for msvc in libtool -- at least, there have been a few patches floating around. Whatever fancy stuff is done to support DLL decorations for mingw/cygwin, if you want that msvc stuff to work you'll still need some mechanism for the plain-old-dumb msvc linker...and I don't know if Bruno has tried his scheme with that toolset (maybe he has; I'm going from memory here). Any way we go, we should do something more consistent than you cannot rely on auto-imports if you use libltdl. The embedded quote is not an accurate description of the current status. More in my other email. And certainly we should document user-level-required changes in NEWS. Well, yeah -- but make sure the proposed documentation is ACCURATE, first. -- Chuck
Re: libltdl exports no symbols (cygwin)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Charles Wilson on 1/30/2007 10:10 PM: Hello everyone, This whole issue seems not good for branch-1-5. I'm pondering backing out all related changes from branch-1-5; that is, the NEWS update and the LT_GLOBAL_DATA/LT_SCOPE change of 2007-01-28, as well as the DLL_EXPORT change of 2006-06-01. We cannot do such a big change for 1.5.24, that will affect all users of --with-included-ltdl. The problem is not with 1.5.24. CVS M4 _already_ relies on CVS libtool, and the only way that I have been developing M4 head on cygwin is by first installing my own CVS snapshot of libtool, rather than using the cygwin version. Rather, the breakage comes because we forward ported a 1.5 patch to head, and I'm not sure whether the breakage is in libtool, or broken usage by m4, or a combination thereof. [*] BTW, I have a longer email I was putting together concerning the root cause of M4's problems w.r.t. LT_SCOPE, DLL_EXPORT, and friends. To wit: CVS M4 has been borked on cygwin for YEARS. Breakage now is nothing new...and reverting cygwin libtool to its broken state vis-a-vis gettext simply to help CVS M4 -- which is borked anyway -- is nonsensical. I'm inclined to agree - CVS M4 needs help anyway. My observation was more along the lines of the current situation is broken whereas it wasn't last week, so what can I do to help pull things into better shape? --- Do what you want, but I am strongly inclined to continue future official cygwin releases of libtool RETAINING the 2006-06-01 and 2007-01-28 changes. I do not look favorably on releasing yet ANOTHER backwards-incompatible version of libtool/libltdl on the cygwin platform, while pretending that it is still compatible. I would argue that libtool should maintain the patch, as I trust Charles' builds on cygwin and don't want to see him forking from the upstream tarball if it can be helped - no need to revert it, as the breakage has not been seen on released software, but only on CVS m4 which is already bleeding edge dependent, and can afford to make adjustments to accomodate this latest change. BTW -- it's obvious to me that the reason Eric never noticed this problem until Ralf committed the change to libtool CVS HEAD, was because he has NOT actually been using cygwin official released (e.g. libtool-1.5.23a) libtool. He's been using libtool CVS HEAD to develop CVS M4. So don't use CVS M4 breakage observed with libtool CVS HEAD as a justification for re-breaking cygwin libtool 1.5.24. Correct. And if nothing else, CVS m4 proves to be a fun playground for what libtool should be able to do, even on braindead platforms like Windows. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFwDAy84KuGfSFAYARAv1qAKC7n9QeUTVUN5xQJlV5PNigSztQpQCfQHw+ 5OTqGDLQeRZNc2RfgFc/8Yw= =Dm6S -END PGP SIGNATURE-
RE: Libtool HEAD testsuite
Ralf Wildenhues mailto:[EMAIL PROTECTED] 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: http://cygwin.com/cygwin-ug-net/using-specialnames.html#id4729824. 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
* Duft Markus wrote on Tue, Jan 30, 2007 at 09:02:24AM CET:
Ralf Wildenhues mailto:[EMAIL PROTECTED] 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:
http://cygwin.com/cygwin-ug-net/using-specialnames.html#id4729824.
[...]
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
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?
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 http://docs.hp.com/en/B2355-90680/cc_bundled.1.html) 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?
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
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
Ralf Wildenhues mailto:[EMAIL PROTECTED] wrote: * Duft Markus wrote on Tue, Jan 30, 2007 at 09:02:24AM CET: Ralf Wildenhues mailto:[EMAIL PROTECTED] 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: http://cygwin.com/cygwin-ug-net/using-specialnames.html#id4729824. [...] 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 test suite. Cheers, Ralf 2007-01-30 Ralf Wildenhues [EMAIL
