Installing Perl modules in @INC
I have a package that uses Perl modules that I would like installed in @INC, e.g., in /usr/share/perl5. Searching through the Automake list archives, the most relevant thread I was able to locate was: http://sourceware.org/ml/automake/2003-05/msg00069.html However, the solution suggested therein spoke of using Stow, while I wish to stick to an Autotools-only setup, where the Perl modules are installed in @INC. I suppose hard-coding perllibdir = $(pkgdatadir)/perl5 would not really be a good idea, or would it? I would appreciate any pointers. Youssef Eldakar Bibliotheca Alexandrina
Re: Creating a partial library
On Wed, Feb 3, 2010 at 03:39, Justin Seyster jrs...@gmail.com wrote: I'm working on a support framework for plug-ins, and I'm struggling to come up with a way to compile it. I'm leaning towards building it as a convenience library, but there a few SNAFUs. Each plug-in is itself a shared library. I would like to avoid having a second shared library that the plug-in relies on for a couple of reasons. Mostly, I think that the extra dependency would make it difficult to distribute plug-ins built with the framework, but I'm also worried that reverse dependencies in the framework would break if there are multiple plug-ins loaded that link the framework. I'm pretty sure that making the framework a convenience library is my ideal solution: the plug-in author will be able to distribute a single shared object without any non-standard dependencies. However, I read that Automake does not allow installing a convenience library. I verified that a regular static library (not specified with noinst_LTLIBRARIES) definitely does not work: the resulting .a file is not position independent and won't link into a plug-in. I don't want to use noinst_LTLIBRARIES, though, for the simple reason that I want to be able to install the library! Is it worth my while to figure out a hack to make a convenience library install, or is there a better approach for linking this kind of framework using Automake? Thanks. There is two things: o first is that you can obtain what you want (static PIC library); and o second is that you should not do that Abous static PIC libraries: You may hint libtool to use PIC code for static library using -prefer-pic option and per-target flags. E.g. for library libfoo.a: LTLIBRARIES = libfoo.la libfoo_la_CFLAGS = -prefer-pic libfoo_la_LDFLAGS = -static -prefer-pic Of course, you can use other language related flags (e.g. libfoo_la_CXXFLAGS for C++) instead of or in addition to the libfoo_la_CFLAGS if you use some other language instead of or in addition to the C. About why you should not to do that: If you link static library into two (or more) modules then after loading the parent process will have two (or more) symbols with one and the same name. With all pain as consequence. What if these symbols are functions and corresponds to two different version of your library? What if they are global variables, which correspond to mutexes? I can imagine the case (and saw it indid) when these mutexes are not sqashed into one and therefore don't protect anything. And so on and so on... Therefore, the safest way is to link your framework into main process (and only into main process) and let the main process to provide these framework functions to the modules loaded by him. -- Andrew W. Nosenko andrew.w.nose...@gmail.com
Re: Creating a partial library
On Wed, Feb 3, 2010 at 8:33 AM, John Calcote john.calc...@gmail.com wrote: (PIC-based static only) library is to use the noinst prefix. But libtool can be used to manually install a convenience library, so you could use libtool to do this in an install-exec-local rule in the Makefile.am file that builds (for instance) libhello.a (untested): install-exec-local: libtool --mode=install ./install-sh -c libhello.a $(DESTDIR)$(lib)/libhello.a This example came from the libtool manual (modified slightly for Automake context). ohh this is interesting. Isn't this breaking `make uninstall' and thus `make distcheck'? Would it be possible (better/suited/correct) to have some lib_LIBRARIES=libother.a with a custom build rule that simply copies the file? Then make install/uninstall could work, but maybe this breaks other things? oki, Steffen
Re: Creating a partial library
On Wed, 3 Feb 2010, Andrew W. Nosenko wrote: Therefore, the safest way is to link your framework into main process (and only into main process) and let the main process to provide these framework functions to the modules loaded by him. I find it convenient to have loadable modules depend on a shared library which provides the run-time functionality that they need. This is portable, and it works great. I agree that depending on optional/chancy PIC functionality is a bad plan and that allowing symbol collision is also fraught with peril. Lazy symbol resolution could allow a module to resolve the symbol in the static library part introduced by another module. When that module is later unloaded, then things go boom since the code being used is no longer present. There is also the small matter of wasted memory if duplicate code is loaded. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: silent installs
John Calcote wrote: On 1/29/2010 10:17 AM, Steffen Dettmer wrote: On Fri, Jan 29, 2010 at 5:21 PM, Bob Friesenhahn Regarding silent installs: Why do passenger trains have windows? Why do passenger train windows have curtains? Okay - I can't help it! I bet the engineer's windows don't have curtains. Probably no curtains, but they do have windshield wiper to clear away the cruft. -- William Pursell
Re: How to handle data/script files in a VPATH build ?
Hello Sylvestre, Sylvestre Ledru wrote: In my Makefile.am, I have: all-local: macros macros: $(top_builddir)/bin/myscript $(top_builddir)/bin/myscript $(top_builddir)/dataDir/myData.sci Obviously, this works when I am building my application in the source tree but it fails when building as VPATH. It is not clear what you wanna accomplish and why it doesn't work as you desire. I cannot change top_builddir by top_srcdir since I need both the data and script to be available in the build tree. Are myscript and myData.sci distributed or built? Why do you need them in the build tree? Cheers, Peter -- Peter Johansson svndigest maintainer, http://dev.thep.lu.se/svndigest yat maintainer, http://dev.thep.lu.se/yat
Re: Creating a partial library
Steffan, On 2/3/2010 5:50 AM, Steffen Dettmer wrote: On Wed, Feb 3, 2010 at 8:33 AM, John Calcotejohn.calc...@gmail.com wrote: (PIC-based static only) library is to use the noinst prefix. But libtool can be used to manually install a convenience library, so you could use libtool to do this in an install-exec-local rule in the Makefile.am file that builds (for instance) libhello.a (untested): install-exec-local: libtool --mode=install ./install-sh -c libhello.a $(DESTDIR)$(lib)/libhello.a This example came from the libtool manual (modified slightly for Automake context). ohh this is interesting. Isn't this breaking `make uninstall' and thus `make distcheck'? Would it be possible (better/suited/correct) to have some lib_LIBRARIES=libother.a with a custom build rule that simply copies the file? Then make install/uninstall could work, but maybe this breaks other things? The trouble with LIBRARIES is that it only builds non-PIC static libraries, which can't be linked into a libtool shared library. My example has a couple of minor flaws that I realized last night after sending it, including the missing uninstall-local rule: install-exec-local: libtool --mode=install ./install-sh -c libhello.a $(DESTDIR)$(libdir)/libhello.a uninstall-local: rm -f $(DESTDIR)$(libdir)/libhello.a John
RE: silent installs
Probably no curtains, but they do have windshield wiper to clear away the cruft. The light rail trolleys around where I live also have pull-down sun shades to protect the driver from glare. :-) /me will stop now --- William Tracy
Re: Creating a partial library
Thanks, this advice gives me exactly what I asked for (even if it turns out that's not what I really wanted :-). I agree entirely that putting the framework into the main program is a good solution, but I'm not involved with the main program's development, so that's not an option for me. Right now I don't want any state to be shared between separate instances of the framework, so the scenario you mentioned (of global variables not being squashed) is actually what I want. I believe that I can ensure that exact behavior across the whole framework by compiling it with -fvisibility=hidden. Hidden visibility also seems to make sure that calls into the framework link only against their own copies (i.e., if two plug-ins use two different versions of the framework, the two plug-ins won't start calling the wrong versions of the framework functions). My hope is that this approach will protect users of the framework from the most possible hidden linking danger. --Justin On Wed, Feb 3, 2010 at 5:17 AM, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Wed, Feb 3, 2010 at 03:39, Justin Seyster jrs...@gmail.com wrote: I'm working on a support framework for plug-ins, and I'm struggling to come up with a way to compile it. I'm leaning towards building it as a convenience library, but there a few SNAFUs. Each plug-in is itself a shared library. I would like to avoid having a second shared library that the plug-in relies on for a couple of reasons. Mostly, I think that the extra dependency would make it difficult to distribute plug-ins built with the framework, but I'm also worried that reverse dependencies in the framework would break if there are multiple plug-ins loaded that link the framework. I'm pretty sure that making the framework a convenience library is my ideal solution: the plug-in author will be able to distribute a single shared object without any non-standard dependencies. However, I read that Automake does not allow installing a convenience library. I verified that a regular static library (not specified with noinst_LTLIBRARIES) definitely does not work: the resulting .a file is not position independent and won't link into a plug-in. I don't want to use noinst_LTLIBRARIES, though, for the simple reason that I want to be able to install the library! Is it worth my while to figure out a hack to make a convenience library install, or is there a better approach for linking this kind of framework using Automake? Thanks. There is two things: o first is that you can obtain what you want (static PIC library); and o second is that you should not do that Abous static PIC libraries: You may hint libtool to use PIC code for static library using -prefer-pic option and per-target flags. E.g. for library libfoo.a: LTLIBRARIES = libfoo.la libfoo_la_CFLAGS = -prefer-pic libfoo_la_LDFLAGS = -static -prefer-pic Of course, you can use other language related flags (e.g. libfoo_la_CXXFLAGS for C++) instead of or in addition to the libfoo_la_CFLAGS if you use some other language instead of or in addition to the C. About why you should not to do that: If you link static library into two (or more) modules then after loading the parent process will have two (or more) symbols with one and the same name. With all pain as consequence. What if these symbols are functions and corresponds to two different version of your library? What if they are global variables, which correspond to mutexes? I can imagine the case (and saw it indid) when these mutexes are not sqashed into one and therefore don't protect anything. And so on and so on... Therefore, the safest way is to link your framework into main process (and only into main process) and let the main process to provide these framework functions to the modules loaded by him. -- Andrew W. Nosenko andrew.w.nose...@gmail.com
Re: Creating a partial library
On Wed, 3 Feb 2010, Justin Seyster wrote: My hope is that this approach will protect users of the framework from the most possible hidden linking danger. Since 9/11, 'hope' is not sufficient protection in today's world. Not all systems are capable of producing a 'partial' library, leaving some symbols unresolved and without knowing where the symbols will come from. Systems which come to mind which don't support this are Microsoft Windows and IBM's AIX. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Installing Perl modules in @INC
I apologize for that unintentional reposting in my previous e-mail with this same subject. Youssef Eldakar Bibliotheca Alexandrina
