Hi, Sofar several times we got hit by the very same OpenPKG specific issue of lack of separation of the system libraries and the OpenPKG environment.
An illustration: When compiling php from OpenPKG 2.2 the resulting binary is linked to the _system _ library libgcrypt dynamically. (This is new behavior in 2.2 and was not present before) Later when compiling Apache I noticed that Apache fails to build due to availability of libgcrypt. After removing the system / vendor provided libgcrypt library Apache built happily but I broke unknowingly php..... IMHO the current / long standing decision about how to deal with libraries within OpenPKG needs rediscussion. I have the strong impression that the current solution is not optimal. E.g. reconsidering a LD_LIBRARY type approach can be discussed. Bug like https://intevation.de/roundup/kolab/msg3293 really hurt us in the long run as it looks like side effects between upgrades are unpredictable. With purely shared libraries checking which libs actually got really compiled in the resulting binary is trivial while static linking needs much more difficult analyses before being able to figure out what is actually happening. Yours, -- martin "I am committed to helping Ohio deliver its electoral votes to the President next year." -- Wally O'Dell - CEO of Diebold, Inc. e r f r a k o n Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker ______________________________________________________________________ The OpenPKG Project www.openpkg.org Developer Communication List [EMAIL PROTECTED]
