On 3/13/2010 1:36 AM, Roger While wrote:
> gettext supplies libintl.la.
> That file requires libiconv.la.
That is what would be supported by a 'build-depends:' tag -- which is
exactly how that is handled by more powerful package management systems
like rpm, deb, apt, and even ebuild.
The origina
Charles Wilson wrote
Roger While wrote:
>
> gettext has a requirement on libiconv2.
> libiconv2 contains only the cygiconv dll and nothing else.
>
> OK. So we have a typical (libtooled) autoconf/automake configure which has
> a AM_GNU_GETTEXT([external]).
>
> Fine, the configure proceeds and prod
Roger While wrote:
>
> gettext has a requirement on libiconv2.
> libiconv2 contains only the cygiconv dll and nothing else.
>
> OK. So we have a typical (libtooled) autoconf/automake configure which has
> a AM_GNU_GETTEXT([external]).
>
> Fine, the configure proceeds and produces something like
On 3/11/2010 12:29 PM, Roger While wrote:
gettext has a requirement on libiconv2.
libiconv2 contains only the cygiconv dll and nothing else.
OK. So we have a typical (libtooled) autoconf/automake configure which has
a AM_GNU_GETTEXT([external]).
Fine, the configure proceeds and produces someth
gettext has a requirement on libiconv2.
libiconv2 contains only the cygiconv dll and nothing else.
OK. So we have a typical (libtooled) autoconf/automake configure which has
a AM_GNU_GETTEXT([external]).
Fine, the configure proceeds and produces something like -
checking for GNU gettext in lib
Ralf Wildenhues escribió:
Hi Jean-Philippe,
* Jean-Philippe Barrette-LaPierre wrote on Mon, Mar 21, 2005 at 06:31:14PM CET:
I'm experiencing problems with libtool 1.5.10 on Cygwin. I'm trying to
compile a project in:
/home/Jean-Philippe\ Barret/project/curlpp
*snip*
Yes. This is a problem, and I
Hi Jean-Philippe,
* Jean-Philippe Barrette-LaPierre wrote on Mon, Mar 21, 2005 at 06:31:14PM CET:
> I'm experiencing problems with libtool 1.5.10 on Cygwin. I'm trying to
> compile a project in:
>
> /home/Jean-Philippe\ Barret/project/curlpp
>
> In the 'examples' subdirectory, this problem occu
Jean-Philippe Barrette-LaPierre wrote:
I'm experiencing problems with libtool 1.5.10 on Cygwin. I'm trying to
compile a project in:
/home/Jean-Philippe\ Barret/project/curlpp
In the 'examples' subdirectory, this problem occurs:
[snip]
you can see that this is not correct. It didn't expanded the
I'm experiencing problems with libtool 1.5.10 on Cygwin. I'm trying to
compile a project in:
/home/Jean-Philippe\ Barret/project/curlpp
In the 'examples' subdirectory, this problem occurs:
-
Making all in examples
Boehne, Robert wrote:
Charles,
Since I haven't heard any complaints about this patch, I'll
assume the Cygwin people are OK with it, and check it in.
Thanks. Looks good here (cygwin), causes no problems on non-windows
(linux), and Earnie is happy with it on mingw. So go for it.
--Chuck
Charles,
Since I haven't heard any complaints about this patch, I'll
assume the Cygwin people are OK with it, and check it in.
Thanks,
Robert
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: rboehne
[dropped automake-patches from the CC: list; this discuession has long
since ceased involving automake]
This version addresses the two issues raised by Bruce: using the shell
that is appropriate for the platform, as determined during configure
(since that is how the libtool variable $SHELL is a
easy enough. But what's the best way to use "the shell"? Do a unquoted
replacement (<
Yes.
Somewhere, buried in the configury stuff is an environment
variable named something like, "CONFIG_SHELL". That's what
you want. If it is not available, then imitating the techniques
used to obtain it
Charles Wilson wrote:
>
> Bruce Korb wrote:
> > Earnie Boyd wrote:
> >
> >>This patch passes my test. What do we need to do to get this accepted
> >>into libtool cvs HEAD?
> >
> >
> >>>+ newargz[0] = xstrdup("/bin/sh");
> >>
> >
> > This may not be the shell and there is no point allocating it.
Bruce Korb wrote:
Earnie Boyd wrote:
This patch passes my test. What do we need to do to get this accepted
into libtool cvs HEAD?
+ newargz[0] = xstrdup("/bin/sh");
This may not be the shell and there is no point allocating it.
It is fine to use it from static memory.
Okay, the secon
Earnie Boyd wrote:
>
> This patch passes my test. What do we need to do to get this accepted
> into libtool cvs HEAD?
> > + newargz[0] = xstrdup("/bin/sh");
This may not be the shell and there is no point allocating it.
It is fine to use it from static memory.
--
Unsubscribe info: http:/
This patch passes my test. What do we need to do to get this accepted
into libtool cvs HEAD?
Earnie.
Charles Wilson wrote:
Okay, this version
1) puts lt-foo.c into .libs
2) "libtool --mode=clean" does the right thing --- cleans up foo,
foo.exe, .libs/foo.exe, .libs/lt-foo.c, plus whatever el
Okay, this version
1) puts lt-foo.c into .libs
2) "libtool --mode=clean" does the right thing --- cleans up foo,
foo.exe, .libs/foo.exe, .libs/lt-foo.c, plus whatever else it already
took care of.
3) lt-foo.c actually passes its own arguments to the shell wrapper -- it
didn't, before. (Oops)
Alexandre Duret-Lutz wrote:
Any way lt-foo.c could go into .libs/? Or just be erased after
foo.exe has been built? Maybe both?
I see no problems with either or both...but I'd rather keep lt-foo.c
around until 'make clean' (or libtool --mode=clean) time.
Also I if you don't move `foo' to `.l
>>> "Chuck" == Charles Wilson <[EMAIL PROTECTED]> writes:
[...]
Chuck> I left the shell wrapper where it was, in the build directory. When
Chuck> creating the shell wrapper, libtool will also create lt-${prog}.c and
Chuck> compile it using
Chuck> $run $LTCC -s -o ${prog}.exe lt-${prog}.c
C
Earnie Boyd wrote:
Charles Wilson wrote:
There are two places in ltmain.sh where the shell wrapper is directly
sourced. This doesn't work very well, because when both "foo" and
"foo.exe" exist, ". ./foo" ends up sourcing "foo.exe" -- which is bad.
This can be resolved by ``. ./foo.'' inste
Charles Wilson wrote:
There are two places in ltmain.sh where the shell wrapper is directly
sourced. This doesn't work very well, because when both "foo" and
"foo.exe" exist, ". ./foo" ends up sourcing "foo.exe" -- which is bad.
This can be resolved by ``. ./foo.'' instead for the cygwin/min
Alexandre Duret-Lutz wrote:
Chuck> Said "stub" executable would have to do ALL of the
Chuck> things the script does, and then pass that environment
Chuck> to its exec'ed target in .libs/ --
Maybe it could just exec() something like `/bin/sh .libs/foo.sh',
where `.libs/foo.sh' is the script wra
Charles Wilson wrote:
Hmmm...now there's a thought. Perhaps, perhaps...
Said "stub" executable would have to do ALL of the things the script
does, and then pass that environment to its exec'ed target in .libs/ --
does native windows provide an exec() command? Environment inheritance?
You'd
>>> "Chuck" == Charles Wilson <[EMAIL PROTECTED]> writes:
[...]
Chuck> 'Course, there's the whole cross-compiler issue (running
Chuck> on linux, building stuff intended for cygwin).
Yes. Sigh.
[...]
Chuck> Said "stub" executable would have to do ALL of the
Chuck> things the script does, a
Alexandre Duret-Lutz wrote:
Chuck> However, the Makefile target is "foo$(EXEEXT)" -- which
Chuck> isn't satisfied by the "foo" wrapper script, so 'make'
Chuck> keeps trying to create it.
Maybe I'm wrong, but my understanding is that wrapper scripts
are generated only when linking programs w
>>> "Chuck" == Charles Wilson <[EMAIL PROTECTED]> writes:
Chuck> There has been a long-standing problem with libtool on windows-ish
Chuck> platforms (cygwin, mingw, others?), in which libtool relinks exe's
Chuck> over and over and over, when the exe depends on a shared lib that is
Chuck> also
Charles Wilson wrote:
[cross posted. Please keep (at least) [EMAIL PROTECTED] in all
replies, especially as the @gnu.org mailserver has not been archiving
all messages]
There has been a long-standing problem with libtool on windows-ish
platforms (cygwin, mingw, others?), in which libtool rel
[cross posted. Please keep (at least) [EMAIL PROTECTED] in all replies,
especially as the @gnu.org mailserver has not been archiving all messages]
There has been a long-standing problem with libtool on windows-ish
platforms (cygwin, mingw, others?), in which libtool relinks exe's over
and over
*sigh*,
don't you just hate it when you only manage to work out what you have been
doing wrong minutes after posting to a public list (old precygwinpackages
aclocal files lying around) and making a fool of yourself.
Thanks for being there anyway :),
Daniel
p.s. I don't think aclocal should loo
sorry,
I've just noticed I was looking at the wrong cvs file and the sed stuff is
the same as in libtool cvs.
it's still a mystery to me why aclocal isn't picking up the
LT_AC_PROG_SED macro.
I get the same problem with dllhelpers-0.4.0/cxx_autotools so I know it
isn't the way my project is set
Hi,
I'm new to the list so I hope I haven't missed this being discussed already.
I've tried libtoolizing a project with the latest libtool-devel (20020202-1), but
after running
configure;make it aborts with the following error.
/bin/sh ../libtool --mode=compile g++ -DGLOBCONFPATH=\"/usr/local/e
32 matches
Mail list logo
