Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 374699 - dev-libs/lzo need LDFLAGS -no-undefined to build DLL for CHOST *-*-mingw32
Summary: dev-libs/lzo need LDFLAGS -no-undefined to build DLL for CHOST *-*-mingw32
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Nathan Phillip Brink (binki) (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on: 515238
Blocks:
  Show dependency tree
 
Reported: 2011-07-10 13:08 UTC by Bertrand Jacquin
Modified: 2014-06-30 12:19 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
dev-libs:lzo-2.04:20110710-130911.log (dev-libs:lzo-2.04:20110710-130911.log,76.43 KB, text/plain)
2011-07-10 13:10 UTC, Bertrand Jacquin
Details
lzo-2.06-mingw32-dll.patch (lzo-2.06-mingw32-dll.patch,580 bytes, patch)
2013-04-24 08:16 UTC, Nathan Phillip Brink (binki) (RETIRED)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bertrand Jacquin 2011-07-10 13:08:22 UTC
Without the LDFLAGS -no-undefined lzo build static library, but not the shared one as the following is reported :


/bin/sh ../libtool  --tag=CC   --mode=link i686-w64-mingw32-gcc   -Os -pipe  -fomit-frame-pointer  -version-info 2:0:0 -L/usr/i686-w64-mingw32/lib -L/usr/i686-w64-mingw32/usr/lib -o liblzo2.la -rpath /usr/lib lzo_crc.lo lzo_init.lo lzo_ptr.lo lzo_str.lo lzo_util.lo lzo1.lo lzo1_99.lo lzo1a.lo lzo1a_99.lo lzo1b_1.lo lzo1b_2.lo lzo1b_3.lo lzo1b_4.lo lzo1b_5.lo lzo1b_6.lo lzo1b_7.lo lzo1b_8.lo lzo1b_9.lo lzo1b_99.lo lzo1b_9x.lo lzo1b_cc.lo lzo1b_d1.lo lzo1b_d2.lo lzo1b_rr.lo lzo1b_xx.lo lzo1c_1.lo lzo1c_2.lo lzo1c_3.lo lzo1c_4.lo lzo1c_5.lo lzo1c_6.lo lzo1c_7.lo lzo1c_8.lo lzo1c_9.lo lzo1c_99.lo lzo1c_9x.lo lzo1c_cc.lo lzo1c_d1.lo lzo1c_d2.lo lzo1c_rr.lo lzo1c_xx.lo lzo1f_1.lo lzo1f_9x.lo lzo1f_d1.lo lzo1f_d2.lo lzo1x_1.lo lzo1x_9x.lo lzo1x_d1.lo lzo1x_d2.lo lzo1x_d3.lo lzo1x_o.lo lzo1x_1k.lo lzo1x_1l.lo lzo1x_1o.lo lzo1y_1.lo lzo1y_9x.lo lzo1y_d1.lo lzo1y_d2.lo lzo1y_d3.lo lzo1y_o.lo lzo1z_9x.lo lzo1z_d1.lo lzo1z_d2.lo lzo1z_d3.lo lzo2a_9x.lo lzo2a_d1.lo lzo2a_d2.lo lzo1c_s1.lo lzo1c_s2.lo lzo1f_f1.lo lzo1f_f2.lo lzo1x_f1.lo lzo1x_f2.lo lzo1x_s1.lo lzo1x_s2.lo lzo1y_f1.lo lzo1y_f2.lo lzo1y_s1.lo lzo1y_s2.lo -lwinmm
libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32 shared libraries

inheriting to flag-o-matic and adding "append-ldflags -no-undefined" in src_configure resolv this

Reproducible: Always

Steps to Reproduce:
1. i686-w64-mingw32-emerge -vat lzo 
2.
3.
Comment 1 Bertrand Jacquin 2011-07-10 13:10:54 UTC
Created attachment 279605 [details]
dev-libs:lzo-2.04:20110710-130911.log
Comment 2 Pacho Ramos gentoo-dev 2011-07-10 18:08:58 UTC
"emerge --info" output please?
Comment 3 Bertrand Jacquin 2011-07-10 19:49:01 UTC
Portage 2.1.10.4 (embedded, gcc-4.5.2, unavailable, 2.6.38-gentoo-r1 x86_64)
=================================================================
System uname: Linux-2.6.38-gentoo-r1-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q9650_@_3.00GHz-with-gentoo-2.0.3
Timestamp of tree: Sun, 10 Jul 2011 13:45:01 +0000
app-shells/bash:          4.2_p10
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.7.2, 3.2
dev-util/cmake:           2.8.4-r1
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.0.3
sys-apps/openrc:          0.8.3-r1
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.68
sys-devel/automake:       1.9.6-r3, 1.11.1-r1
sys-devel/binutils:       2.21.1
sys-devel/gcc:            4.5.2
sys-devel/gcc-config:     1.4.1-r1
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r1
sys-kernel/linux-headers: 2.6.38 (virtual/os-headers)
sys-libs/glibc:           2.13-r3
Repositories: gentoo meleeweb dberkholz sunrise enlightenment
ACCEPT_KEYWORDS="x86 ~x86"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-Os -pipe  -fomit-frame-pointer"
CHOST="i686-w64-mingw32"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-Os -pipe  -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="assume-digests binpkg-logs buildpkg distlocks ebuild-locks fixlafiles fixpackages nodoc noinfo noman parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS=""
GENTOO_MIRRORS=" http://ftp.free.fr/mirrors/ftp.gentoo.org"
LDFLAGS="-L/usr/i686-w64-mingw32/lib -L/usr/i686-w64-mingw32/usr/lib"
LINGUAS="en"
MAKEOPTS="-j6"
PKGDIR="/usr/i686-w64-mingw32/packages/"
PORTAGE_CONFIGROOT="/usr/i686-w64-mingw32/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/usr/i686-w64-mingw32/tmp/"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/opt/meleeweb/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="bindist kdrive make-symlinks minimal modules multicall x86 zlib" ELIBC="mingw" INPUT_DEVICES="evdev mouse keyboard tslib" KERNEL="linux" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="fbdev" 
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 4 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2013-04-24 08:16:12 UTC
Created attachment 346458 [details, diff]
lzo-2.06-mingw32-dll.patch

I’ll suggest this trival change to upstream.

It does make sense for upstreams, I think, to use -no-undefined in cases where the shared object cleanly and directly depends on other dynamic objects. The only case where -no-undefined probably shouldn’t be in target_LDFLAGS is in some odd scenario where the libraries providing certain symbols will only ever be loaded by dlopen()ing particular libraries before dlopen()ing the shared object or through LD_PRELOAD. I.e., -no-undefined applies to almost all situations and is the rule rather than the exception. It is too bad that libtool defaults to assuming that undefined symbols is normal.

I don’t expect many Windows users of liblzo to be inclined to want the DLL version, but it is nice to be able to provide it if desired and this patch permits that.
Comment 5 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2013-04-24 08:24:54 UTC
Patch sent upstream, pending upstream coordination.
Comment 6 Nathan Phillip Brink (binki) (RETIRED) gentoo-dev 2013-05-24 04:16:06 UTC
Upstream reports that they have already made this change in their development tree and it will show up in the next version, so I will put this patch in a new ebuild revision since upstream has no issue with it.
Comment 7 Bertrand Jacquin 2013-06-11 21:03:50 UTC
(In reply to Nathan Phillip Brink (binki) from comment #6)
> Upstream reports that they have already made this change in their
> development tree and it will show up in the next version, so I will put this
> patch in a new ebuild revision since upstream has no issue with it.

Thanks @binki, it seems it's not included in current portage tree.
Comment 8 Samuli Suominen (RETIRED) gentoo-dev 2014-06-30 12:17:11 UTC
looks like this patch is included in upstream lzo2-2.0.8 release, so adding bug 515238 to deps, from which 2.08 will be added to Portage
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2014-06-30 12:19:09 UTC
2.0.8 in portage