ar.dylib
Is it a known behavior ? If so, is it a bug ?
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Wed, 21 Apr 2010, Peter O'Gorman wrote:
On 04/21/2010 04:00 PM, Vincent Torri wrote:
Hey,
A guy mentioned that problem: on mac os x, a "standard" shared lib has
suffix name .dylib:
lib_LTLIBRARIES = libfoo.la --> libfoo.dylib
but with a "module"
-- Forwarded message --
Date: Fri, 23 Apr 2010 12:27:27 -0600
From: Eric Blake
To: Vincent Torri
Cc: autoc...@gnu.org
Subject: Re: use of shrext_cmds on mac os x
On 04/23/2010 12:09 PM, Vincent Torri wrote:
Hey,
on mac os x, shrext_cmds is defined like that:
shrext_cmds
Hey,
almost everything is in the subject. 2 weeks ago, there was a thread about
the release. So what is the status ?
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
ile a program for Windows CE (using cegcc) and
it works, now (well, it worked with the git version, so...)
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
ding these patches, I honestly have paid very little attention to
Windows fixes for libtool because I can't test them,
even if you install mingw cross toolchain on linux ? You can even test
Windows CE with cegcc on linux
Vincent Torri
and don't use them:
So I figured someone else w
erson
knowledgeable with WinCE, but that didn't happen. Oh well.
sorry, i didn't follow the thread. What is the problem with WinCE ?
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
e.org/gmane.comp.gnu.libtool.general/10794/focus=9769
To repeat the question: can I assume that the preprocessor symbol
_WIN32_WCE is defined for wince code, and usually not defined for
non-wince code?
Yes. _WIN32_WCE is defined only on Windows CE platform.
Vincent
On Tue, 24 Aug 2010, Ralf Wildenhues wrote:
Vincent, what about the other question I asked:
* Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST:
I Cc:ed you on the thread, was that wrong? How can we reach you?
Please answer this. Without somebody to ask about WinCE we *can
On Tue, 24 Aug 2010, Ralf Wildenhues wrote:
* Vincent Torri wrote on Tue, Aug 24, 2010 at 09:23:26PM CEST:
On Tue, 24 Aug 2010, Ralf Wildenhues wrote:
* Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST:
I Cc:ed you on the thread, was that wrong? How can we reach you?
Please
Hey,
I checked out libtool git 2 days ago and try to compile a library that
uses libole32 or libws2_32 with mingw-w64 (cross compilation on linux). I
get the usual message:
*** Warning: linker path does not have real file for library -lole32.
etc...
No problem with mingw. A guy from mingw-w
On Wed, 25 Aug 2010, David wrote:
On Martes 24 Agosto 2010 21:32:13 Ralf Wildenhues escribió:
* Vincent Torri wrote on Tue, Aug 24, 2010 at 09:23:26PM CEST:
On Tue, 24 Aug 2010, Ralf Wildenhues wrote:
* Vincent Torri wrote on Tue, Aug 24, 2010 at 08:25:12PM CEST:
I Cc:ed you on the thread
On Wed, 25 Aug 2010, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 25, 2010 at 06:46:31AM CEST:
I checked out libtool git 2 days ago and try to compile a library
that uses libole32 or libws2_32 with mingw-w64 (cross compilation on
linux). I get the usual message:
*** Warning
er [2]). We have not yets convinced cegcc
to create thumb code; we might look into this in the next weeks.
Our libs will be dayly built with some kind of buildbot. mingw, mingw-w64
and cegcc will be included. So it will also be a good test.
Vincent
Hey
Any news about the problem ?
Vincent Torri
On Wed, 25 Aug 2010, Vincent Torri wrote:
On Wed, 25 Aug 2010, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 25, 2010 at 06:46:31AM CEST:
I checked out libtool git 2 days ago and try to compile a library
that uses libole32 or
Hey
Any news about the problem ?
so, i have provided the libtool debug output [1] and provided the
informations that Charles Wilson asked me to give [2].
Any idea of the problem ?
Vincent Torri
[1] http://lists.gnu.org/archive/html/libtool/2010-08/msg00040.html
[2] http://lists.gnu.org
path where
libole32.a is located), there is no problem. That path is in the
pathsprinted with
x86_64-w64-mingw32-gcc -print-search-dirs
so it seems it's a libtool problem.
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
#define FOO_H
#if (defined _WIN32 || defined _WIN32_WCE) && !defined __GNUC__
_WIN32 is defined also On Windows CE if __GNUC__ is not defined (i.e.
microsoft tools are used in the Windows CE case). So it can be simplified.
Vincent Torri
# ifdef BUILDING_LIBFOO
# ifdef DLL_EXPORT
# defin
Hey
If the question at the bottom is related to libtool and not automake, tell
me and I'll forward the mail to the libtool ML.
* Vincent Torri wrote on Fri, Nov 05, 2010 at 04:56:55PM CET:
foo_SOURCES = bar1.c
if MY_COND
foo_SOURCES += bar2.cpp
else
foo_SOURCES += bar2.c
endif
One
Hey,
On Sat, 20 Nov 2010, Ralf Wildenhues wrote:
* Vincent Torri wrote on Sat, Nov 20, 2010 at 12:55:27AM CET:
Now, i've remarked a side effect. What I'm building is a shared lib
that is only opened by dlopen. So I pass --tag=disable-static to
pdf_la_LIBTOOLFLAGS. When using foo
On Fri, 18 Mar 2011, LRN wrote:
Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined
gcc now says something like this:
gcc.exe: error: unrecognized option '-no-undefined'
Before 4.6.0 it was possible to do that, and gcc said only this:
gcc.exe: unrecognized option '-no-undefin
On Sat, 19 Mar 2011, LRN wrote:
On 18.03.2011 23:51, Vincent Torri wrote:
On Fri, 18 Mar 2011, LRN wrote:
Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined
gcc now says something like this:
gcc.exe: error: unrecognized option '-no-undefined'
Before 4.
On Sat, 19 Mar 2011, LRN wrote:
On 19.03.2011 0:17, Vincent Torri wrote:
On Sat, 19 Mar 2011, LRN wrote:
On 18.03.2011 23:51, Vincent Torri wrote:
On Fri, 18 Mar 2011, LRN wrote:
Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined
gcc now says something like this
On Fri, 18 Mar 2011, Vincent Torri wrote:
On Fri, 18 Mar 2011, LRN wrote:
Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined
gcc now says something like this:
gcc.exe: error: unrecognized option '-no-undefined'
Before 4.6.0 it was possible to do that, and gcc
On Tue, Feb 7, 2012 at 3:03 AM, Bob Friesenhahn
wrote:
> On Tue, 7 Feb 2012, Jan Engelhardt wrote:
>
>> Much to my disappointment, I found that the newly-released libkmod v5
>> has made the following non-trivial change to its source tree, the latter
>> of which I want to bring to attention:
>
> [s
against Evil, -luuid is passed and I have
the warning above, and no DLL is produced. Even worse, some binaries
can not be compiled at all.
So I would like to know how I can forbid libtool to pass -luuid each
time I link against Evil.
thank you
Vincent Torri
_
another solution is to just kill the stupid .la file. There is
absolutely NO reason to add to the linker static libraries that are
ONLY used in my Evil library and that are not used elsewhere.
I think that it is the best solution
thank you
Vincent Torri
On Sat, Jul 21, 2012 at 10:34 AM, Peter
On Sat, Jul 21, 2012 at 2:41 PM, Peter Rosin wrote:
> On 2012-07-21 13:16, Vincent Torri wrote:
>> another solution is to just kill the stupid .la file. There is
>
> I don't think the .la file is stupid as it lists other important
> dependencies.
so what ? There
vas_engines_buffer_module_la_LDFLAGS = -no-undefined -module
-avoid-version
modules_evas_engines_buffer_module_la_LIBTOOLFLAGS = --tag=disable-static
I have looked at the code closely, but i can't see my error
Does someone know what the problem is ?
thank you
Vincent Torri
___
https://lists.gnu.org/mailman/listinfo/libtool
On Sun, Nov 4, 2012 at 11:29 AM, Vincent Torri wrote:
> Hey
>
> I have that error with my package. Usually, it's a problem of
> configuration and prefix. I know that I have solved that problem with
> a 'make clean', 'make' then 'make install'.
ons) or in the build system (that is, we should optimize the
build system so that non identical options are passed) ?
thank you
Vincent Torri
___
https://lists.gnu.org/mailman/listinfo/libtool
Here is below the list of arguments
Vincent Torri
libtool: compile: x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H
-I. -I.. -I../src/lib/efl -DPACKAGE_BIN_DIR=\"/opt/windows_64/bin\"
-DPACKAGE_LIB_DIR=\"/opt/windows_64/lib\"
-DPACKAGE_DATA_DIR=\"/op
On Wed, Mar 25, 2015 at 2:06 PM, Vincent Torri wrote:
> Here is below the list of arguments
>
> Vincent Torri
>
> libtool: compile: x86_64-w64-mingw32-gcc -std=gnu99 -DHAVE_CONFIG_H
> -I. -I.. -I../src/lib/efl -DPACKAGE_BIN_DIR=\"/opt/windows_64/bin\"
> -DPACKAG
Is this log file sufficient ?
Vincent Torri
On Wed, Mar 25, 2015 at 8:39 PM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:
> On Wed, 25 Mar 2015, Vincent Torri wrote:
>
>>
>> also it seems that on Linux, it's not the case (no such long list of
>> argu
file, without any luck
Does someone know what I should add to build mupdf *before* the link
of my module ?
thank you
Vincent Torri
___
https://lists.gnu.org/mailman/listinfo/libtool
Hello
I have a project which uses the autotools as build system (autoconf, +
automake + libtool).
is it possible to pass to the compiler a flag only when the static
library is built ?
i have tried to set lt_prog_compiler_static in configure.ac, with no luck
thank you
Vincent Torri
API __declspec(dllimport)
# endif
in the last #else, I don't know what to do to correctly manage MY_API
for my problem above
One solution would be : never compile 'lbfoo' as a static lib ("DLL
are good on Windows"), but I would like to support both static and
shared libraries.
Does someone know how to solve my issue ? (I hope I've been clear enough...)
thank you
Vincent Torri
shared library (know == having a macro to
distinguish shared lib and static lib)
Vincent
> Vincent Torri wrote:
> > Hello
> >
> > I contribute to an autotools project. The tree is :
> >
> > src/lib/libfoo <--- the library, with libfoo.h declaring the public s
On Tue, Aug 10, 2021 at 11:19 PM Nick Bowler wrote:
>
> On 2021-08-10, Vincent Torri wrote:
> [...]
> > As I have said, the problem is not the lib itself. There is no problem
> > with the lib. The problem is with the binary : when I compile it,
> > there is no way t
On Tue, Aug 10, 2021 at 10:38 PM Bob Friesenhahn
wrote:
>
> On Tue, 10 Aug 2021, Vincent Torri wrote:
> >>
> >> Perhaps better solution is use of -export-symbols.
> >
> > As I have said, the problem is not the lib itself. There is no problem
> > with the
On Wed, Aug 11, 2021 at 3:27 PM Bob Friesenhahn
wrote:
>
> On Wed, 11 Aug 2021, Vincent Torri wrote:
> >
> > The only solution I can see is : forcing to have only one specific
> > library. either static or shared, and throw an error if the wrong lib
> > is chosen at
or cmake) are using .dll.a for the
import lib
Note that having an import lib is not necessary, it's perfectly
possible to link against the DLL. The GNU linker allows this. See
https://sourceware.org/binutils/docs/ld/WIN32.html, section "direct
linking to a DLL" for more information.
Vincent Torri
l 2.2
(released 2 weeks ago) does not mention cegcc at all. Which is a bit
strange, imho.
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Fri, 14 Mar 2008, Bob Friesenhahn wrote:
On Fri, 14 Mar 2008, Vincent Torri wrote:
I would like to know when libtool supports the cegcc compiler. Right now,
libtool refuses to build shared libraries with that compiler. Also, there
are libtool patches for that compiler that were written
a web page that describes what to do, exactly ?
As I'm using mingw, i can test it too :)
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Fri, 14 Mar 2008, Bob Friesenhahn wrote:
On Fri, 14 Mar 2008, Vincent Torri wrote:
it's not my patch but here is what I've found:
http://lists.pld-linux.org/mailman/pipermail/pld-cvs-commit/Week-of-Mon-20070226/144657.html
and it's not in the libtool patch list. Should
As I'm using mingw, i can test it too :)
Good!
do you want the results with mingw ? (libtool 2.3a) Or do you already have
the results ?
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
of my lib, even if the dll
of those libraries (lwsock2, libiberty, etc...) do not exist. I recall
that with previous version (1.5.22 or maybe the one below), it can not.
Do you have some suggestions to fix this ?
thank you
Vincent Torri--- libltdl/m4/ltoptions.m4 2008-04-01 20:23:20.
2) With those patches, libtool can now create dll's with cegcc. But I have
that message when it tries to create the dll of my lib:
*** Warning: linker path does not have real file for library -lws2.
etc... saying it can not create the shared lib of my lib because the shared
version of libws
On Sat, 12 Apr 2008, Bob Friesenhahn wrote:
On Sat, 12 Apr 2008, Vincent Torri wrote:
2) With those patches, libtool can now create dll's with cegcc. But I have
that message when it tries to create the dll of my lib:
*** Warning: linker path does not have real file for library
4 files are correctly
copied and used.
So I would like to know why libtoolize does not copy those files with the
libpng library. And if someone knows why OBJDUMP is not defined, i would
be glad to know :)
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
Hey,
My problem is that ECHO and OBJDUMP are not defined when I'm configuring
libpng 1.2.26, while it's perfectly defined with another lib.
That typically means that you are using ltmain.sh from 2.2.x, but the
libtool.m4 macros from 1.5.x.
I'll try to investigate, then
I've grep'ed OBJDUM
, and one of the dev
would like to use a variable like ECHO_C or one of the other. Is it
reasonnable ? Is it compatible with former libtool ?
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Wed, 16 Apr 2008, Ralf Wildenhues wrote:
Hi Vincent,
* Vincent Torri wrote on Wed, Apr 16, 2008 at 07:03:48PM CEST:
My problem is that ECHO and OBJDUMP are not defined when I'm configuring
libpng 1.2.26, while it's perfectly defined with another lib.
That typically means th
On Fri, 18 Apr 2008, Ralf Wildenhues wrote:
* Vincent Torri wrote on Thu, Apr 17, 2008 at 03:59:07PM CEST:
On Wed, 16 Apr 2008, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Apr 16, 2008 at 07:03:48PM CEST:
My problem is that ECHO and OBJDUMP are not defined when I'm config
Maybe they just forgot to use AC_LIBTOOL_WIN32_DLL (or the LT_INIT
option win32-dll)?
omg, i didn't see that. Yes, it solves the problem
thank you very much
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl
or something else ?
Note that the library can be used on old distributions, which can not be
upgraded to support newer libtool.
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
Hey,
* Vincent Torri wrote on Thu, May 01, 2008 at 03:56:11PM CEST:
what is the best way to remove the checks of g++ and g77 when using
AM_PROG_LIBTOOL ?
define([AC_LIBTOOL_LANG_CXX_CONFIG], [:])dnl
define([AC_LIBTOOL_LANG_F77_CONFIG], [:])dnl
This one.
thank you
Note that the
use "#ifdef PIC" for shared and
"#ifndef PIC" for static code. That usually works.
I think that it will not work with MinGW. But then you can use DLL_EXPORT.
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
.
libtool explicitely removes the .gcno files in the 2nd case:
libtool: link: rm -fr .libs/eina_chained_mempool.gcno
does someone know why libtool remove the .gcno files. And of course, does
someone know a way to keep those files ?
thank you
Vincent Torri
_
On Sun, 31 Aug 2008, Ralf Wildenhues wrote:
Hello Vincent,
Thanks for the bug report.
* Vincent Torri wrote on Fri, Aug 29, 2008 at 05:38:59PM CEST:
I'm compiling two libraries with the options -fprofile-arcs
-ftest-coverage passed to gcc.
The first one has .gcno files in his dire
Hey,
* Vincent Torri wrote on Fri, Aug 29, 2008 at 05:38:59PM CEST:
I'm compiling two libraries with the options -fprofile-arcs
-ftest-coverage passed to gcc.
The first one has .gcno files in his directory and the .libs sub
directory. The second one has .gcno files in his directory bu
link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/bin'
libtool: link: Continuing, but uninstalled executables may not work.
I've never seen those message. Again, I would like to know what is
happening.
thank you
Vincent Torri
__
link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/bin'
libtool: link: Continuing, but uninstalled executables may not work.
I've never seen those message. Again, I would like to know what is happening.
No idea where I should look
e is right, what should I do to remove those "dependencies" ? (flag to
pass in a variable in my Makefile.am, or something like that)
I paste the Makefile.am that is used to compile the eet binary below
thank you
Vincent Torri
### beginning of Makefile.am
MAINTAINERCLEANFILES = Make
Hey,
Sorry, Ralf, i've just deleted your answer. It was embedded in a lot of
spams... I paste it below.
Hello Vincent,
* Vincent Torri wrote on Sun, Sep 28, 2008 at 01:04:44PM CEST:
eet_LDADD = $(top_builddir)/src/lib/libeet.la
Hence when I call objdump -p on my eet binary,
On Mon, 29 Sep 2008, Ralf Wildenhues wrote:
* Vincent Torri wrote on Mon, Sep 29, 2008 at 09:47:02PM CEST:
* Ralf Wildenhues wrote:
* Vincent Torri wrote on Sun, Sep 28, 2008 at 01:04:44PM CEST:
2) If he is right, what should I do to remove those "dependencies" ?
(flag to
link: Could not determine host path corresponding to
libtool: link: '/home/torri/local/opt/cegcc/bin'
libtool: link: Continuing, but uninstalled executables may not work.
I've never seen those message. Again, I would like to know what is happening.
No idea where I should look in ltmain.sh
Hey,
* Vincent Torri wrote on Fri, Oct 03, 2008 at 08:52:54AM CEST:
I'm cross-compiling using the cegcc toolchain and the mingw32ce
compiler. I have 2 problems:
1) I use Windows sockets, hence i have to link against libws2 and I
pass -lws2. I have the following (usual...) me
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
* Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST:
If with those settings, things still fail, you should surround the
func_win32_libid code in your libtool script with 'set -x', 'set +x'
and look at the commands c
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
* Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST:
If with those settings, things still fail, you should surround the
func_win32_libid code in your libtool script with 'set -x', 'set +x'
and look at the commands c
On Sun, 5 Oct 2008, Vincent Torri wrote:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
* Vincent Torri wrote on Sun, Oct 05, 2008 at 08:00:15PM CEST:
If with those settings, things still fail, you should surround the
func_win32_libid code in your libtool script with 'set -x', &#
that these 2 calls must be guarded and something else
should be displayed when migw32ce is used.
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
path':
./.libs/lt-suite.c:931: warning: passing argument 1 of 'lt_extend_str'
makes pointer from integer without a cast
arm-mingw32ce-strip: './suite.exe': No such file
About the errno problem, I've sent a mail about that.
There is also a problem with Windows CE: t
On Tue, 7 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote:
2) 2nd qestion: I have the following message from libtool (which
On Wed, 8 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
On Tue, 7 Oct 2008, Roumen Petrov wrote:
Vincent Torri wrote:
Hey,
Even if i'm still waiting for an answer about the func_win32_libid()
function, here is the 2nd problem:
On Sun, 5 Oct 2008, Ralf Wildenhues wrote
On Wed, 8 Oct 2008, Roumen Petrov wrote:
Libtool try to convert path from build system to the path from host
system.
So, where and how can I correct that in ltmain.sh ?
any idea ?
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo
dummy.o]: .text
t
that's all.
Should I provide more informations ?
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
where i should look in ltmain.sh, so that i can least try to find that
workaround myself.
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Mon, 27 Oct 2008, Ralf Wildenhues wrote:
It would help if you posted, for a library where this fails, the output
of the './libtool --mode=link' line with --debug added as first
argument;
the command is:
/bin/sh ../../../libtool --debug --tag=CC --mode=link arm-mingw32ce-gcc
-g -O2 -no
On Mon, 27 Oct 2008, Ralf Wildenhues wrote:
* Vincent Torri wrote on Mon, Oct 27, 2008 at 11:23:34PM CET:
/bin/sh ../../../libtool --debug --tag=CC --mode=link arm-mingw32ce-gcc
-g -O2 -no-undefined -Wl,--enable-auto-import -version-info 0:1:0
-L/home/torri/local/wince/lib -L/home/torri
milar patch for Windows CE ?
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
installed help2man, there is no problem. Maybe
configure should check the availability of help2man and the doc should be
built accordingly.
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
path where the process is launched.
* _spawnv()
i don't know any simple way to fake that function. Maybe one should add
another test in the 'host' case for that specific compiler which wo do
nothing (in that case, one can remove the #ifndef in the c
Hey,
* Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST:
libtool call:
/bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2
-Wl,--enable-auto-import -L/home/torri/local/wince/lib
-L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o
know as i don't know the purpose of that function.
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
2_DLL just before. This way is deprecated
If you use LT_INIT, pass win32-dll to it
In both case, you have to pass -no-undefined to libtool (during linking).
See http://www.gnu.org/software/libtool/manual/libtool.html#LT_005fINIT
regards
Vin
Hey,
* Vincent Torri wrote on Tue, Oct 07, 2008 at 05:30:24PM CEST:
libtool call:
/bin/sh ../../libtool --tag=CC --mode=link arm-mingw32ce-gcc -g -O2
-Wl,--enable-auto-import -L/home/torri/local/wince/lib
-L/home/torri/local/opt/cegcc/lib -o suite.exe suite.o test_memcpy.o
That's all. WHY does libtool does not want to
do so ? Is there a way to forbid libtool executing that wrapper ? like
-do-not-exec-the-stupid-wrapper
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
c-the-stupid-wrapper
It is just a warning. Is there a real issue ?
the issue is that 'make install' installs no executables at all.
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
ot precise enough. So:
1) with the host i586-mingw32msvc, I have the warnings and the
installation succeeds
2) with the host mingw32ce, I have the warnings (and some errors I already
mentioned) and the installation fails
Vincent Torri
___
http://lists
command, and execute it with --debug as well, and post that,
too.
maybe the issues i have reported in that mail:
http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html
should be fixed first
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
e.c:660:
undefined reference to `getcwd'
/tmp/cchXYNpc.o: In function `main':
/home/torri/tmp/svnroot_wince/e17/proto/evil/src/bin/./.libs/lt-evil_suite.c:484:
undefined reference to `_spawnv'
collect2: ld returned 1 exit status
arm-mingw32ce-strip: './evil_suite.exe': No such
On Wed, 21 Jan 2009, Charles Wilson wrote:
Vincent Torri wrote:
here is a reminding of something that i reported 2 months ago: (see
http://lists.gnu.org/archive/html/libtool/2008-11/msg00147.html).
I recall the facts: when using the mingw32ce compiler,
func_emit_cwrapperexe_src() fails
ibtool 2.2.*
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Thu, 16 Apr 2009, Ralf Wildenhues wrote:
Hello Vincent,
* Vincent Torri wrote on Thu, Apr 16, 2009 at 01:04:00PM CEST:
I know that libtool 1.5.2* is a very old version, not maintained anymore,
but i would like to know if the problem that I have is related to that
version or not. I cross
.
Is there a reason why libtool still uses g++ to create the DLL ?
if you need more informations (configure.ac or Makefile.am files), tell me
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
Hey,
* Vincent Torri wrote on Sat, Apr 18, 2009 at 09:45:24AM CEST:
i have written a library which can be compiled for windows xp or windows
ce. The source files are only C files with windows ce, and there is a c++
file with windows xp.
I assume that this C++ file is added with an Automake
On Sat, 18 Apr 2009, Vincent Torri wrote:
Hey,
Anyway, you
can work around it by setting foo_LINK. Here's an example.
ok, so it's just a matter of using the correct link options
another question related to that. I have that following code:
libevil_la_LDFLAGS = -no-und
On Sat, 18 Apr 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Sat, Apr 18, 2009 at 07:13:11PM CEST:
On Sat, 18 Apr 2009, Vincent Torri wrote:
Anyway, you can work around it by setting foo_LINK.
ok, so it's just a matter of using the correct link options
another question re
1 - 100 of 123 matches
Mail list logo
