I did lately try out the newest cvs version of the autotools, and
I was amazed that libtool can not create dlls with it. I had been
using the libtool-version from the libsdl.org project, and it did
work fine. Sam told me, that his changed were not merged into the
original libtool project. That's
Alexandre Oliva wrote:
On Apr 26, 2001, Guido Draheim [EMAIL PROTECTED] wrote:
I did just need to change a single line in ltmain.sh which
enabled me afterwards to actually *build* a dll.
Looks like you were not using -no-undefined when creating the
library. This is required to build
Guido Draheim wrote:
from that I'd say libtool knows that CC has created a pfe.exe but
the automake-rules/vardefs expect a builddir/pfe.exe too. A copy
of builddir' pfe to pfe.exe does indeed work. Who's to blame,
libtool or automake?
It is libtool's fault - even that the final link-line
Hi libtool'ers,
using a remote-login account on a darwin-1.3 machine, I did
currently looking for support of sharedlib/dlopen support for
this platfrom, but I am a bit confused a the moment, so may
be you could enlighten me.
the current libtool (1.4 (1.920 2001/04/24 23:26:18))
does let us
This is not restricted to borland compilers, there are quite
some C-compilers on unix-systems that quite some people like
to see supported, however most of the autotools developers
do live in a quite gnu'ish/gcc'ish environment, and every now
and then, a gmake'ish/gcc pecularity slips in that
Perhaps the problem will go away when we have a binary ltmain in a couple of
releases?
In the mean while, I think the only workaround is to not use '~' in pathnames.
*sigh* ... actually, I just wonder why it did
work in 1.3.x and it must be left as is in 1.4 - well,
then again,
(whatever that is anyway)
Guido Draheim wrote:
no further comment needed, here's the output (libtool 1.4, 1.920)
any ideas?
/bin/sh ./libtool --mode=link i386-mingw32msvc-gcc -D_export=__dllexport -W,-E
-W,--warn-common -o mforth.la -rpath
/programs/pfe/pfe -export-dynamic -module -avoid
apropriatly. It is interesting that we break windows'
name-conventions for libraries, happily adding lib before
the basename - am I right that this has changed from
former tools targetting windows?
okay, need some sleep now, bye, guido
Guido Draheim wrote:
As everyone knows, compiling a win-dll
Gary V. Vaughan wrote:
On Wednesday 20 June 2001 10:58 am, Guido Draheim wrote:
Anyway, libtool.m4 and libtool-content are out of sync in this case,
it is clearly buggy, don't you think Gary? ;-)
The last time I used the impgen code in libtool, it worked fine for me.
However, I must
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 expect
[EMAIL PROTECTED] wrote:
On Tue, Sep 11, 2001 at 12:14:42PM -0700, Bruce Korb wrote:
It seems I need to be able to build both 32 and 64 bit
libraries. Since nobody seems to have anything to do,
maybe we can add this to our copious spare time activities:
Construction of multiple
Max Horn wrote:
OK, I think I just found out that this is the reason modules are not
built right on darwin:
# Commands used to build and install a shared archive.
archive_cmds=\$CC \$(test \\x\$module\\ = xyes echo -bundle ||
echo -dynamiclib) \$allow_undefined_flag -o \$lib \$libobjs
Es schrieb Kevin Ryde:
I tried using the Debian packaged mingw32 cross-compiler to build a
windows DLL with cvs libtool but didn't at first realize I had to set
HOST_CC manually. Perhaps libtool could probe for a build system
compiler itself when it needs one (for impgen.c).
I don't
please be a bit more specific, what cross compiler do you use?
Otherwise, 2.95.x crosscompiling does work smoothly for a lot of
platforms under my hands, but I did not check 3.0.x so far. What
version is that libtool in gcc 3.x. I guess it is not the fault
of libtool as seen in cvs, but feel
Es schrieb H . J . Lu:
On Wed, Oct 31, 2001 at 08:18:28PM +0100, Guido Draheim wrote:
please be a bit more specific, what cross compiler do you use?
Otherwise, 2.95.x crosscompiling does work smoothly for a lot of
Does 2.95.x even use libtool?
yupp, but I was amazed to see it calls
Es schrieb H . J . Lu:
The problem I am running into is kde 3.0-alpha1. Yes, I am cross compiling
kde from RedHat 7.1/x86 to a different Linux arch. On RedHat 7.1/x86,
# ls -l /usr/lib/libjpeg.*
-rw-r--r--1 root root 165144 Dec 11 2000 /usr/lib/libjpeg.a
-rwxr-xr-x1
Es schrieb Guido Draheim:
a patch like the following. I did not test it even in a single run,
but one might use it as a guideline.
*bg* ... spot the typo ;-)
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Torok-1, Maria wrote:
Anything you could tell me regarding 32-bit and 64-bit versions of automake,
make, and m4 would also be appreciated!
[..]
E-mail: [EMAIL PROTECTED]
Torok-1, Maria wrote:
We're currently using GNU libtool v1.4 on Solaris 2.6,
... before you flood the mailing-list,
Es schrieb Jon Leichter:
#ifdef DLL_EXPORT
# define EXTERN extern __declspec(dllexport)
#else
# define EXTERN extern
#endif
I am sure everyone who had been compiling a dll had seen this
and they have been hit by the declspec-problems that
Es schrieb Jon Leichter:
Cygwin sets this variable to the global default:
sys_lib_search_path_spec=/lib /usr/lib /usr/local/lib
MinGW executes the following command:
sys_lib_search_path_spec=`$CC -print-search-dirs | grep ^libraries: |
sed -e
Es schrieb Jon Leichter:
[..]
describe - using just a DLL_EXPORT or EXTERN in an installable
header file is simply wrong.
Agreed. Is someone going to fix this in libtool?
well, it's not particularly a libtool problem that people tend
to put a dependency of their code I would more or
Es schrieb stefan:
Hello list,
I recently setup a cross compiler from linux-mingw32. Using --host,
--build and --target I am able to reproduce software successfully. But
with a little bit of confusion about the above parameters.
Reading `info Autoconf' tells me:
--host : the
Es schrieb stefan:
On Sat, 5 Jan 2002, Guido Draheim wrote:
Es schrieb stefan:
Hello list,
I recently setup a cross compiler from linux-mingw32. Using --host,
--build and --target I am able to reproduce software successfully. But
with a little bit of confusion about
Es schrieb stefan:
On Sun, 6 Jan 2002, Guido Draheim wrote:
Thus libtool should set the program compiling the `impgen' program when
creating the import library to a `--build' gcc and should not default to
the `--host' gcc which it in fact does. This fails of course, because
Es schrieb Dan Kegel:
Guido Draheim wrote:
... See - the libtool crossgcc support (to which I did
contribute some of the time) can simply ask the cross-gcc
for the local searchpath via `gcc -print-search-dirs` -
this is needed for win32 compiles atleast, and I have a
patch on my disk
Es schrieb Dan Kegel:
As pointed out by H. Lu in October
( http://mail.gnu.org/pipermail/bug-libtool/2001-October/002869.html )
and seconded by Guido
( http://mail.gnu.org/pipermail/bug-libtool/2001-October/002872.html )
libtool improperly searches /lib and /usr/lib when doing
a
Es schrieb Dan Kegel:
Guido Draheim wrote:
... you put the patch before the big case-series
for the target-platform, so I guess that the libpath will be
overridden immediately.
Only if the case statement below decides to override it.
Linux doesn't.
Putting it above the case
to be a very
old correction even that I did not find the exact location.
well, let's hope there is a libtool release somewhen that can
do darwin compiling then
cheers, guido
Es schrieb David N. Williams:
Guido Draheim wrote:
[..]
oh no, it's the old overquoting problem along with zsh
Bob Friesenhahn wrote:
On Tue, 17 Sep 2002, Max Bowsher wrote:
I agree that this is inelegant. Ideally, we would calculate the relative path to
bindir from libdir, but I don't know how to do that. Anyone?
There is no requirement that bindir from libdir even be on the same
filesystem,
Max Bowsher wrote:
Earnie Boyd wrote:
Guido Draheim wrote:
hmm, perhaps, the LD can now link with dlls directly, and that should
Yes, indeed it can, and will search for it in the LIBRARY_PATH. If it
can't find libfoo.dll.a or libfoo.a it will look for libfoo.dll when
-lfoo is given
Earnie Boyd wrote:
Guido Draheim wrote:
Max Bowsher wrote:
Guido Draheim wrote:
How old may a gcc/binutils pair be? My oldest crosscompilers
are gcc 2.95.3 and ld --version reports 2.11.90.8. And for
all I know, these are in fact the oldest versions around,
no one want to go back beyond
Frank Kemmer wrote:
Wouldn't it be nice, if libtool had versioned the '.a' files, too, if the
-release option
is given? Or may be another option -staticlib-release?
This is just a question? Or is there another style of versioning intended
for the
static libs?
we had a talk about
David Olofson wrote:
On Wednesday 18 September 2002 22:37, Danny Smith wrote:
[...]
or does that mean we
either have to make assumptions, or just *require* import libs to be
present?
The latter is certainly safer.
Yeah, but it doesn't work if you can't get an import lib that works
Troy Cauble wrote:
So the Stable Release is over a year old and only works
because the Linux distro teams are patching it. Maybe
it's time for a bug fix release? Or at least pointers to
the best patches on the home page?
please, let's have one, as soon as possible. hmm, tomorrow?
Elizabeth Barham wrote:
Earnie Boyd [EMAIL PROTECTED] writes:
Not, totally, but it's being worked upon. I've joined the libtool list
as well in order to help with resolving the issues with mingw32
host/build/target issues. Hopefully, others that have been actively
working with mingw32
Isn't that the old zsh qouting bug? Well, people still refuse to give us
an 1.4.3 anysoon, so may be you want to expand your configure scripts with:
http://ac-archive.sf.net/Installed_Packages/patch_libtool_on_darwin_zsh_overquoting.html
Christoph Egger wrote:
Usually I don't reply myself, but
no news
Troy Cauble wrote:
Using 1.4.2, I was bitten by the test/pic_mode quoting bug
in ltmain.sh.
I pulled branch-1-4 from cvs but for that version, ltmain.sh
needs ${SED} defined by a new macro and still has issues with
non-quoted test values anyway.
After realizing that I
Christoph Egger wrote:
All what I want are three things:
1) That my above fix becomes part of one of the next libtool releases
2) That libtool calls gcc with the right params, so that gcc doesn't break
the compiling process with 'gcc: -install_name only allowed with
-dynamiclib'
3)
a new-feature release is the same work as a bugfix release?
ye kiddin'...
Bob Friesenhahn wrote:
Wouldn't it be better to get libtool 1.5 out the door? The resources
required to achieve a releasable product are similar and CVS libtool
already contains most of the fixes that would go into a
Bruce Korb wrote:
Christoph Egger wrote:
Ok, here we come: I just did 2)
The fix is replacing this line
archive_cmds='$nonopt $(test x$module = xyes echo -bundle ||
echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
$deplibs$linker_flags -install_name $rpath/$soname $verstring'
by
Bob Friesenhahn wrote:
Time spent on libtool 1.4.3 is time spent doing work which must
either be done a second time, or has already been done, for libtool
1.5.
Not true. There were some patches backported even before now,
I was doing some of the work under the expectation that we can
see a
Elizabeth Barham wrote:
yes,mingw*)
-library_names_spec='${libname}`echo ${release} | sed -e
's/[[.]]/-/g'`${versuffix}.dll'
+soname_spec='$libname.dll'
+library_names_spec='$libname.dll.a'
don't cut away the release spec.
libtool link --release 10.56 -o libfoo.la
Earnie Boyd wrote:
Max Bowsher wrote:
Earnie Boyd wrote:
Unfortunately not - make install bindir=/alternatelocation.
I prefer that over a switch, with a default
value for the variable of ../bin.
I think that a switch is the only way, if we are to deal with the case I
cite above.
Benjamin Reed wrote:
[...]
---(snip!)---
kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module
-avoid-version
kbackgammon_LDADD = kbackgammon.la $(LIB_KDEGAMES) $(LIB_KSYCOCA)
kbackgammon_SOURCES = dummy.cpp
---(snip!)---
...this is a no-no, kbackgammon is trying to link against a
Guido Draheim wrote:
Benjamin Reed wrote:
[...]
---(snip!)---
kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module
-avoid-version
kbackgammon_LDADD = kbackgammon.la $(LIB_KDEGAMES) $(LIB_KSYCOCA)
kbackgammon_SOURCES = dummy.cpp
---(snip!)---
...this is a no-no, kbackgammon
Benjamin Reed wrote:
On Sunday, November 24, 2002, at 05:13 PM, Guido Draheim wrote:
I mean, that should also be seen on other platforms than darwin, right?
Or am I mistaken here? (I wouldn't count myself to know large parts of
libtool indepth, well, then again, who still does ;-) ...)
Well
Benjamin Reed wrote:
On Sunday, November 24, 2002, at 04:54 PM, Guido Draheim wrote:
The only hint that I can give has the form of a question: Did you try
kbackgammon_LDADD = -static kbackgammon.la $(LIB_KDEGAMES)
$(LIB_KSYCOCA)
kbackgammon_SOURCES = dummy.cpp
$ ./libtool --help --mode
Benjamin Reed wrote:
On Sunday, November 24, 2002, at 05:44 PM, Guido Draheim wrote:
You mean they are listed as .la on the link-line?
To stick with the example, there is a
LIB_KDEGAMES = libkdegames.la
in your makefiles? aargh, kde maniacs at work
No, it would be, libfoo_la_LIBADD
It's the correct solution AFAICS - from the same sources two
libtool libraries are built - one is a system library that
gets linked to the system binary. And the module libtool
archive is separate from that. Both .la will be able to pick
up the same .lo being compiled along, so it is nothing more
link with a .dylib and everything gets resolved nicely?
cheers, -- guido
Nick Hudson wrote:
On Monday 25 November 2002 10:04 am, Guido Draheim wrote:
It's the correct solution AFAICS - from the same sources two
libtool libraries are built - one is a system library that
gets linked to the system
**
do you have a /usr/local/lib/.libs/ directory ?
**
Szekely Izabella wrote:
Hy!
I use libtool 1.4.2, automake 1.4-p5, autoconf 2.13 on RedHat linux 7.3.
The is the folowing error ...:
PREPROCESSING ...
/bin/sh ../../libtool --mode=link c++ -g -O0
To clarify a bit - the link-line does not have a -L for some .libs.
Any .libs of a -L is searched automatically. If that is not the
case then the next guess comes at some .la to be copied manually
around instead of being installed. May be libmp3lame.la and
libshout.la are somewhere around? -
[EMAIL PROTECTED] wrote:
== pw == Philip Willoughby [EMAIL PROTECTED] writes:
pw I have the following in a Makefile.am:
pw pkglib_LTLIBRARIES=libapttlog.la
pw libapttlog_la_SOURCES=aptt/log/log.c AM_CPPFLAGS=@INCLTDL@
pw -I$(top_srcdir)/src -I$(top_builddir)/src
pw
Carl D. Roth wrote:
I had the same problem - libtool does not like destdir-install
with two libraries being interdependent. I had a look through
the sources how to pass it down to libtool - but the automake
generated install-line for the .la will now pass an extra
argument. Without help from
Simon Richter schrieb:
Robert,
Ok, here it is. This patch changes AC_LIBTOOL_PROG_COMPILER_PIC
so that it only appends -DPIC to the default C tag and the CXX
tag for C++. I would also like to deprecate -DPIC in the 1.5 release
to make it clear we intend to do away with it. I would also like
Boehne, Robert schrieb:
Wouldn't replacing -DPIC with -D__PIC__ break a fundamental
assumption about ANSI compilers, that __ means compiler-defined
and not in the userspace?
[...]
#if (defined(__pic__) || defined(__PIC__)) !defined(PIC)
#define PIC 1
#endif
The main problem with
Boehne, Robert schrieb:
IMHO, I have yet to see an example of how it could be useful
to define PIC when it seems that the only way to make use of
it is to have it surround severely implementation-specific stuff
like inline assembler in which case the compiler _should_ be defining
__PIC__ or some
to use different options than these. It's surely the
existance of -DPIC on the commandline that made developers
to just pick it up, 'cause it's so easy and 'been around so
long. :-))
-- cheers, guido
Robert
-Original Message-
From: Guido Draheim [mailto:[EMAIL PROTECTED]]
Sent: Thursday
I did just ran into a problem with darwin libtool
that refuses to link. I have noticed that current
cvs contains a patch (20-03-2003) that fixes the
situation. It's a big one, I do only need a small
part of it (lt_cv_deplibs_check_method=pass_all).
Question: what's the status, is it a good plan to
I have a similar problem on a different account: the version
management system at my employer uses ~ in directory names
to flag different branches and subversions of projects and
their checkout areas. The libtool has the tendency to
resolve some symlinks, so it does not help to put some
* short
The world has changed - there are commandline tools for unixish systems
that take a C program (not C#!) and compile them into a MSIL binary or
library. This makes it a valid crosscompile target for free software.
The free projects for the dotnet platform - mono, dotgnu, portablenet
and
Guido Draheim wrote:
Bob Friesenhahn wrote:
On Thu, 11 Sep 2003, Guido Draheim wrote:
* short
The world has changed - there are commandline tools for unixish systems
that take a C program (not C#!) and compile them into a MSIL binary or
library. This makes it a valid crosscompile target
Dalibor Topic wrote:
Guido Draheim wrote:
Dalibor Topic wrote:
Guido Draheim wrote:
For the java machine, the term `jvm` is used universally. I do not
remember there were any dependency on pointer lengths, it runs in
managed mode always.
JVM, JDK, Java, etc. are all trade marks
[EMAIL PROTECTED] wrote:
Hi,
I want to compile gtkhtml2 (libgtkhtml) for windows,
I use MinGW (gcc-3.2.3) and cygwin.
My problem is that only static libraries are created,
no .dlls. What could be the reason for this?
The problem is that the library consists of some
sub-packages
You may want to ask at mingw.org for specifics. If all
dependencies are resolved then a dll should be there
as $subdir/.libs/*.dll - check the content of the .la
files in $subdir/*.la whether it has been configured
correctly to create dynalibs (it's a text file). Then
do the next step.
[EMAIL
Jim Pick wrote:
Anyways, the config.sub name is just going to be used to define a
target - so it makes sense to call the target Java, since it's only
going to be used by tools generating Java byte code, which will run on
Sun's JVM. Of course it will still run on other virtual machines that
# Add /usr/xpg4/bin/sed as it is typically found on Solaris
# along with /bin/sed that truncates output.
for lt_ac_sed in $lt_ac_sed_list /usr/xpg4/bin/sed; do
- test ! -f $lt_ac_sed break
+ test ! -f $lt_ac_sed continue
cat /dev/null conftest.in
lt_ac_count=0
On one of my build
67 matches
Mail list logo
