Porting libtool to SkyOS
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 files). Ok, I started by reading following documentation: http://www.delorie.com/gnu/docs/libtool/libtool_61.html. As stated there, I added all SkyOS specific setting to libtool.m4 from the libtool-1.5.22 package. Unfortunately I don't know how to proceed. What must be done next? Just a simple ./configure;make;make check? I tried this, but it doesn't look like as if my changes were actually used. (only libtool.m4 has the new changes in it, no other file). I then tried to use autoconf/automake, but this failed with error messages like: configure.ac: No proper invocation of AM_INIT_AUTOMAKE was found. I upgraded autoconf to 2.95c without success. Running ./bootstrap also prints many autoconf errors. Can anyone give me a few hints on how to actually "compile" and test the changes? Thanks! Robert___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Re: Porting libtool to SkyOS
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 && make check VERBOSE=x ) 2>&1 | tee log') I rebuilt and reinstalled autoconf-2.59c, automake-1.9.6 and m4-1.4.4. > ( ./bootstrap && ./configure && make && make check VERBOSE=x ) 2>&1 | > tee log > and send the log. > This is weird. Let's see those errors. configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). tests/Makefile.am:51: HAVE_CXX does not appear in AM_CONDITIONAL tests/Makefile.am:52: HAVE_F77 does not appear in AM_CONDITIONAL tests/Makefile.am:58: HAVE_F77 does not appear in AM_CONDITIONAL configure.ac:55: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:107: error: possibly undefined macro: AM_CONDITIONAL autoheader: error: AC_CONFIG_HEADERS not found in configure.ac configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). Makefile.am:5: INSTALL_LTDL does not appear in AM_CONDITIONAL Makefile.am:12: CONVENIENCE_LTDL does not appear in AM_CONDITIONAL configure.ac:53: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:54: error: possibly undefined macro: AM_CONFIG_HEADER configure:19209: error: possibly undefined macro: AM_CONDITIONAL configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). configure.ac:32: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). Makefile.am:16: BINARY_HELLDL does not appear in AM_CONDITIONAL Makefile.am:33: BINARY_HELLDL does not appear in AM_CONDITIONAL configure.ac:32: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:58: error: possibly undefined macro: AM_CONDITIONAL configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). configure.ac:32: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). configure.ac:32: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). configure.ac:32: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac: no proper invocation of AM_INIT_AUTOMAKE was found. configure.ac: You should verify that configure.ac invokes AM_INIT_AUTOMAKE, configure.ac: that aclocal.m4 is present in the top-level directory, configure.ac: and that aclocal.m4 was recently regenerated (using aclocal). Makefile.am:16: BINARY_HELLDL does not app
Re: Re: Re: Re: Porting libtool to SkyOS
> 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? Anway, I'm currently doing a 'make check' for autoconf, automake and m4. Maybe there is a general problem with these tools which just happens to be a problem when trying to build libtool. Thanks, Robert___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool 2.1a ported to SkyOS, how to test?
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. The testsuite predicts that the 'shared' tests finished successfully. My question is now, how can I test other packages, for instance libcairo, with these modifications? What is the prefered why to tell cairo that there is new libtool now? Thanks! Robert ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool 2.1a ported to SkyOS, how to test?
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 variables) when the aclocal perl script tries to execute autom4te. (Because of this aclocal is almost empty always). I will investigate this and let you know the results. If everything works (configuring third party packages too), I will post the output from 'make check' and the patch to the mailling list you suggested. Thank you very much for your help! Robert ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool 2.1a ported to SkyOS, how to test?
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 added. When I try to build libtool-1.5.22 it succeeds and creates following files in the libltdl/.libs directory: libltdl.dll (A valid SkyOS dll with all functions exported) libltdl.a (The static library) libltdl.la : # libltdl.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libltdl.3.1.4.dll' # Names of this library. library_names='libltdl.dll' # The name of the static archive. old_library='libltdl.a' # Libraries that this one depends upon. dependency_libs='' # Version information for libltdl. current=4 age=1 revision=4 # Is this an already installed library? installed=no # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/local/lib' libltdl.lai: # libltdl.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libltdl.3.1.4.dll' # Names of this library. library_names='libltdl.dll' # The name of the static archive. old_library='libltdl.a' # Libraries that this one depends upon. dependency_libs='' # Version information for libltdl. current=4 age=1 revision=4 # Is this an already installed library? installed=yes # Should we warn about portability when linking against -modules? shouldnotlink=no # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/local/lib' Unfortunately trying to install libtool-1.5.22 doesn't work because the install process can't find libltdl-3.1.4.dll (which obviously isn't there) 'make install': /boot/programs/unix/bin/install -c .libs/libltdl.3.1.4.dll $dldir/libltdl.3.1.4.dll (this fails) Now the questions: - Does anyone know which libtool.m4 configuration is responsible for this failure? - When this is fixed, and there finally is a libltdl.3.1.4 dll, does the make install process install a symlink like libltdl.dll -> libltdl.3.1.4.dll ? ( If not, how is ld supposed to find this library when a third party package for instance tries to link to libltdl by just using 'ld -lltdl ?) - May there be any problems with SkyOS using the .PE DLL format for shared libraries? There must be no undefined/unreferenced symbols when building a DLL. (like in Windows) Anyway, a few more information: I tried to add a skyos target to libtool.m4 with following characteristics: - The static library should be named: $(libname).a - The dynamic library should be named: $(libname).dll - There should be NO import library. ( $(libname).lib), because SkyOS GCC/LD can directly link against the DLL I attach following files: libtool.m4.diff output from (./bootstrap && ./configure && make && make install) I would be very thankful for any hint! Robert! log.txt.gz Description: GNU Zip compressed data libtool.m4.diff.gz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool 2.1a ported to SkyOS, how to test?
> 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 -o .libs/ltdl.o rm: cannot remove directory `': Is a directory Fixed. This was a kernel bug when trying to delete '' (rm -f ltdl.o '' ). It returned EISDIR rather then ENOENT Did you change ltmain.in or ltmain.sh in any way? You can run No, not at all As far as I can see, we need to discuss several questions before we can fix this: - does skyos have drive letters like w32? If not, the logic can be simplified considerably. No. You can think of SkyOS as a unix system when it comes to the filesystem layout and available tools. A *nix emulation layer inside the kernel emulates a *nix environment by providing the well known *nix filesystem layout (/bin, /usr/, /etc, .) as well as linking all available GNU tools into this locations. Same for the environment variables. The only real difference is the executable file format which is PE in SkyOS. Note: If there is anything missing, like an environment variable, essential directory, gcc configuration, ... then I can easily fix this and make it available in the next distribution. - how does the runtime linker find DLLs? Is there a special variable for it (shlibpath_var, for example LD_LIBRARY_PATH) or does it abuse $PATH for this? If not the latter, you don't need the hacks done for cygwin to install a DLL in some bindir. The runtime linker looks in following folders is this order: - /boot/sytem/dll (primary location for DLLs) - /lib - /usr/lib - /usr/local/lib - LD_LIBRARY_PATH What you can do is post `./libtool --config' output. Better even, go through every such variable, try to understand its purpose, and then try to think whether it needs to be adjusted for skyos. There is some documentation about them in doc/libtool.texi, and some inline in libtool.m4. Then post your results, and we shall see how we can munge that into a proper patch to support skyos. Attached. I'm going through every variable currently. I already found sys_lib_search_path_spec and sys_lib_dlsearch_path_spec which are not set correctly. Thanks, Robert! config.txt.gz Description: GNU Zip compressed data ___ http://lists.gnu.org/mailman/listinfo/libtool
Libtool 1.5.22 (almost) ported to SkyOS
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 undefined symbols in the resulting shared library don't set this flag at all? One of these packages is glib, for instance. Once I added the -no-undefined to makefile.am, it built correctly. So I guess this is something I should bug the glib people instead? Anyway, I will do a few more tests and send a patch once everything is working correctly. Thanks Robert! ___ http://lists.gnu.org/mailman/listinfo/libtool
hardcode_libdir, rpath and DLLs
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_not_yet_installed_glib-2.0.0 to ld. 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 have to set this path. (Inside the make process this may not be really a problem, but when executing directly from the shell no one has set this path yet). How does cygwin deal with this? Does this even work on cygwin? Thanks, Robert! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Re: hardcode_libdir, rpath and DLLs
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 >>> have to set this path. (Inside the make process this may not be really >>> a problem, but when executing directly from the shell no one has set >>> this path yet). >>> >>> How does cygwin deal with this? Does this even work on cygwin? >>> >>> Robert >> Win32 doesn't have any such notion of LD_LIBRARY_PATH, so that is not an >> option. The DLL search rules are very simple, I think it's essentially >> 1. current working directory, 2. $PATH, 3. Windows system directory. >> There may be other obscure modifiers too. The full search order is >> documented on MSDN under the LoadLibrary() function I think. >> I suspect the right way to handle this would be to use "libtool >> --mode=execute" to run the binary, and that should either set the >> working directory to the dir where the DLL lives or set $PATH. Or maybe >> libtool uses a wrapper script for the binary. >> Brian Sorry, I should have included a reference to following posts: http://lists.gnu.org/archive/html/libtool/2006-04/msg00047.html http://lists.gnu.org/archive/html/libtool/2006-04/msg00027.html I'm actually porting libtool to SkyOS which mostly works already. So I'm not running windows/cygwin, its just that the SkyOS executable format is PE/DLL, thats way I'm refering to cygwin in the last post. >> [ Note that Cygwin does actually support LD_LIBRARY_PATH but only when >> doing dynamic runtime loading of a library with dlopen(), but it can >> only do this because at that point Cygwin is fully in control of things >> and can fake it. When simply calling on the operating system to load a >> binary (in the case of ./foo) there is no way to influence the DLL >> search process since that is done by the Windows dynamic loader. ] Actually SkyOS respects the LD_LIBRARY_PATH variable when loading an executable. Thanks! Robert! ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Re: hardcode_libdir, rpath and DLLs
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 let you know how far I come. Thanks for the really great help so far! Robert ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool / SkyOS / ELF
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 possible to just set the version_type to none? 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) Attached is the patch against libtool-1.5.22 which adds "skyos" as a supported target. 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. Please let me know if you have any suggestions/comments regarding this patch, Thanks! Robert libtool.m4.patch Description: Binary data ___ http://lists.gnu.org/mailman/listinfo/libtool
