Hello Alexandre,
Friday, July 28, 2000, 4:41:52 AM, you wrote:
AO> On Jul 27, 2000, Paul Sokolovsky <[EMAIL PROTECTED]> wrote:
>>>> - 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.
AO> For you, maybe. There are still people using them, and unless we have
AO> good reason to break them, we shouldn't. I don't think we have a good
AO> reason.
AO> Besides, are you really sure -Dundefined also works on all versions of
AO> mingw?
-Dundefined does no magic - it just defines (unused) compiler
macro. Reasoning is that I wanted turn off
allow_undefined_flag=unsupported behaviour, while still allowing users
to see if allow-undefined was specified.
>> 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 ;-)
AO> I see. This is news to me. Good news. But how about data symbols
AO> exported from the library?
There's never problem with *exporting* anything, only *importing*
has.
AO> If DLLs don't work just like on regular
AO> systems, there's little point (IMO) in creating the library, since
AO> people won't be able to link with them.
They will! But, *maybe*, after some additional work.
AO> Is there any way we can tell
AO> whether the library exports any data symbols, by looking at object
AO> files and its dependencies?
Yes, that's how my a2dll script works, http://www.is.lg.ua/~paul/devel/a2dll.html
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 ;-)
AO> I see. So probably the way to go is to extend the test of soft links
AO> to check whether the tool-chain can understand them.
No! That's bug of my system! Soon it'll vanish forever, so there's
no need to drag workaround all along.
AO>> Wrong, this breaks builds on FAT file-systems.
>> Again not true. It doesn't break building on FAT systems.
AO> I'm talking about plain old FAT, not FAT32 or such extensions.
So do I. In Windows 95 of year 1995 MS introduced so-called 'vfat'
which completely backward-compatible with fat but allows long names.
Since win95 is the very first complete win32 system, that any win32
system support sane filenames.
Btw, it's also long-standing stereotype that there's some problems
with naming files on win9x systems. Nescape up to 4.7 was used to
screw up downloaded filenames by replacing all but the last dot to
underscores. Fortunately, they fixed that in 4.72 ;-)
>> We won't consider crosscompiling from djgpp under bare dos to
>> gnu-win32 or gnu-linux, will we? ;-)
AO> Why not? What's wrong with someone using DOS for real development? :-)/2
If someone so bright, I hope he'll have an idea of putting duty of
converting filenames to representation acceptable by that dos to his
runtime library and not application programs ;-P
AO> No, it is MS-Windows's DLL model that's totally against libtool grand
AO> idea. The developer must modify header files to be able to link with
AO> DLLs.
No, only *may need*.
AO> That's why libtool requires a special macro for the developer
AO> to tell libtool the package has been properly adapted to support DLLs.
I don't see how that macro saves developer from modifying headers.
Instead, what it does is turns "may need" to "must". Once again,
consider following possibilities:
1. Library has pure functional interface
2. Library has some data exports, but client never imports them.
3. Library has some data exports, and client does import them.
Only the third case requires modification of headers. And IMHO,
first two cases account for 80% of time.
AO> Not if it can't tell what is the preferrable directory. And, in
AO> general, it can't. I'd rather not do a partial job.
As for latter clause, I've got idea about that ;-) The same I
heard from Garry. I really cannot parse this binary preference -
either all or nothing. I'd rather have job done to the extent
possible, so I can continue where it stopped and not from the scratch.
Far less I'd like dumb computer program's trying to save me from my
hell on the basis that something "wrong" *might* happen (I reffer to
libtool behaviour of not building dlls unless --no-undef and
AC_*_WIN32 specified).
AO> Please remember that libtool is a stand-alone script, and there's
AO> nothing wrong in someone creating any library then telling libtool to
AO> install it anywhere at all. It doesn't have to be /usr/local/lib, or
AO> $(libdir). One could run, for example:
AO> libtool --mode=install install -c libgcc.la
/tmp/foobar/lib/gcc-lib/mn10300-elf/am33/libgcc.la
If those heuristics I wrote before tried, in the case above it
just can give up and install in the same dir as .la.
AO> Nope, this is not an ltconfig issue, it's a libtool issue. Remember,
AO> libtool is a stand-alone script, it's not package-dependent at all.
AO> I'd rather not change this.
But it is produced by ltconfig at compile time, isn't it?
AO> I'm not suggesting the addition of any additional directory. I'm only
AO> suggesting:
AO> libtool --mode=install --dlldir=$(bindir) install -c libgcc.la
/tmp/foobar/lib/gcc-lib/mn10300-elf/am33/libgcc.la
Who will add that --dlldir? I use libtool because many software
uses it, so I can encapsulate any knowledge about building of stupid
win32 dlls and use it immediately to build that many software! So I
put that knowledge, and while it has heuristical character (well,
building of shared libraries is quite complex domain ;-) ), that
"common sence" works pretty well in most cases.
AO> --
AO> Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135
