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 funct
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 posins
>>> "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
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
* 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 definiti
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, Max
>>> "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'
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.
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 informa
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.in
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 th
* 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
>
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
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 w
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: t
15 matches
Mail list logo
