[lttng-dev] dlopen, gcc -l and LD_PRELOAD

[David OShea]

Hi all,

> -----Original Message-----
> From: Jérémie Galarneau [mailto:jeremie.galarneau at efficios.com]
> Sent: Tuesday, 19 March 2013 7:28 AM
> To: Thibault, Daniel
> Cc: lttng-dev at lists.lttng.org
> Subject: Re: [lttng-dev] dlopen, gcc -l and LD_PRELOAD


> > Good question. I think this problem has been fixed as part of the 2.1
> release. However, I do know there are other issues related to
> "dlopen()"-ing probe providers; details on the bug tracker[1].
> >
> > Jérémie
> > [1] https://bugs.lttng.org/issues/447
> > -----Fin du message d'origine-----
> >
> >    Bug 447 concerns dlclose(), not dlopen().  It's a legitimate
> concern (that has yet to be addressed, it seems), but it has nothing to
> do with potential delays or deadlocks upon calling dlopen() on a
> tracepoint provider.

[...]

> Typically, you would want to do one or the other [dlopen or
> LD_PRELOAD]. But to answer your question, yes, this would workaround
> the locking problem described in the man page that affected prior
> versions of lttng-ust (before 2.1).

FYI I mentioned my email to this list dated 25/Feb/2013 that:

"I noticed that commit ID b834deadbfa8a78ae1d00440fd91c41dfd351eba changed README to remove a note suggesting that dlopen() not be used.  It looks like the same change should be made to doc/man/lttng-ust.3, which still suggests that you not use dlopen()."

Just a reminder that it does appear to have been intended that that note be removed, so it should probably be disregarded.

Also, if anyone is able to provide explanations for the questions in my previous email, that might serve to address the topic of this thread too.

Thanks,
David

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.