* Ralf Wildenhues wrote on Wed, May 18, 2011 at 09:13:32PM CEST:
> * Erik de Castro Lopo wrote on Tue, May 17, 2011 at 12:21:35PM CEST:
> > The problem is the generation of a test program in a sub-directory.
> > The test program that should be generated is:
> >
> > G72x/g72x_test.$(EXEEXT)
> >
Hello Erik,
* Erik de Castro Lopo wrote on Tue, May 17, 2011 at 12:21:35PM CEST:
> I have a project that uses autoconf/automake/libitool etc. The
> build system worked as recently as a month ago for both native
> compiles on linux and cross compiles from linux to windows.
> Unfortnately, linux to
Hi all,
I have a project that uses autoconf/automake/libitool etc. The
build system worked as recently as a month ago for both native
compiles on linux and cross compiles from linux to windows.
Unfortnately, linux to wndows cross compiles suddenly stopped
working with libtool 2.4 from Debian testi
On Thu, Oct 25, 2007 at 05:39:47PM -0700, Brian Dessent wrote:
> > Info: resolving _z_errmsg by linking to __imp__z_errmsg (auto-import)
>
> These are completely normal if you are porting software that does not
> explicitly dllimport symbols. They are not errors.
I supposed so.
> There is not en
Robert Schwebel wrote:
> Info: resolving _deflate_copyright by linking to __imp__deflate_copyright
> (auto-import)
> Info: resolving __dist_code by linking to __imp___dist_code (auto-import)
> Info: resolving __length_code by linking to __imp___length_code (auto-import)
> Info: resolving _z_errms
Hi,
We are currently trying to cross compile wireshark to mingw with the
standard automake cross procedure. Quite some uggly hacks later, we are
now able to compile everything, but the final linker stage goes wrong.
The final linker call outputs things like this one:
--8<--
Info:
* Brendon Costa wrote on Mon, Jun 12, 2006 at 10:46:29AM CEST:
> Duft Markus wrote:
> >
> > Do you want to get it to work with the MinGW GCC, or with the MSVC
> > toolchain (i.e. cl.exe, link.exe etc...) ? This makes a big
> > difference, since libltdl is really useless with the MS toolchain.
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duft Markus wrote:
> Hi!
>
> Do you want to get it to work with the MinGW GCC, or with the MSVC toolchain
> (i.e. cl.exe, link.exe etc...) ? This makes a big difference, since libltdl
> is really useless with the MS toolchain.
>
> I think we allrea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Dessent wrote:
> No, your example was flawed because it did not pass -no-undefined, which
> means you get static libraries unconditionally. If you fix that, then
> libtool builds both shared and static versions of the library, and it
> successfu
Hello Markus,
* Duft Markus wrote on Mon, Jun 12, 2006 at 08:31:37AM CEST:
> Hmmm.. Ok, maybe i'm wrong with this, but at least i'm successfully
> working with about 600mb sources on interix with the ms toolchain with
> libtool but without libltdl, and it works without any problems (static
> and a
)
Regards, markus
-Ursprüngliche Nachricht-
Von: Ralf Wildenhues [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 12. Juni 2006 08:28
An: Duft Markus
Cc: Brendon Costa; libtool@gnu.org
Betreff: Re: libtool + MinGW
* Duft Markus wrote on Mon, Jun 12, 2006 at 08:24:00AM CEST:
>
> Do you want t
* Duft Markus wrote on Mon, Jun 12, 2006 at 08:24:00AM CEST:
>
> Do you want to get it to work with the MinGW GCC, or with the MSVC
> toolchain (i.e. cl.exe, link.exe etc...) ? This makes a big
> difference, since libltdl is really useless with the MS toolchain.
This statement isn't true in gener
Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Brendon Costa
Gesendet: Freitag, 9. Juni 2006 15:58
An: libtool@gnu.org
Betreff: libtool + MinGW
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi All,
As part of my quest to get libtool and MSVC working together, i
Brendon Costa wrote:
> Question: Does libtool 1.5.22 for MinGW support shared libraries and
> using DLOpened modules without dlpreopening?
Of course it supports shared libraries.
> If so in the example i gave before for a shared library was created
> using ar cru and not g++ -shared and was link
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ralf Wildenhues wrote:
> * Brendon Costa wrote on Fri, Jun 09, 2006 at 03:58:24PM CEST:
>> As part of my quest to get libtool and MSVC working together, i thought
>> i would first get libtool working with an example project on a few other
>> systems fi
* Brendon Costa wrote on Fri, Jun 09, 2006 at 03:58:24PM CEST:
>
> As part of my quest to get libtool and MSVC working together, i thought
> i would first get libtool working with an example project on a few other
> systems first.
Are you building upon the efforts of Peter Ekberg? Because if you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Dessent wrote:
> I'm not sure why you are getting the link errors about duplicated
> symbols, but your testcase in general is not doing what you think it's
> doing. You'll note that there is not a DLL created anywhere, and this
> is because you
Brendon Costa wrote:
> Would someone be able to have a look at the script file and let me know
> what i am doing wrong?
I'm not sure why you are getting the link errors about duplicated
symbols, but your testcase in general is not doing what you think it's
doing. You'll note that there is not a
I am currently using a development version of libtool which is about
six months old.
Under MinGW I am seeing behavior I do not understand when executing
the program via libtool's wrapper script. The strange behavior only
occurs when a modules-enabled build is involved and only if the
program is e
I am tidying and explaining my patch bit by bit. Here is the second chunk.
A libtool expert needs to check Hunk 2. See my comments below
Once section 1 and 2 have been pronounced OK, they can be commited, as they are
just groundwork for the main chunk of the patch, and can stand alone.
Max.
--
I am tidying and explaining my patch bit by bit. Here is the first chunk,
including the merge of the Cygwin-local changes to libtool (not done by me).
Hunks 1 & 2 should be fine. Hunk 3 is purely the addition of a comment, which
you may prefer to leave out on the grounds of unnecessary bloat.
Eit
On Sun, Sep 23, 2001 at 05:44:40PM +0200, Guido Draheim wrote:
> "Gary V. Vaughan" wrote:
> >
> > On Sat, Sep 22, 2001 at 11:15:43PM +0300, Tor Lillqvist wrote:
> > > The chance of a Unix system having
> > > directory names containing semicolons is practically nil, isn't it?
> >
> > Yup. It is
"Gary V. Vaughan" wrote:
>
> On Sat, Sep 22, 2001 at 11:15:43PM +0300, Tor Lillqvist wrote:
> > The chance of a Unix system having
> > directory names containing semicolons is practically nil, isn't it?
>
> Yup. It is possible technically, but anyone who uses semicolons in
> PATH has got to exp
On Sat, Sep 22, 2001 at 11:15:43PM +0300, Tor Lillqvist wrote:
> The chance of a Unix system having
> directory names containing semicolons is practically nil, isn't it?
Yup. It is possible technically, but anyone who uses semicolons in
PATH has got to expect trouble, no?
Cheers,
Gary.
> > b) why is it just bigcaps drive-letters?
>
> Ditto. Although I guess this comes from the spec file, so maybe more
> care _is_ needed after all?
It doesn't come from the specs file, remember that the mingw gcc can
be installed freely in any location, and the specs file isn't edited
when
On Sat, Sep 15, 2001 at 05:06:54PM +0200, Guido Draheim wrote:
> Tor Lillqvist wrote:
> >
> > -- Small improvement for mingw-hosted tool support (while still
> > running libtool on cygwin). In that case PATH_SEPARATOR is ':', but
> > gcc -print-search-dirs still prints its search path with ';' as
Tor Lillqvist wrote:
>
> -- Small improvement for mingw-hosted tool support (while still
> running libtool on cygwin). In that case PATH_SEPARATOR is ':', but
> gcc -print-search-dirs still prints its search path with ';' as
> separator.
>
>yes,mingw*)
> library_names_spec='${libname}`e
Hi,
Here is a patch to libtool with:
-- Small improvement for mingw-hosted tool support (while still
running libtool on cygwin). In that case PATH_SEPARATOR is ':', but
gcc -print-search-dirs still prints its search path with ';' as
separator.
-- Add support for .rc files (Windows resource fil
28 matches
Mail list logo
