[[Moved back to libtool list, but left all the context for people who
don't follow libtool-patches]]
Hi Paul,
Sorry this isn't a full reply -- I'll try to get back to you when I
have had time to look over your patch.
On Thu, Jul 27, 2000 at 09:41:52PM -0300, Alexandre Oliva wrote:
> On Jul 27, 2000, Paul Sokolovsky <[EMAIL PROTECTED]> wrote:
>
> > Thanks, I noticed that announced location for them (/common @
> > subversions, IIRC)
>
> It used to be /common @anoncvs.gnu.org; it's /config since it moved to
> subversions. You can get the latest files from ftp.gnu.org anyway.
>
> > Yes, I heard about that, but I need that to get all working.
>
> Just get the CVS tree, branch-1-3 if you care much about stability.
>
> > I still hope to implement way which will allow building dlls without
> > any changes to sources/build files.
>
> Good luck :-)
Been there! I am open to suggestions having hit a few brick walls
myself!
> > Because AFAIU the way to turn off caching is to assign it to
> > /dev/null, not empty string.
>
> Anyway, config_cache may be empty, and that's what the test is
> checking for.
>
> >>> - allow_undefined_flag=unsupported
> >>> + allow_undefined_flag='-Dundefined'
>
> AO> I'm pretty sure this is not enough, at least for some older versions
> AO> of Cygwin.
>
> > Older versions of cygwin were betas and long've been gone.
>
> For you, maybe. There are still people using them, and unless we have
> good reason to break them, we shouldn't. I don't think we have a good
> reason.
>
> Besides, are you really sure -Dundefined also works on all versions of
> mingw?
>
> > Then, why account for their bugs?
>
> Why don't we start requiring only POSIX-compliant platforms too? :-)
> This would at least solve our problem of supporting the brain-damage
> of MS-Windows DLLs :-)
>
> AO> This is not fascistic. It's just that it's impossible to build DLLs
> AO> on MS-Windows unless header files and function definitions contain the
> AO> appropriate __declspec directives.
>
> > That's not true. That's dll client executables cannot be built
> > without __declspec - *in some cases*. Dlls themselves are always built
> > (unless there're several mutually dependent ones). I proved that to
> > Gary. Well, I showed him ;-)
>
> I see. This is news to me. Good news. But how about data symbols
> exported from the library? If DLLs don't work just like on regular
> systems, there's little point (IMO) in creating the library, since
> people won't be able to link with them. Is there any way we can tell
> whether the library exports any data symbols, by looking at object
> files and its dependencies?
I need to trawl through my mail archive to jog my memory, but I do
recall being moderately convinced at the time =)O|
> AO> If this is not the case for PW
> AO> (what the heck is that?
>
> > That's fruit of my long-standing discontent with cygwin. It's
> > ported to win32 djgpp's libc + usual gnu-win32 stuff. So, while I'm
> > striving to be more standard-unix-friendly then other, there's same
> > old PE-COFF underlying.
>
> Thanks for enlightening me :-)
>
> AO> Wrong. LN_S should already be `cp' on systems that don't support
> AO> soft-linking. If this isn't the case, that's what you want to fix.
>
> > And I use mingw32-hosted gcc currently, so while pw32 has
> > symlinks, gcc/binutils don't understand them ;-)
>
> I see. So probably the way to go is to extend the test of soft links
> to check whether the tool-chain can understand them.
>
> AO> Wrong, this breaks builds on FAT file-systems.
>
> > Again not true. It doesn't break building on FAT systems.
>
> I'm talking about plain old FAT, not FAT32 or such extensions.
>
> > We won't consider crosscompiling from djgpp under bare dos to
> > gnu-win32 or gnu-linux, will we? ;-)
>
> Why not? What's wrong with someone using DOS for real development? :-)/2
>
> AO> all. Assuming ../bin is blatantly wrong.
>
> > Agree that wrong, do not agree that blatantly! That's just nice
> > heuristics ;-)
>
> Sustained :-)
>
> AO> It's the Makefile that must use bindir when installing a DLL.
>
> > But that's totally against libtool grand idea.
>
> No, it is MS-Windows's DLL model that's totally against libtool grand
> idea. The developer must modify header files to be able to link with
> DLLs. That's why libtool requires a special macro for the developer
> to tell libtool the package has been properly adapted to support DLLs.
>
> > It is asked to install (shared) library and should do it. If there's
> > platform on which shared libraries smeared across two files, one
> > called 'implib' and one called 'dll', both preferrably installed in
> > different dirs, it should do it, silently
>
> Not if it can't tell what is the preferrable directory. And, in
> general, it can't. I'd rather not do a partial job.
But with libtool, the dll is *not* smeared across two files. I wrote
the impgen program so that a static implib is generated on the fly,
allowing libtool to treat the dll part as the whole library for the
rest of the time. The tradeoff is that we have to jump through some
hoops (building and running the impgen program for on the build host)
in order to perform a simple link. The key is in realising that
Windows uses the binary search PATH to find dlls (I know that is an
oversimplification!).
> Please remember that libtool is a stand-alone script, and there's
> nothing wrong in someone creating any library then telling libtool to
> install it anywhere at all. It doesn't have to be /usr/local/lib, or
> $(libdir). One could run, for example:
>
> libtool --mode=install install -c libgcc.la
>/tmp/foobar/lib/gcc-lib/mn10300-elf/am33/libgcc.la
>
> Something like this will certainly start happening as soon as GCC
> starts using libtool to build libgcc. We shouldn't make this any
> harder than it already is.
Of course, that can only work (portably) if you built the library with
libtool --mode=link $CC -o libgcc.la -rpath /tmp/foobar/lib/gcc-lib/mn10300-elf/am33
$LIBGCCOBJECTS
> > To achieve this, all *dir should be passed via
> > ltconfig to libtool
>
> Nope, this is not an ltconfig issue, it's a libtool issue. Remember,
> libtool is a stand-alone script, it's not package-dependent at all.
> I'd rather not change this.
Not to mention that ltconfig will go away soon. The only interfaces
to libtool will be via configure.in (and ultimately configure) and the
libtool script itself (presumably as called by the Makefile).
> AO> We might accept a patch for libtool install to accept some alternate
> AO> directory in which to install a DLL, something like --dlldir, so that
> AO> libtool will install .DLL files in that directory, instead of, or in
> AO> addition to, the directory in which libraries are installed.
>
> > There's no such directory in GNU dirstructure, hence, shouldn't be
> > in a future.
>
> I'm not suggesting the addition of any additional directory. I'm only
> suggesting:
>
> libtool --mode=install --dlldir=$(bindir) install -c libgcc.la
>/tmp/foobar/lib/gcc-lib/mn10300-elf/am33/libgcc.la
>
> But see? It doesn't really solve the problem, since I could have
> installed multiple libgcc libraries with same name. In this case, the
> poor MS-Windows user will probably have to add $(libdir) to his PATH.
I think that Windows forces us to admit that $shlibpath_var is PATH,
and that a Windows user of libtool generated dlls must have the
library installation directories in their PATH. Maybe we should
install a wrapper script that takes care of this?
> Thanks for trying to fix this mess. I really hope some day we won't
> have to make contortions to be able to support shared libraries on
> MS-Windows. I wish you luck with the PW effort, even if your aim is
> not to fully replace the way DLLs are built with something that is
> more developer-friendly.
Most definitely!
Cheers,
Gary.
--
___ _ ___ __ _ mailto: [EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
