Hi,
On 8/10/24 20:08, Navin P wrote:
When i run make -j1 i find all the object files libx.a but when i
do make -j8 i find some missing object files inside libx.a.
Typically you'd generate all objects first, then archive them in a
single invocation. This is I/O bound anyway, so you're not lo
Hi,
On 26.03.2018 18:57, Basin Ilya wrote:
> The expected drawback is a slower `make install`, but I'm fine with it.
That doesn't work for most use cases, where the build is running as an
user, while "make install" runs as root. "make install" should not write
anything to the build tree, because
Hi,
On 10.02.2016 17:49, Vadim Zeitlin wrote:
> *** Warning: Trying to link with static lib archive
> /opt/msw/i686-w64-mingw32/lib/libboost_filesystem.a.
> *** I have the capability to make that library automatically link in when
> *** you link to this library. But I can only do this if you ha
Hi,
On 06.07.2015 20:17, martin wrote:
> Random files are generated wth .loT file type.
Files ending in T are temporary files that are generated because some
compilers do not delete the output file on failure. These are renamed to
the same name without the T at the end of the build step they bel
Hi,
On 04.03.2013 07:23, Satz Klauer wrote:
> libtool --mode=compile g++ -Wall -fPIC -shared -Wno-unused [...]
> As far as I understood it, the statement "-export-symbols-regex
> mylib_" should ensure only functions starting with "mylib_" should be
> exported by the resulting library.
Indeed, h
Hi,
On Sun, Mar 28, 2010 at 05:33:44PM +0200, Ralf Wildenhues wrote:
> * doc/libtool.texi (FAQ, Stripped link flags): New nodes.
> (Wrapper executables): Replace bug address with macro.
> (Compile mode, Link mode): Document `-Wc,' and `-Xcompiler '
> semantics better.
Hmm, -Wc is
Hi,
I'm trying to use link time optimization with gcc 4.5, which somewhat
works :), but requires the compiler flags to be passed to the linking
step as well. libtool however removes them from the command line. Is
there any harm in passing them to the linking step?
Simon
signature.asc
Descrip
Hi,
I'm using libtool in a project that builds a few shared libraries, a
main program and plugins to the program, all in the same source package.
I've made Debian style packages from my source tree, which requires
installation into DESTDIR to work.
In the native case, this works:
/bin/sh ../lib
Hi,
I have a project with two libraries exposing different levels of detail
to the user, basically one provides (C++) base classes with some
functionality, and the other one provides classes derived from those
with the actual implementation.
Since the latter is going to change often, I'd rather n
Hi,
Paolo Bonzini schrieb:
In debian, libncurses.so is not installed unless libncurses-dev is also
installed. Therefore, programs should open libncurses.so.5 directly.
No. Ideally the installation script for your program would create a
symlink from a private directory for your program to th
Hi,
John Brown wrote:
> I gather that on Linux, you *can* create a shared library with undefined
> symbols.
Indeed.
> 1) Why would anyone do that intentionally?
To link against another library, or to import a symbol defined by the
main program or a library loaded by the main program before. T
Hello,
I'm trying to write testcases for a plugin loader (basically a C++
wrapper around ltdl that takes care of registering the new creators in
the factories), and for this, I need to link a plugin that is then
supposed to be loaded from the testcases.
For some reason, libtool builds said p
Hi,
a lot of projects that are just starting out still make quite a lot of
changes to their library ABI, so it does not make full sense to build a
shared library right away, but sometimes it is still necessary to have
PIC code around, for example when building a plugin to be dlopen()ed by
some pro
Hi,
Mike Frysinger wrote:
I don't know, but PIE and PIC don't compile to same thing AFAICT. I
don't know the significance of that though.
IIRC -pie is only a linker flag that
a) affects selection of the linker script
b) disallows certain relocation types
c) notes the position-independence
Hi,
a library I'm writing has the possibilty of being extended with plugins
that can be loaded with ltdl. In order to avoid having to export
lt_dlpreloaded_symbols from the main program to the library (thus making
prelinking impossible and being generally ugly and unportable). I'd like
to have a l
Hi,
Keith Packard wrote:
> I want the SONAME to be libXaw.so.6, but the filename to be libXaw6.la,
> libXaw6.so.6.0.1, libXaw6.so.6 and libXaw6.so
There is no need to name the real file libXaw6.so.6.0.1, as the 6 is
mentioned twice this way (libXaw.so.6.0.1 suffices). The unversioned
symlink and
Hi,
I have a shared library that internally uses plugins that are dlopened
(or dlpreopened). For this to work, I basically have the following options:
- Have the application load the list of preloaded symbols. This means
that the application programmer needs to be aware that my library uses
ltdl
Hi,
1) I have a C++ library that makes use of global constructors.
This should also work when using static libraries, as long as the global
constructors are contained within the same archive member as the object
they construct, and everyone who uses the result from a static
initialization also h
Hi,
> My intentions here are:
> Build the sources for libauthuserdb.la. Take their object code, and grab
> whatever modules from libauth.la that are references by stuff in
> libauthuserdb.la, and place all of that into a shared library.
Not possible without reimplementing parts of the linker.
Hi,
> This isn't about plugins, it's actually about a few helper libraries which
> are needed by the main program.
There is nothing to say against installing these libraries into
$(libdir), although you can also simply link them statically when they
are used by only one program (gives you a 5% s
Hi,
> However, I need these plugins to be in the same directory as where the main
> executable resides, and I cannot install them into one of the $blah/lib
> paths or add the current path to LD_LIBRARY_PATH.
This is a bad idea. Most likely, your program will end up in /usr/bin or
/usr/local/bin
Keith,
> I maintain a few X libraries and would like to see about transitioning
> them from imake to automake. The stumbling block is that I cannot change
> the library version numbers across this transition on any operating system.
To remain binary compatible, it suffices to have the same maj
Robert,
> Ok, here it is. This patch changes AC_LIBTOOL_PROG_COMPILER_PIC
> so that it only appends -DPIC to the default "C" tag and the CXX
> tag for C++. I would also like to deprecate -DPIC in the 1.5 release
> to make it clear we intend to do away with it. I would also like
> to ask anyone
Robert,
> I think you can ignore inline assembler for anything other than
> C (including C++). I've never thought about it, but inline assembler
> in Fortran code sounds truly frightening! Anyway, if it was so
> important, why doesn't the compiler define it for you?
Current gcc defines __PIC__
Robert,
> Ok then, I'll see if I can make "-DPIC" into
> a conditionally-set thing that would be set to "" for anything
> but C and C++. Can we agree on that? ;)
Yes, although it would be nice if the other languages also had a way of
knowing they should emit PIC, at least if they allow condition
Hi,
> Good point, we never really resolved this issue.
> All in favor of dropping -DPIC entirely say "I"!
I'm against it.
If you have optimized assembler versions of some code for some platforms
(like the STL has, for example) and some of that code is not PIC, it is
a good idea to enclose it i
26 matches
Mail list logo
