In the changelog of glpk-4.50:
Though API was not changed since 4.49, symbols _glp_lpx_* were
removed from the export list, hence 35:0:0.
Seems like ppl relies on them because it fails to compile against API 35:0:0.
Steps to Reproduce:
1. emerge glpk-4.50
2. emerge ppl
ppl fails to compile.
Portage 18.104.22.168 (default/linux/amd64/13.0/desktop/kde, gcc-4.6.4, glibc-2.15-r3, 3.8.13-gentoo x86_64)
System uname: Linux-3.8.13-gentoo-x86_64-Intel-R-_Core-TM-_i5_CPU_M_580_@_2.67GHz-with-gentoo-2.2
KiB Mem: 7954528 total, 1183352 free
KiB Swap: 4095996 total, 3975584 free
Timestamp of tree: Sat, 15 Jun 2013 01:45:01 +0000
ld GNU ld (GNU Binutils) 2.22
dev-lang/python: 2.7.3-r3, 3.2.3-r2
sys-devel/autoconf: 2.13, 2.69
sys-devel/automake: 1.11.6, 1.12.6
sys-devel/gcc: 4.6.4, 4.7.3, 4.8.1
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
Repositories: gentoo x11 seden sunrise science dmol kde lisp scarabeus floppym mv zugaina java local
ACCEPT_LICENSE="* -@EULA AdobeFlash-11.x skype-eula Google-TOS google-talkplugin skype-22.214.171.124-copyright google-chrome Oracle-BCLA-JavaSE"
CFLAGS="-O2 -pipe -w -march=native"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share/polkit-1/actions /usr/share/themes/oxygen-gtk/gtk-2.0 /var/lib/hsqldb"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -pipe -w -march=native"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTDIR_OVERLAY="/var/lib/layman/x11 /var/lib/layman/seden /var/lib/layman/sunrise /var/lib/layman/science /var/lib/layman/dmol /var/lib/layman/kde /var/lib/layman/lisp /var/lib/layman/scarabeus /var/lib/layman/floppym /var/lib/layman/mv /var/lib/layman/zugaina /var/lib/layman/java /usr/local/portage"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Created attachment 350974 [details]
build.log for failed compile.
Build fails because it cannot find the symbols that were removed.
CC-ing glpk maintainers in case they can help with updating ppl. (By the way, why is the glpk ebuild using EAPI5 but not setting a subslot when libglpk soname version changes?)
ppl can't be updated without breaking gcc. it needs to be installed into a new SLOT.
Created attachment 351278 [details]
Same problem here. I was able to pull some more out in the backtrace, looks like my unicode is from a different local. Hope this helps, real show stopper on my end.
For now you could make ppl depend on <=glpk-4.48, so that users don't run into this problem.
(In reply to Ryan Hill from comment #6)
Hey Ryan, could you please remove the build glpk-4.48 build dependency for ppl -0.12.1-r1? glpk-4.50 is already a global mask, which I've unmasked for use in other builds. While I am anxious in ppl-0.x implementing working linear programming with glpk-4.50, I have extensive builds with benched lapack. As I just *KNOW* the ppl guys & gals are all about extending ppl's already capably functional linear programming extensions, I already went ahead with glpk-4.50 on my system. Your mask is redundant against the global mask and renders portage useless for me in certain circumstances. While dev-libs/ppl is not a fugazi library , */for that insane prune crazy management (*not* the gentoo way)/* , I am a patient boy.
Rhetorical: Every find an amazing function in a *useless* program? gcc / glibc does all the time...
I'd prefer the dependencies were accurate. If this is preventing you from installing 4.50 can't you temporarily disable the lpsol USE flag? (it'll be broken anyways). Or copy ppl-0.12-1-r1 into an overlay and remove the version from the dependency.
(In reply to Ryan Hill from comment #8)
> I'd prefer the dependencies were accurate. If this is preventing you from
> installing 4.50 can't you temporarily disable the lpsol USE flag? (it'll be
> broken anyways). Or copy ppl-0.12-1-r1 into an overlay and remove the
> version from the dependency.
Since when is glpk a dependency for anything? I already have 4.50 on my machine... and it is the first and only instance of glpk on my machine. ppl never needed it before? Now with it listed as a dependency @world is complaining. I can't even run haskell-updater (which is not compiling anything but dev-haskell) without it telling me to unmask and downgrade to glpk-4.48... although, I suppose I could tell it to use a different package manager.. BUT why do I need to?
How was this issue NOT addressed by masking glpk-4.50 globally? I choose to keep 4.50 installed, and compile GHC over and over, until ppl addresses this issue and mends my graphite. I do not believe that glpk is,was, or should be listed as a dependency for ppl... am I that far off base here? For those who downgraded more power to you, in my opinion there will be errata in the other packages that have used 4.50 already, namely GHC. So again, why do I HAVE to downgrade or use it at all? I'll live with the error compiling ppl, which is a package that I have not compiled against glpk yet anyways... but I would like to be able to compile my @world up to ppl.
(In reply to Jason Mours from comment #9)
Jason, I think Ryan is perfectly correct about the dependencies. It sounds like you have accidentally enabled USE=lpsol for dev-libs/ppl when you don't really want/need it. You should check those USE flag settings and jump onto the forums or IRC if you can't get it to behave how you want.
> Since when is glpk a dependency for anything?
glpk is a dependency of ppl when the lpsol USE flag is enabled. This has always been the case. Nothing has changed here. Perhaps you never noticed because you had it installed already?
> How was this issue NOT addressed by masking glpk-4.50 globally?
Because eventually it will be unmasked? We have to keep old versions of ppl around indefinitely (different gcc versions require specific versions of ppl and we don't remove old gcc versions) and I'd really like it if they actually build.
> I do not believe that glpk is,was, or should be listed as a dependency for
> ppl... am I that far off base here?
Well it'll error out during configure if glpk is not installed, so I would say yes.
> So again, why do I HAVE to downgrade or use it at all?
You don't. The whole point of having the lpsol USE flag is so people don't have to install glpk. Disable it and carry on.
No I stand corrected. lspol is a use flag I have stated in package.use from over a month ago.
I installed glpk after I saw 4.50 listed packages >10 days ago, and not from implementing the use flag, as it was cited [N] when I pulled it in.
But I'm sure I'm wrong in this instance. I apologize Ryan.
The new glpk-4.53 may allow for an easy fix; please see https://bugs.gentoo.org/show_bug.cgi?id=501320 for more info.
(In reply to Erik Quaeghebeur from comment #13)
> The new glpk-4.53 may allow for an easy fix; please see
> https://bugs.gentoo.org/show_bug.cgi?id=501320 for more info.
To be more explicit, there are now files lpx.h and lpx.c that one can add to any 4.48-compatible project to make it compile with 4.53+ glpk versions. Literally, from glpk-4.54/examples/oldapi:
"The program module in this subdirectory contains an implementation of
the old GLPK API as it was defined in GLPK 4.48.
To compile an existing project using the old GLPK API you need to add
to the project two files lpx.h and lpx.c.
Please note that you may mix calls to old and new GLPK API routines in
the same project (except calls to glp_create_prob and glp_delete_prob).
The file lpxsamp.c is an example that illustrates using the old GLPK
Would this allow for the block on glpk > 4.48 to be lifted, or is there something else in play?
ppl-1.1 is in the tree now and i think that means everything shakes out OK
(In reply to SpanKY from comment #15)
> ppl-1.1 is in the tree now and i think that means everything shakes out OK
I see that the new ppl-1.1 ebuild still requires <=glpk-4.48 -- is that restriction meant to be lifted now?
(In reply to Jeremy Murphy from comment #16)
should be fixed now, thanks