Re: libtool / SkyOS / ELF

[Ralf Wildenhues]

Hi Robert,

* Robert Szeleney wrote on Thu, May 11, 2006 at 09:29:28AM CEST:
> 
> As "promised" in my last post to this mailinglist I finally switched the 
> SkyOS executable format from PE to ELF.

You know, it's pretty funny when issues in trying to port Libtool to
some system has the effect of having the system change its exectuable
format.  Talk about reverse effects.  :-)

> And finally, libtool works like a charm.

Great.  It'd be nice to see how the testsuite fares (see README on how
to run it verbosely).

> 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 possible to just 
> set the version_type to none? 

I think that should be possible.  But of course, that will limit the
ways in which you will be able to upgrade your shared libraries later.
Also, since I think version_type=none may not have seen so much usage
exposure in Libtool, there may have been bit rot.

> At least one package, tiff-3.7.4,  has problems with none as version type. 
> ( though I'm not sure if this is a tiff-3.7.4 or a libtool problem)

Could you point to more information, so we can see what the problem is
(build log, something that shows the failure)?  Thanks.

> Attached is the patch against libtool-1.5.22 which adds "skyos" as a 
> supported target.

Hmm.  I think it's missing a few things still.  First, if you have no
libm, I think currently it's necessary to hack a couple of places in
ltmain.in, unfortunately (search for beos there).  Then, what about PIC
objects, do you use text relocations in your shared libraries?  If yes,
how would that work on, say, x86_64 machines?  I think you need to set
lt_prog_compiler_pic (for both C++ and non-C++; if there are multiple
compilers on SkyOS, also for both $GCC = yes and no).  Similarly, how
about lt_prog_compiler_static and lt_prog_compiler_wl?

Then, I think you don't have an archive_cmds setting for C (and other
languages, in AC_LIBTOOL_PROG_LD_SHLIBS), only for C++
(AC_LIBTOOL_LANG_CXX_CONFIG).   Further, how about means to hardcode
library paths?  (That is rather important in order to be able to use
uninstalled libraries while compiling and testing some package.)
There are several aspects to this topic.  Also, I guess you may need to
set an export_dynamic_flag_spec value, and for optimization, you can
look at providing whole_archive_flag_spec if available.  Further, is
there a means to not export all non-static symbols in a library?  If
yes, you should set archive_expsyms_cmds.

For optimization, a setting in AC_LIBTOOL_SYS_MAX_CMD_LEN helps.

Then, an important missing part is a suitable adjustment to ltdl.m4.

> I tested this patch with following packages which all built a valid shared 
> library using libtool:
> atk-1.10.3, cairo-1.0.2, fontconfig-2.3.93, libxml2-2.6.23, glib-2.8.6, 
> libgdiplus-1.1.13.2, perl-5.8.8, gettext-0.14.5 and a few more.

That's great.  I think the Libtool testsuite will point to more
necessary changes.  Let's see further then.

> Please let me know if you have any suggestions/comments regarding this 
> patch,

Well, a GNU-style ChangeLog entry is optional but would be helpful. ;-)

Cheers,
Ralf