Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] 0.10.3 release later this week?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Olivier Biot" <ethereal@xxxxxxxxxx>
Date: Mon, 22 Mar 2004 23:28:57 +0100
It looks like the -Wl,--export-dynamic is the culprit on those
systems.

See for example:

http://sources.redhat.com/autobook/autobook/autobook_172.html

The code which sets this flag is in Makefile.am (see ethereal_LDFLAGS
for an example).

Could we as a trade-off add a configure option --without-shared-libs
which reverts to 0.10.2 non-shared libraries (libethereal from
libdfilter and libftypes; and libwiretap; however not sure about
libui) for those platforms giving compile problems today?

Regards,

Olivier

----- Original Message ----- 
From: Olivier Biot

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