Hi guys!
I recently started porting libtool to
SkyOS. In general, libtool works just fine in SkyOS, but only for static
libraries. So I want to update it to support shared libraries. (SkyOS uses
a unix similar filesystem layout with most GNU tools available and uses
the PE format for executable f
Ralf Wildenhues <[EMAIL PROTECTED]>
20.04.2006 16:40
An
Robert Szeleney <[EMAIL PROTECTED]>
Kopie
libtool@gnu.org
Thema
Re: Porting libtool to SkyOS
Hi Ralf!
Here is the log.
Before I did '( ./bootstrap && ./configure
&& make &&
> This is too small. aclocal.m4 should contain
some macros from Automake.
> You didn't by any chance remove the AM_INIT_AUTOMAKE call from
> configure.ac in your changes?
>
No, I didn't touch any file.
Do you think that this is rather an autoconf/m4/coreutils/...
instead of a libtool problem?
Hi guys!
Being unable to './bootstrap' libtool 1.9 because of various autoconf
errors I just tried to ported libtool 2.1a (the daily CVS version).
Fortunately ./bootstrap works without any problems there. I also added
all SkyOS modifications to libtool.m4 and run ./configure;make;make check.
Hi Ralf!
Erm. Did you mean 1.5 instead of 1.9? Because 1.9 is dead; branch-1-5
and HEAD are alive.
Oh yes, sorry, I meant 1.5.22
Anyway, I have a suspicion why libtool 1.5.22 is not working. Looks like
that the kernel can't setup the inital stack layout (with arguments and
environment va
Hi!
Ok, made progress. ./bootstrap for libtool-1.5.22 works now. (After
fixing the inital stack creation routine and tweaking gcc to return the
default library directory for 'gcc -print-search-dirs)
But it looks like that there is a misconfiguration in the skyos specific
settings I just adde
> OK, first thing here: compiling ltdl.lo has these spurious errors:
/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.
-g -O2 -c -o ltdl.lo ltdl.c
mkdir .libs
rm: cannot remove directory `': Is a directory
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -c ltdl.c -DPIC -
Hi!
Finally it looks like that libtool is
working.
I can now successfully compile cairo-1.0.2,
fontconf-2.3.93, libxml2-2.6.23, and a few more to shared libraries.
Though I have one question regarding
the -no-undefined flag.
Is it possible that a lot of packages
which actually don't have und
Hi!
If I understand the libtool concept
correctly, libtool passes -rpath to the linker when building an executable
which depends on a not yet installed library.
For instance, when building glib, glib-2.0.0.dll
is built at first. When building glib-genmarshal, libtool passes -Wl,--rpath,/path_to_n
Hi Brian!
>>> Unfortunately, PE DLLs don't support
this --rpath option. Is there any
>>> way to tell libtool to use something different for this?
>>>
>>> Probably using LD_LIBRARY_PATH. Though I think that this will
not
>>> really work, because whenever you execute glib-genmarshal
one would
>>>
Hi!
Ok, because of the various problems
using PE/DLL executable format with *nix software I just decided to completely
drop PE support and replace it with ELF. (Except for a tiny .PE loader
for Mono assemblies).
http://www.skyos.org/?q=node/519
Once done, I will try porting libtool
again and le
Hi!
As "promised" in my last post
to this mailinglist I finally switched the SkyOS executable format from
PE to ELF.
And finally, libtool works like a charm.
Anyway, I have one question regarding
the version-type. As I don't want to use any shared library versioning
system on SkyOS, is it possi
12 matches
Mail list logo
