has to re-compile the tool
I know that I can use the "-version-number" option to get the same
behavior across different operation systems, but I'm wondering if
this is merely a BSD convention, or if there is a deeper technical
reason.
Thanks in advance,
Stefan
ctory. Then, a wrapper
script was created
-in the current directory.
On NetBSD 1.2, libtool encodes the installation directory of
libhello, by using the `-R/usr/local/lib' compiler flag.
--
Stefan Sperling <[EMAIL PROTECTED]> Software Developer
elego Software
://www.jobtrans.info/employers/index_.php?menu=viewsingle&sajat=1&emailrol=1&id=668
These are printable, and you can download them, too..
I hope to hear from you in the near future.
Thank you for your kind attention.
Yours sincerely,
Stefan Veronica
[EMAIL PROTECTED]
==
!
On Tue, 29 Jan 2002, Jon Leichter wrote:
> Stefan. I have had the same concerns as you. I have brought up a similar
> topic in the past. Even with your patch, DLL_EXPORT is a flawed macro name.
> I'd suggest the following patch:
>
> #ifdef LIBLTDL_DLL_IMPORT
> # def
Dear list,
The attached patch is meant to fix problems with the libltdl.dll
under Windows. It attaches LT_SCOPE to each exported/imported symbol.
Furthermore it changes
#ifdef DLL_EXPORT
# define LT_SCOPE __declspec(dllexport)
#endif
#ifdef LIBLTDL_DLL_IMPORT
# define LT_SCOPE extern __declspe
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
> > > > this g
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
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 system the package will run
Dear libtool'ers,
while using the current version 1.4.2 of libtool I encountered the
following problems:
On a Darwin 1.4 (MacOSX 10.0, bash) --
I had to --disable-shared for a complete build.
This is due to the extra convenience libraries on the final link command
line.
I got it workin
Paul Davis [EMAIL PROTECTED] wrote:
> > > what is any of this for in the first place?
> >
> >You mean why do we allos someone to define lt_dlmalloc, lt_dlrealloc,
> >and lt_dlfree? I don't know :)
>
> yes, thats precisely what i mean. what problem is this attempting to
> solve? some bizarre platf
Hello list,
in the current libltdl package (1.4.2) you are marking the allocator
function pointers (malloc, realloc, free) with LT_SCOPE in order to
indicate the linker on M$-Windows to import/export it from the DLL. Why
don't you do this with all other code symbols?
Thanks in advance,
Dear libtool'ers,
just played around with libtool-1.3d.tar.gz ... under Win32. It worked
perfectly with a Cygwin distro. Thanks for your efforts on that.
Now I do have two feature request (do not know if ever possible...):
1) AC_LIBTOOL_WIN32_DLL should have two optional arguments like
AC_
Hello libtool'ers,
since the MinGW32 (Minimal GNU for Windows) linker is able to create
shared libraries on Windows I would like to know if it would be posssible
to add support for DLLs to libtool ?
I do have some knowledge about the general build process on Win32. So if
you want to know how i
13 matches
Mail list logo
