From: Gerald Combs
| All,
|
| I'd like to release 0.10.3 on Wednesday or Thursday in order to take
| care of the problems in
|
| http://www.ethereal.com/appnotes/enpa-sa-00013.html
|
| If anyone needs to postpone the release, please let me know.
I don't know if this is a reason for postponing the release, but as
such Ethereal will *not* compile on either MinGW or CygWin or even AIX
as the shared libethereal (and other ones) still contains unresolved
symbols, something forbidden on those (Win32, AIX) systems.
For the sake of completeness I added some relevant text below:
<include>
I never understood "-no-undefined" to operate in that manner. From
the
GNU Autotools book
(http://sources.redhat.com/autobook/autobook/autobook_88.html#SEC88):
`-no-undefined'
Modern architectures allow us to create shared libraries with
undefined symbols, provided those symbols are resolved (usually by the
executable which loads the library) at runtime. Unfortunately, there
are
some architectures (notably AIX and Windows) which require that all
symbols are resolved when the library is linked. If you know that your
library has no unresolved symbols at link time, then adding this
option
tells libtool that it will be able to build a shared library, even on
architectures which have this requirement.
That wording has always given me the impression that shared libraries
simply would not be built on platforms that don't allow undefined
symbols at link time unless you pass the flag. It doesn't say
anything
about changing the behavior on platforms that do support undefined
symbols in shared libraries at link time.
</include>
Regards,
Olivier
