[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AM_LDFLAGS += -no-undefined

From: Bob Friesenhahn
Subject: Re: AM_LDFLAGS += -no-undefined
Date: Tue, 8 Apr 2014 12:01:55 -0500 (CDT)
User-agent: Alpine 2.01 (GSO 1266 2009-07-14)

On Tue, 8 Apr 2014, Akim Demaille wrote:

Since then, I realized that building libltdl as part of the project was prohibitive, costly, and dangerous. It was better to rely on libltdl to be a formally installed dependency on the system. Now GraphicsMagick treats libltdl just like any other external library and life is much improved. I would encourage any other package to not bundle libltdl and to simply document that it must already be installed on the system.

What do you mean by dangerous?  In case of mixture of versions I guess?
This is probably a problem for libraries that likely to be linked in
a program that links with even more libraries.

Libltdl is likely managed by a package manager on the system since it is a common component on any GNU/Linux system and other free systems. By embedding libltdl in some other application or library, the users of that application or library may overwrite the libltdl installed by the package manager. The configure options to manage this are confusing.

And for "prohibitive and costly", I'd be happy too to have some details :)
It's not too big, and very fast to build (compared to the remainder
of my severely-templated C++ libraries, it is perfectly negligible).

The ltdl configure script bits take a long time to run and make the configure script larger. With the recursive build, the build time is not worth worrying about.

Bob Friesenhahn
GraphicsMagick Maintainer,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]