libtool
[Top][All Lists]
Advanced

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

pic-only option not working as expected


From: John Calcote
Subject: pic-only option not working as expected
Date: Sat, 22 Jan 2011 12:42:33 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7

I'm trying to create a libtool static library (a shared library is not needed in this case) that can be used as part of a shared library in another project. Thus, I need to ensure that PIC code is used in the static library. Since this is a private project, I wanted to set the defaults in 'LT_INIT' to attain my goals without having to insist that the user specify various options on the 'configure' command line. Here's my 'LT_INIT' macro call in 'configure.ac':

...
LT_INIT([disable-shared static pic-only])
...


While playing with these options, I noticed that the 'disable-shared' and 'static' options seem to have the desired effect, but the 'pic-only' option does not. Whether I use 'pic-only' or not, I get the following output from 'configure --help':

...
Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-pic              try to use only PIC/non-PIC objects [default=use
                          both
]
  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
...

When using the 'pic-only' option in 'LT_INIT', would expect to see the following output:

...
Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-pic              try to use only PIC/non-PIC objects [default=use
                          pic only
]
  --with-gnu-ld           assume the C compiler uses GNU ld [default=no]
...

Of course, the result of this apparent discrepancy is that my user is forced to use '--with-pic' on the 'configure' command line in order to get a static library that is usable within a shared library.

While looking for a solution, I found this thread (from Oct 2010) on the libtool mailing list:

   http://www.mail-archive.com/address@hidden/msg12408.html

Because this thread is so recent, I'm wondering if this issue ever been resolved (or even noticed) by the libtool maintainers.

Thanks in advance,
John

reply via email to

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