Re: sh portability questions
Just a couple of random thoughts: * Paul Eggert wrote on Wed, Sep 28, 2005 at 12:36:06AM CEST: > Andreas Schwab <[EMAIL PROTECTED]> writes: > > Paul Eggert <[EMAIL PROTECTED]> writes: > > > >> Assuming you don't need recursion, here's a thought. I believe this is a decent assumption for the functionality both Autoconf and Libtool provide now. > >> Use "local", but > >> stick to the convention that all variable names are unique. On > >> systems that don't support "local", define a function named "local" > >> that warns if any of its arguments is a variable whose value is set; > > > > That would also (spuriously) warn if you call a function with local > > variables a second time, unless you explicitly unset the local variables > > before returning. > I guess the best we can do is define a function "local" that does nothing. We had the idea of emulating local variables (in the non-recursive setting) with m4: http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00068.html but it was admittedly seen as rather ugly-to-read for the end-user. (Begs the question how nice to read Autoconf output is now.. ;-) You can probably even have m4 (or a combination of m4 and testsuite shell scripts) check that your function call tree doesn't have any circles, and produce the output topologically sorted, just as the AC_REQUIRE machinery does now. Probably way overkill. Cheers, Ralf, who ducks and runs now ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: SYSROOT/DESTDIR
Hi Tim, * Tim Rice wrote on Wed, Sep 28, 2005 at 01:16:47AM CEST: > On Tue, 27 Sep 2005, Ralf Wildenhues wrote: > > * Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST: > > > I'd like to be able have the embedded runpath be /opt/lib even > > > if I install in /opt/foo/lib. (the package posinstall script would put > > > symbolic links in /opt/lib) > > > > I believe that should be possible now, although in a bit weird way: > > configure --prefix=/opt --enable-fast-install [OPTIONS] > > make > > make install DESTDIR=/tmp > > $mkdir_p /opt/foo > > mv /tmp/opt/* /opt/foo > > # create symlinks .. > > ./libtool --mode=finish /opt/lib > > (surely you can also use some other path below /opt as DESTDIR to avoid > > another copy if /tmp is on another mount point). > > Hmm, that may work. I'll have to try it sometime. > It'll require some serious changes to my package build scripts. :-( I should add that, when done this way, the package might expect all other files to appear below /opt as well (for example /opt/share etc.). If you only wanted the lib/ directory to appear someplace else, then I think you can achieve this by even uglier configure --prefix=/opt/foo --libdir=/opt/lib --enable-fast-install \ [OPTIONS] make make install DESTDIR=/tmp mv /tmp/opt/lib/* /opt/lib/* # or similar; ensure target dirs exist mv /tmp/opt/* /opt/foo # see above # create symlinks ./libtool --mode=finish /opt/lib Note this is untested, but it'd be good to know if it causes trouble with existing packages. :) Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: sh portability questions
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> "local" isn't in POSIX so I'd avoid it in portable scripts.
Doh. Thanks.
> For what it's worth, I briefly searched for this issue and found these
> bug reports dated this year where someone used "local" in a shell
> script and someone else complained and fixed it.
> http://www.networksecurityarchive.org/html/Secure-Shell/2005-02/msg00067.html
> http://packages.debian.org/changelogs/pool/main/x/xfree86/xfree86_4.3.0.dfsg.1-14/changelog
Thanks, I should have done this myself...
> Is "local" that crucial? Admittedly it's very annoying to lack local
> variables, but you can always solve it by renaming. (Unless you want
> to use recursion. Is that a goal here?)
No, recursion is not an issue, but it was to avoid having to stick to
ugly naming convention to avoid clashes.
> Assuming you don't need recursion, here's a thought.
Nice trick! Thanks for the suggestion. Unfortunately, although I
don't have recursion, I do call my function multiple times. Of course
I could start using 'unset', which is unportable but easy to work
around, but that starts to become quite a mess.
I can actually define "local" to do nothing and use an external
maintainer-check to grep'n check them.
Also, maybe I am paranoid, but would you trust shells to support
conditional function definitions? Or function definitions in eval?
if (local foo) >/dev/null 2>&1; then :; else
local () { true; }
fi
or even
(local foo) >/dev/null 2>&1 || local () { true; }
Bah. First trust, then react. Thanks!
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: sh portability questions
Akim Demaille <[EMAIL PROTECTED]> writes: > Also, maybe I am paranoid, but would you trust shells to support > conditional function definitions? Or function definitions in eval? No, you're not paranoid. But I think I would trust it, yes. Admittedly it might take some iterations to get the test right. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: sh portability questions
* Akim Demaille wrote on Wed, Sep 28, 2005 at 09:51:23AM CEST:
>
> I can actually define "local" to do nothing and use an external
> maintainer-check to grep'n check them.
>
> Also, maybe I am paranoid, but would you trust shells to support
> conditional function definitions? Or function definitions in eval?
>
> if (local foo) >/dev/null 2>&1; then :; else
> local () { true; }
> fi
>
> or even
>
> (local foo) >/dev/null 2>&1 || local () { true; }
You'd have to forbid
local foo=bar
then. (I guess you didn't want to use it anyway.)
Hmm, if it weren't for quoting issues, you could use
local ()
{
for l
do
case $l in *=*) eval "$l";; esac
done
}
but quoting kills that, unfortunately, and func_quote_for_eval
might be way overkill here.
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: sh portability questions
Akim Demaille <[EMAIL PROTECTED]> writes:
> if (local foo) >/dev/null 2>&1; then :; else
> local () { true; }
> fi
Note that local is only valid in function context, so this will always
produce a failure.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: sh portability questions
>>> "Andreas" == Andreas Schwab <[EMAIL PROTECTED]> writes:
> Akim Demaille <[EMAIL PROTECTED]> writes:
>> if (local foo) >/dev/null 2>&1; then :; else
>> local () { true; }
>> fi
> Note that local is only valid in function context, so this will always
> produce a failure.
Thanks, I didn't know. How about this then?
(
foo=bar
test_local () {
local foo=foo
}
test_local
test $foo = bar
) || local () {
case $1 in
*=*) eval "$1";;
esac
}
___
http://lists.gnu.org/mailman/listinfo/libtool
Bug in the doc?
Hi,
the info pages for libtool says
" Shared libraries, however, may only be built from
"position-independent code" (PIC). So, special flags must be passed to
the compiler to tell it to generate PIC rather than the standard
position-dependent code." [libtool.info.gz]
This looks wrong to me. A final program, or a final shared library, does
not care if its object files were built with or without -fpic/-fPIC. At
least this is the case on GNU/Linux and afaics {Free,Open}BSD. I maybe seen
it on the MacOS-X/Darwin too when I last tried building some on
Sourceforge CF. On Win32, -fPIC is always in effect.
Comments please.
Jan Engelhardt
--
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: A versionized variation on `lt_dlopen ()'
Hi Ludovic, * Ludovic Courtès wrote on Tue, Sep 27, 2005 at 06:25:34PM CEST: > > After reading a recent thread on `guile-user', Can you give a pointer to the thread? I couldn't find it easily (i.e., within one minute :) > it occurred to me that > `lt_dlopenext ()' doesn't allow to pass information about the version of > a module that is requested. > > This is quite unfortunate, especially for Guile, since Guile modules > load C libraries using `dynamic-link' which is roughly the Scheme > version of `lt_dlopenext ()'. This precludes having several versions of > a given extension installed at once since each of these versions need to > load a particular version of its companion C library. Erm, I may be misunderstanding, but you actually have several libcs lying around which you choose to load from (for other libraries, I'd understand, but libc)? This question is of course independent of your actual request. > So, I think it would be very nice to have something like: > > /* Open a module with the file name FILENAME which is compatible with > revision REVISION of interface INTERFACE. The module should have > been linked with `-version-info'. */ > lt_dlhandle lt_dlopen_version (const char *filename, > unsigned interface, > unsigned revision); > > And similarly for `lt_dlopenext ()'. And I believe this may also be > useful for other kinds of programs, like programs that use plug-ins (for > instance, plug-ins could be compiled with a `-version-info' that > reflects the version of the plug-in API exposed by the program). > > What do you think? A couple of thoughts: For one, you'd need to use the .la files to open the modules then (with the current functions, you can also open the plain .so or whatever it's called). This is probably not a big constraint for your use. For another, static linking (dlpreopening) of more than one version of the module would not work, but that is nothing new. Other than that, it sounds like a reasonable idea to explore post-2.0. I believe, though, you should use INTERFACE only to decide which one to open; the function would then search for a module where INTERFACE lies between CURRENT-AGE and CURRENT, and try to open that. If there are multiple matches, I'm not sure what would be best: among modules differing only in REVISION, obviously the highest would be best. Other than that: Assuming that, with increasing CURRENT, CURRENT-AGE would also be non-decreasing, it should probably select the one with the highest CURRENT, I guess. (The CURRENT comparison would obviously have higher precedence than the REVISION comparison.) Side issue: When we fix preopening to not need the .la file at all, we'll also have to store the version information then. I must admit that I haven't thought all the way through this. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Bug in the doc?
On Wednesday 28 September 2005 07:56 am, Jan Engelhardt wrote:
> " Shared libraries, however, may only be built from
> "position-independent code" (PIC). So, special flags must be passed to
> the compiler to tell it to generate PIC rather than the standard
> position-dependent code." [libtool.info.gz]
>
> This looks wrong to me.
looks correct to me
> A final program,
the snippet you posted doesnt say anything about final programs, just shared
libraries
> or a final shared library, does
> not care if its object files were built with or without -fpic/-fPIC. At
> least this is the case on GNU/Linux and afaics {Free,Open}BSD. I maybe seen
> it on the MacOS-X/Darwin too when I last tried building some on
> Sourceforge CF. On Win32, -fPIC is always in effect.
sounds like you're testing on x86. some architectures (like x86) will accept
non-PIC objects in shared libraries, but many (like alpha/parisc/x86_64) will
fail to even link the objects together into a shared library.
-mike
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Bug in the doc?
Hi Jan,
* Jan Engelhardt wrote on Wed, Sep 28, 2005 at 01:56:17PM CEST:
>
> the info pages for libtool says
>
> " Shared libraries, however, may only be built from
> "position-independent code" (PIC). So, special flags must be passed to
> the compiler to tell it to generate PIC rather than the standard
> position-dependent code." [libtool.info.gz]
And in general, this is true. There are exceptions.
> This looks wrong to me. A final program, or a final shared library, does
> not care if its object files were built with or without -fpic/-fPIC. At
> least this is the case on GNU/Linux and afaics {Free,Open}BSD. I maybe seen
> it on the MacOS-X/Darwin too when I last tried building some on
> Sourceforge CF. On Win32, -fPIC is always in effect.
$ uname -ms
Linux x86_64
$ echo 'int f() { return 42; }
int g() { return f(); }' > a.c
$ gcc -c a.c
$ gcc -shared -o liba.so a.o
usr/bin/ld: a.o: relocation R_X86_64_PC32 against `f' can not be used when
making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
$ gcc -fPIC -c a.c
$ gcc -shared -o liba.so a.o
Note that while this "works" without -fPIC on x86 (or x86_64 in 32bit
mode, FWIW), it has a profound effect on the generated shared library
(search for "text relocations"; this and its advantages and
disadvantages have been explained several times on this list even).
In general, this depends on both the machine and the operating system
involved. And no, on Win32 you can't ignore the fact whether or not
you're creating a DLL, at least in the general case (search for data
imports/exports, for example).
There are systems, where it makes no difference while compiling, but
only when linking, but you did not mention AIX. ;-)
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: sh portability questions
* Akim Demaille wrote on Wed, Sep 28, 2005 at 01:36:11PM CEST:
>
> Thanks, I didn't know. How about this then?
> (
> foo=bar
> test_local () {
> local foo=foo
> }
> test_local
> test $foo = bar
> ) || local () {
> case $1 in
> *=*) eval "$1";;
> esac
>
> }
That does not test what you'd like to know (if local doesn't work in
test_local, foo won't be reassigned), and the logic is wrong.
I believ you can even fail if you know you can't handle the assignment
(and you also don't want to see the test failure):
(
test_local () {
#set -x
local lfoo=foo 2>/dev/null
foo=$lfoo
}
test_local
test -n "$foo"
) || local () {
case $1 in
*[$IFS]*)
echo "local assignments with white space not implemented" >&2
exit 1;;
*=*) eval "$1";;
esac
}
Tested with Solaris 9 sh and dtksh (the latter does not have `local').
But why not allow `local a=b c=d'?
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: A versionized variation on `lt_dlopen ()'
Hi Ralf, Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Can you give a pointer to the thread? I couldn't find it easily (i.e., > within one minute :) Probably because it's inappropriately entitled. ;-) It starts here: http://lists.gnu.org/archive/html/guile-user/2005-09/msg00061.html . And I tried to summarize the issues that may be relevant to `libltdl' there: http://lists.gnu.org/archive/html/guile-user/2005-09/msg00090.html . > Erm, I may be misunderstanding, but you actually have several libcs > lying around which you choose to load from (for other libraries, I'd > understand, but libc)? This question is of course independent of your > actual request. I meant "C library" in the general sense, i.e. a library written in C, unlike in "the GNU C library". > A couple of thoughts: For one, you'd need to use the .la files to open > the modules then (with the current functions, you can also open the > plain .so or whatever it's called). This is probably not a big > constraint for your use. For another, static linking (dlpreopening) of > more than one version of the module would not work, but that is nothing > new. For Guile and other plug-in-like usage patterns, we don't really care about ``dlpreopening'': the point is precisely to load things dynamically. Aside from that, why would we need the `.la' files to open a specific version of a library? Doesn't the library file name precisely reflect its interface/revision/age? In any case, whether `libltdl' needs to read a `.la' file in order to do the job is not something the user should worry about. > Other than that, it sounds like a reasonable idea to explore post-2.0. > I believe, though, you should use INTERFACE only to decide which one to > open; the function would then search for a module where INTERFACE lies > between CURRENT-AGE and CURRENT, and try to open that. If there are > multiple matches, I'm not sure what would be best: among modules > differing only in REVISION, obviously the highest would be best. > Other than that: Assuming that, with increasing CURRENT, CURRENT-AGE > would also be non-decreasing, it should probably select the one with the > highest CURRENT, I guess. (The CURRENT comparison would obviously have > higher precedence than the REVISION comparison.) Actually, the REVISION argument is optional: implicitly, you'd always prefer the highest as you said. So we can probably remove that parameter from the function. Then I guess choosing the interface with the highest CURRENT, provided that CURRENT - AGE <= INTERFACE, things should work fine. In fact, a more fine-grained API could be exposed, something along the lines of: /* Return an array of library files that implement interface INTERFACE. */ lt_dlfile *lt_matching_dl_files (const char *filename, unsigned interface, size_t *match_count); /* Open the dynamic library represented by FILE. */ lt_dlhandle *lt_dlopen_file (lt_dlfile *file); And then, a number of accessors, like: const char *lt_dlfile_file_name (const lt_dlfile *); unsignedlt_dlfile_interface (const lt_dlfile *); unsignedlt_dlfile_age (const lt_dlfile *); unsignedlt_dlfile_revision (const lt_dlfile *); With this, users could implement any policy they like. Does this sound reasonable? Thanks, Ludovic. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: postdeps empty on OpenBSD
On 2005-09-28, Jacob Meuser <[EMAIL PROTECTED]> wrote: > yes. I work with transcode (transcoding.org), which is a C program > that loads modules. some modules are written in C++. it works on > OpenBSD with the C++ modules linked to libstdc++. this is done > unconditionally in the Makefile.ams with 'modfoo_la_LIBADD = -lstdc++'. > I have not had a complaint about this method, but maybe no one's > actually built such a module for transcode while using a non-system > g++? I've just investigated this (on Linux) and it looks like libtool handles specifying -lstdc++ in LIBADD much better (I was using specifying it using "make LDFLAGS=-lstdc++" which is wrong now I come to think of it). Only one -lstdc++ appears in the actual link command, and it's after the correct -L. I need to test further but I think this will avoid problems with non-system GCC installations. It needs to be conditionalised on using GCC, but that's easy to do in configure as it already knows. It'll not cope with other compilers on platforms that might need this but I'm not aware of any currently. So I'm happier now, though I still tend to think libtool should just take care of this. Otherwise it's a trap waiting to catch anyone creating such modules - it'll all work fine until someone tries it on OpenBSD. If this isn't addressed in the libtool code, a brief discussion of the issue in the manual would be useful. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
forward porting UnixWare fixes to HEAD
I'm attempting to forward port the branch-1-5 UnixWare fixes to CVS HEAD. All of the old tests pass now but 2 of the new tests (18 & 19) fail. Pointers would be appreciated. ## -- ## ## Detailed failed tests. ## ## -- ## 18. template.at:23: testing ... template.at:24: test -n "$CXX" || (exit 77) template.at:74: $LIBTOOL --tag=CXX --mode=compile $CXX -I. $CPPFLAGS $CXXFLAGS -c -o alib.lo alib.cpp stderr: stdout: libtool: compile: CC -I. -g -c alib.cpp -KPIC -DPIC -o .libs/alib.o libtool: compile: CC -I. -g -c alib.cpp -o alib.o >/dev/null 2>&1 template.at:75: $LIBTOOL --tag=CXX --mode=compile $CXX -I. $CPPFLAGS $CXXFLAGS -c -o aclib.lo aclib.cpp stderr: stdout: libtool: compile: CC -I. -g -c aclib.cpp -KPIC -DPIC -o .libs/aclib.o libtool: compile: CC -I. -g -c aclib.cpp -o aclib.o >/dev/null 2>&1 template.at:76: $LIBTOOL --tag=CXX --mode=link $CXX $CPPFLAGS $CXXFLAGS -o libaclib.la aclib.lo stderr: stdout: libtool: link: ar cru .libs/libaclib.a .libs/aclib.o libtool: link: : .libs/libaclib.a libtool: link: creating libaclib.la libtool: link: ( cd ".libs" && rm -f "libaclib.la" && ln -s "../libaclib.la" "libaclib.la" ) template.at:77: $LIBTOOL --tag=CXX --mode=link $CXX $CPPFLAGS $CXXFLAGS -o libalib.la -rpath /usr/local/lib alib.lo libaclib.la stderr: prelink: INFO: C++ prelinker: executing: CC -c -I. -g -KPIC -DPIC -o.libs/alib.o alib.cpp stdout: libtool: link: (cd .libs/libalib.lax/libaclib.a && ar x /usr/local/src/gnu/libtool/build/tests/testsuite.dir/18/./.libs/libaclib.a) libtool: link: CC -G -h libalib.so.0 -o .libs/libalib.so.0.0.0 .libs/alib.o .libs/libalib.lax/libaclib.a/aclib.o libtool: link: (cd ".libs" && rm -f "libalib.so.0" && ln -s "libalib.so.0.0.0" "libalib.so.0") libtool: link: (cd ".libs" && rm -f "libalib.so" && ln -s "libalib.so.0.0.0" "libalib.so") libtool: link: (cd .libs/libalib.lax/libaclib.a && ar x /usr/local/src/gnu/libtool/build/tests/testsuite.dir/18/./.libs/libaclib.a) libtool: link: ar cru .libs/libalib.a alib.o .libs/libalib.lax/libaclib.a/aclib.o libtool: link: : .libs/libalib.a libtool: link: rm -fr .libs/libalib.lax .libs/libalib.lax libtool: link: creating libalib.la libtool: link: ( cd ".libs" && rm -f "libalib.la" && ln -s "../libalib.la" "libalib.la" ) template.at:78: $CXX -I. $CPPFLAGS $CXXFLAGS -c prog.cpp stderr: stdout: template.at:79: $LIBTOOL --tag=CXX --mode=link $CXX $CPPFLAGS $CXXFLAGS -o prog prog.$OBJEXT libalib.la stderr: Undefined first referenced symbol in file cq(T1) [with T1=int, return type=T1] ./.libs/libalib.so UX:ld: ERROR: Symbol referencing errors. No output written to .libs/prog stdout: libtool: link: CC -g -o .libs/prog prog.o ./.libs/libalib.so -R/usr/local/lib template.at:79: exit code was 1, expected 0 18. template.at:23: 18. simple template test (template.at:23): FAILED (template.at:79) 19. template.at:115: testing ... template.at:116: test -n "$CXX" || (exit 77) template.at:199: $CXX $CPPFLAGS $CXXFLAGS -c -o $main_o ../src/sub/main.cpp stderr: stdout: template.at:207: $LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS $CXXFLAGS -c -o lib/a.lo ../src/lib/a.cpp stderr: stdout: libtool: compile: CC -I../src/lib -I../src/lib2 -g -c ../src/lib/a.cpp -KPIC -DPIC -o lib/.libs/a.o libtool: compile: CC -I../src/lib -I../src/lib2 -g -c ../src/lib/a.cpp -o lib/a.o >/dev/null 2>&1 template.at:208: $LIBTOOL --tag=CXX --mode=compile $CXX $CPPFLAGS $CXXFLAGS -c -o lib2/b.lo ../src/lib2/b.cpp stderr: stdout: libtool: compile: CC -I../src/lib -I../src/lib2 -g -c ../src/lib2/b.cpp -KPIC -DPIC -o lib2/.libs/b.o libtool: compile: CC -I../src/lib -I../src/lib2 -g -c ../src/lib2/b.cpp -o lib2/b.o >/dev/null 2>&1 template.at:209: $CXX $CPPFLAGS $CXXFLAGS -c ../src/sub/main.cpp stderr: stdout: template.at:211: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o lib/liba.la lib/a.lo stderr: stdout: libtool: link: ar cru lib/.libs/liba.a lib/.libs/a.o libtool: link: : lib/.libs/liba.a libtool: link: creating lib/liba.la libtool: link: ( cd "lib/.libs" && rm -f "liba.la" && ln -s "../liba.la" "liba.la" ) template.at:212: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o lib2/libb.la lib2/b.lo stderr: stdout: libtool: link: ar cru lib2/.libs/libb.a lib2/.libs/b.o libtool: link: : lib2/.libs/libb.a libtool: link: creating lib2/libb.la libtool: link: ( cd "lib2/.libs" && rm -f "libb.la" && ln -s "../libb.la" "libb.la" ) template.at:213: $LIBTOOL --tag=CXX --mode=link $CXX $CXXFLAGS -o sub/main $main_o lib2/libb.la lib/liba.la stderr: prelink: INFO: C++ prelinker: executing: CC -c -I../src/lib -I../src/lib2 -g -osub/main.o ../src/sub/main.cpp Undefined first referenced symbol in file b(T1 &) [with T1=bs, return type=unsigned int] libb.a(b.o) UX:ld: ERROR: Symbol referencing errors. No output written to sub/main stdout: libtool:
