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
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
> &g
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 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
or 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
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
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
ck
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
) 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=\/opt/windows_64/share/ethumb\
-DPACKAGE_BUILD_DIR
On Wed, Mar 25, 2015 at 2:06 PM, Vincent Torri vincent.to...@gmail.com 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\
-DPACKAGE_LIB_DIR=\/opt
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
arguments), while on Windows, it is. So maybe
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 vincent.to...@gmail.com 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'. But it's not sufficient.
First
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 p...@lysator.liu.se 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 is a HUGE problem
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
___
https
On Tue, Feb 7, 2012 at 3:03 AM, Bob Friesenhahn
bfrie...@simple.dallas.tx.us 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
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
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
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.6.0
_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
# define LIBFOO_SCOPE extern __declspec (dllexport
(that is the 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
/build/root/mingw/lib/
(*) I assume you're using a native non-multilib toolchain (you didn't
specify).
It's native (I use the linux version of the mingw-w64 toolchain). But I
don't know what multilib means :-)
thank you
Vincent Torri
what you do, with just an additional else in DLL_EXPORT case, without
your #ifndef.
works fine with gcc (mingw, mingw-w64, mingw32ce) and vc++
hth
Vincent Torri
On Thu, 16 Sep 2010, Ralf Wildenhues wrote:
Hello Chuck and Peter,
do I see it right that there are no pending w32 patches for before
the next Libtool release any more (after the one I just acked)?
there is a mingw-w64 issue i have mentioned 2 times, with a debug log of
libtool.
Vincent
On Thu, 16 Sep 2010, Ralf Wildenhues wrote:
Hello Vincent,
* Vincent Torri wrote on Thu, Sep 16, 2010 at 09:52:39PM CEST:
On Thu, 16 Sep 2010, Ralf Wildenhues wrote:
do I see it right that there are no pending w32 patches for before
the next Libtool release any more (after the one I just
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
} in #(
yes)
if test $GCC = yes; then
- lt_sysroot=`$GCC --print-sysroot 2/dev/null`
+ lt_sysroot=`$CC --print-sysroot 2/dev/null`
what is the interest of testing $GCC if you use $CC ?
Vincent Torri
fi
;; #(
/*)
diff --git a/tests/sysroot.at b/tests/sysroot.at
index c0ac6d1
]). 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 Torri
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
/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 Torri
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
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
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 was taking care
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
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
-- Forwarded message --
Date: Fri, 23 Apr 2010 12:27:27 -0600
From: Eric Blake ebl...@redhat.com
To: Vincent Torri vto...@univ-evry.fr
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
? 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:
pkg_LTLIBRARIES = bar.la
bar_la_LDFLAGS
pthread, even if the binary itself does not use pthread directly ?
If you compile a trivial hello-world type program with '-v -pthread', does
the output show that an alternate libc or a threads library is being used?
I'll ask the guy who reported the problem
Thank you
Vincent Torri
-pthread -pthread
Is there a known problem with OpenBSD and -pthread, using libtool 1.5.26 ?
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Mon, 28 Dec 2009, Bob Friesenhahn wrote:
On Mon, 28 Dec 2009, Vincent Torri wrote:
When passing -pthread to my_lib_LDFLAGS and my_lib_CFLAGS in Makefile.am,
on OpenBSD (libtool 1.5.26), the linker does not have -lpthread, but just
-pthread :
Is -pthread not sufficient to do
On Sun, 8 Nov 2009, Bob Friesenhahn wrote:
On Sat, 7 Nov 2009, Vincent Torri wrote:
The link command is:
/bin/sh ../../../libtool --tag=CC --mode=link gcc -o emotion.la -rpath
-module -avoid-version emotion.lo ../../../src/lib/libethumb.la
-L/usr/local/lib -L/usr/X11R6/lib -levas
that no value is passed to rpath (what is after it is -module)
I don't know which information or file i should provide to give more hints
about the problem.
does someone have an idea ?
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
read the same as X.Y.Z
if i'm not mistaken, you can compute le libtool versioning from the
version of the software. If the version of the software is X.Y.Z, the
libtool version can be computed with : (X+Y).Z.Y
Of course the version of the software must be correctly updated.
Vincent Torri
On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 12, 2009 at 12:33:47AM CEST:
if i'm not mistaken, you can compute le libtool versioning from the
version of the software. If the version of the software is X.Y.Z,
the libtool version can be computed with : (X+Y
On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 12, 2009 at 07:15:16AM CEST:
On Wed, 12 Aug 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Wed, Aug 12, 2009 at 12:33:47AM CEST:
if i'm not mistaken, you can compute le libtool versioning from the
version
compilation command ? A bit like cmake or waf.
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Wed, 10 Jun 2009, Vincent Torri wrote:
On Tue, 9 Jun 2009, Bob Friesenhahn wrote:
See http://lists.gnu.org/archive/html/automake/2009-05/msg00093.html for
the announcement.
The release was hastened in order to shave some lifetime from 'shave'.
Another related question: would
? Something like:
AM_INIT_AUTOMAKE(1.6 dist-bzip2)
if test $AUTOMAKE_CURRENT_VERSION -ge 1.1 ; then
AM_SILENT_RULES
fi
I think that i can get it by using sed on what is returned by 'automake
-version', but i would prefer an autotools way
thank you
Vincent Torri
Hey,
here is a patch that does not generate the c wrapper when cegcc hosts
(cegcc and mingw32ce) are used.
regards
Vincent Torridiff --git a/ChangeLog b/ChangeLog
index e278549..cb6ac68 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2009-06-07 Vincent Torri vtorri at univ-evry
On Sun, 7 Jun 2009, Ralf Wildenhues wrote:
* Vincent Torri wrote on Sun, Jun 07, 2009 at 08:33:42AM CEST:
1) remove the wrapper for cegcc and mingw32ce host (see the patch i sent)
2) remove the #ifndef __MINGW32CE__ the in windows wrapper, they are
useless.
Thank you for explaining. I
Hey,
* Vincent Torri wrote on Wed, Jun 03, 2009 at 09:32:50PM CEST:
Does there exist a simulator for wince? Even if not now, can there
exist one at some point? In that case, we should strive to not make
things harder for that setup.
there is a simulator for Windows CE that can be run
__MINGW32CE__
that are in the wrapper for cygwin / mingw
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, 2 Jun 2009, Bob Friesenhahn wrote:
On Tue, 2 Jun 2009, Vincent Torri wrote:
So, the first line is the link of my real binary (evil_suite.exe), then the
compilation of the c wrapper is done and is failing. If I run make install,
evil_suite.exe is not installed.
This is expected
answer.
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
this
possible.
So what should be done to disable the execution of the c wrapper on that
platform only ?
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
.
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-undefined -Wl
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 related
.*
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
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
:
undefined reference to `_spawnv'
collect2: ld returned 1 exit status
arm-mingw32ce-strip: './evil_suite.exe': No such file
../../libtool: line 8551: $func_ltwrapper_scriptname_result: ambiguous
redirect
thank you
Vincent Torri
___
http://lists.gnu.org
) 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.gnu.org/mailman/listinfo
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
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
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
Vincent Torri
___
http
of that function.
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
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
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
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 case the host is
mingw*)
Vincent Torri
-f $1 | $SED -e '10q' 2/dev/null |
- $EGREP 'file format pe-i386(.*architecture: i386)?' /dev/null ; then
+ $EGREP 'file format pe-i386(.*architecture: i386)?|file format pe-x86-64'
/dev/null ; then
may I recall that I am waiting a similar patch for Windows CE ?
thank you
Vincent
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
t
that's all.
Should I provide more informations ?
thank you
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo/libtool
On Thu, 9 Oct 2008, Ralf Wildenhues wrote:
Hello Vincent,
* Vincent Torri wrote on Thu, Oct 09, 2008 at 07:02:56AM CEST:
here is a patch that removes compilation errors with mingw32ce because it
does not support the errno system.
Is __MINGW32CE__ even defined for that system? Because
hey,
here is a patch that removes compilation errors with mingw32ce because it
does not support the errno system.
I don't know if it is the best solution, but it is working for me. So if
you have a better solution, feel free to modify that patch
thank you
Vincent Torridiff --git
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:
2
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
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
': No such file
About the errno problem, I've sent a mail about that.
There is also a problem with Windows CE: there is no environment variables
in that OS, hence no getenv / setenv functions.
Vincent Torri
___
http://lists.gnu.org/mailman/listinfo
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 called, when 'libtool
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...) message
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 called, when 'libtool
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 called, when 'libtool
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', 'set +x
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 to fix those messages ?
thank you
Vincent Torri
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, i get
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 pass in a variable
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 to fix those messages ?
thank you
Vincent Torri
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
___
http
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
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 directory
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
___
http://lists.gnu.org/mailman
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
1 - 100 of 121 matches
Mail list logo
