Re: Libtool 2.1a ported to SkyOS, how to test?

[Ralf Wildenhues]

* Robert Szeleney wrote on Sun, Apr 23, 2006 at 05:22:05PM CEST:
> >  
> >>/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

> Fixed. This was a kernel bug when trying to delete '' (rm -f ltdl.o '' 
> ). It returned EISDIR rather then ENOENT

LOL.  :-)

> >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.

Do executables have an extension, like .exe?

> 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.

OK.  Does the file system have symlinks and hard links?  Any
requirements on file names (like 8.3 or so)?

> 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.

:-)

For fixing the issue you previously reported (versioned libs): take a
good look at the versioning systems that ltmain uses.  If your system
uses the same one as one we already have, pick that; otherwise, it needs
a new one.  You picked linux in your previous patch, was that a
conscious decision?  When you're through with that, set
library_names_spec right, so that the symlinks will be created, and
`make install' will work right then.

> >- 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

OK.  How about dlopen?  Do you have that?  How does it find
- the modules to be opened, and
- any libraries those modules may depend on, in case your dlopen also
  loads these automatically (set this correctly in ltdl.m4)?

> >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.

soname_spec doesn't look right.  But the basic questions first:
Does your link editor load indirect dependencies?  Based on soname?
Does your runtime linker load dependencies?  Based on soname?

Then, search ltmain.in for occurrences of cygwin; you may have to add
skyos at some instances to forbid creating shared libraries if
-no-undefined has not been passed.

More later.

Cheers,
Ralf