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
hi everyone,
I am still trying to crosscompile a dll on linux with the new
autotools series. Currently I use cvs-autoconf, automake-1.4d
and libtool-1.4 on top of libsdl.org/Xmingw32 cross-tools.
I did just need to change a single line in ltmain.sh which
enabled me afterwards to actually *buil
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
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 libt
Alexandre Oliva wrote:
>
> On Apr 26, 2001, Guido Draheim <[EMAIL PROTECTED]> wrote:
>
> > 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.
okay, here's the relevant section from libtool, just a few
lines before the prog-wrapper generation:
# Only actually do things if our run command is non-null.
if test -z "$run"; then
# win32 will think the script is a binary if it has
# a .exe suffix, so we strip it o
umm, TODO says:
* Port the migration of all code from ltconfig into libtool.m4 to the
multi-language-branch, so that CVS automake can remove its references
to ltconfig.
isn't that done already? likewise for
* Check whether the version of libtool.m4 is compatible with
ltconfig/ltmain.sh. M
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 kno
Sebastien Sable wrote:
>
> Sebastien Sable <[EMAIL PROTECTED]> writes:
>
> > So I made a fake very simple library using autoconf, automake,
> > libltdl, libtool-1.4. Making it as clean as I could, reading the
> > autobook and libtool info pages. It works perfectly well under
> > linux. It compil
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 wil
"Gary V. Vaughan" wrote:
>
> Since we are trying to make things work like UNIX here, I think that the dlls
> should probably be installed to $libdir. The problem that needs solving is
> how to teach the executable to find its dlls.
>
> Unfortunately this probably comes dow to wrapper scripts,
> 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,
Alexandre Oliva wrote:
>
> On Jun 8, 2001, Guido Draheim <[EMAIL PROTECTED]> wrote:
>
> > hmmm, or an autoconf wrapper macro?
>
> Nope, this wouldn't work for libraries that are not installed in
> libdir, but in a subdir thereof.
>
Yes, it would, the su
As everyone knows, compiling a win-dll requires all references
to be resolved at link-time, and therefore libtool needs to
know all lib-files by their name in the link-stage.
A project of mine contains a few module-dll that are installed
into $pgklibdir and "dlopen"-ed. Now there is a module2-dl
there are plans for automatic support of HOST_CC
(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
a few bits, like renaming the build-libs
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
Guid
moin moin, Olly,
Olly Betts wrote:
>
> On Wed, Jun 20, 2001 at 03:23:18AM +0200, Guido Draheim wrote:
> > What is HOST_CC ? It has no default, and cross-gcc is the wrong cc.
>
> It's meant to point to a native compiler in precisely this situation to
> solve the probl
"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
"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
[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 mu
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
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
Max Horn wrote:
>
> At 3:28 Uhr +0200 15.09.2001, Guido Draheim wrote:
> >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 bui
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
Es schrieb Kevin Ryde:
> > But this is not
> > actually the Right Thing, dlltool should offer an option about it,
> > and since dlltool is preinstalled, we do not need to compile a
> > tool on the fly.
>
> Yes, that'd make sense. I suppose though that features added to
> dlltool now wouldn't act
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
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-x
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 mai
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 t
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:" |
> s
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
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:
> --hos
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 ab
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
> > &g
Es schrieb Robert Collins:
> >
> > and note that there are quite some other people on this list who would
> > love to see the things get sorted out once and for all. It just needs
> > someone with time enough to exchange the three dozen e-mails it will
> > take (atleast!) to get things right. Just
>
> and libtool.texi says
> @defvar old_archive_from_expsyms_cmds
> If a static library must be created from the export symbol list in order to
> correctly link with a shared library, @samp{old_archive_from_expsyms_cmds}
> contains the commands needed to create that static library. When thes
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
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 cro
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.
> Linu
ad
of the x-prefix-with-doublequotes we have here, which accounts
also for the libtool-1.4.2 branch - it seems 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
E
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
> file
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.
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, I g
David Olofson wrote:
> On Tuesday 17 September 2002 13:05, Max Bowsher wrote:
> [...]
>
>>I think the correct approach is to use a libfoo.dll.a if it is present,
>
>
> Agreed.
it should be ATM.
>
>
>
>>and do funny impgen stuff if it is not.
>
>
> Just not as funny as the current appro
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.
Earnie Boyd wrote:
> Guido Draheim wrote:
>
>>
>>No, because I did just switch my system, and have to reinstall some
>>rpms - crosscompiler and stuff is some that. Atleast I am still
>>missing the crosscompiled zlib stuff that I used to use to
>>crosscompi
Earnie Boyd wrote:
> Guido Draheim wrote:
>
>>Earnie Boyd wrote:
>>
>>>Guido Draheim wrote:
>>>
>>>
>>>>No, because I did just switch my system, and have to reinstall some
>>>>rpms - crosscompiler and stuff is some that. At
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
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 impo
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 wit
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 th
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'
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/$sona
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
>
> Would bindir be an environment variable if libtool is being executed
> from make? If not, setting a variable in the libtool.m4 that configure
> sets works. I prefer that over a switch, with a default value for the
> variable of ../bin. If bindir is passed to libtool through the
> envir
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
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 bund
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 is
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 ;-) ...)
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:17 PM, Guido Draheim wrote:
That's actually the difference between "-all-static" and "-static" IIRC.
The "-static" should only link its .la's as static, and non-la's dynamic.
But perhaps I
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
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
t
o can
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
**
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 -L/usr/X
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? - notice
[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> l
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 autom
Jon Nall wrote:
why do .la files have to store hard-coded paths of the .so files they
reference? why aren't the names enough as ld.so should be able to query
it's cache of library directories at runtime?
why not? - in other words, what's your actual problem with it...
i realize libtool runs o
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 lik
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 remo
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 s
ed to
be made explicit in the source setup - and people would try
harder 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
Ro
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
directori
Naofumi Yasufuku wrote:
At Mon, 31 Mar 2003 00:10:10 +0200,
Guido Draheim wrote:
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. T
* 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 oth
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
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 for free software.
Your
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 for free software.
The free projects for the dotnet platform - mono
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 with associated conditions of
use. http://www.sun.com
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 with
[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 (sub-directories)
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 PROTE
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
c
Petter Reinholdtsen wrote:
It has recently come to my attention that the latest versions of HP-UX
uses two different file suffices on shared libraries on ia64.
Traditional PA-RISC libraries use .sl endings, while ELF style ia64
libraries (32 and 64 bits) use .so endings.
Checking the ChangeLog in
Petter Reinholdtsen wrote:
[Guido Draheim]
I am not a maintainer, and I do not want to give any premature
answer on your question, but the wording of your question has the
feeling of a mail sent to a commercial hotline.
Interesting. You have more experience with commercial hotlines then
me
# 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
94 matches
Mail list logo
