Mirror of the lttng-dev mailing list
 help / color / mirror / Atom feed
From: sboisvert@gydle.com (Sebastien Boisvert)
Subject: [lttng-dev] Building URCU in a Cygwin 64 environment
Date: Tue, 31 May 2016 11:12:19 -0400	[thread overview]
Message-ID: <574DA9D3.5070903@gydle.com> (raw)
In-Reply-To: <574DA411.3000603@efficios.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]

Hi Jonathan,

Thank you for looking into this. I appreciate.

It sounds like I have a solution in hand to continue. That's great.

I just read the text in the web page referenced by the link [1] that you kindly provided to me.
This is interesting. Now I know a little bit more about this.

So, Linux can have 'chains of dependencies of potentially infinite length' whereas Windows
is limited to shared library DLL files that can not depend on other DLL files; knowing the dependencies
is the job of a .exe file and these dependencies must be known at link time.

TIL

+1

On 05/31/2016 10:47 AM, Jonathan Rajotte Julien wrote:
> Hi Sebastien,
> 
> I'll simply move the conversation here (from IRC) to have an archive of it.
> 
> On 2016-05-31 09:39 AM, Sebastien Boisvert wrote:
>> Hi,
>>
>> I am in the process of writing a blog article on the use of the LTTng-UST userspace event tracer on Windows.
>>
>> I am building urcu and LTTng-UST in a Cygwin 64 environment. Then, I plan to use LTTng in Visual Studio Community, so I mostly need headers (.h) and shared libraries (.dll).
> 
> Nice!
> 
>>
>> When I am building urcu (0.9.2), I get this message:
>>
>> libtool: link: warning: undefined symbols not allowed in x86_64-unknown-cygwin shared libraries
> 
> This seems related to a Windows restriction regarding inter-library dependencies [1], the relevant part:
> 
> "Some platforms, such as Windows, do not even allow you this flexibility. In order to build a shared library, it must be entirely self-contained or it must have dependencies known at link time (that is, have references only to symbols that are found in the .lo files or the specified ‘-l’ libraries), and you need to specify the -no-undefined flag. By default, libtool builds only static libraries on these kinds of platforms."
> 
> Looks like the -no-undefined might be a good start judging from this patch I found for the urcu cygwin port in yacp [2].
> 
> Cheers!
> 
> [1] https://www.gnu.org/software/libtool/manual/libtool.html#Inter_002dlibrary-dependencies
> [2] https://github.com/fd00/yacp/blob/master/userspace-rcu/userspace-rcu-0.8.7-1bl1.src.patch
>>
>> The immediate consequence seems to be the absence of .dll files in the urcu build that I am generating. Otherwise, the build contains static library files and headers.
>>
>> However, I suppose that the .a static library files also have undefined symbols as I am getting linking issues when building LTTng-UST.
>>
>> Do you have a clue of what may be the issue here ? Otherwise, I will continue my investigation and get around the issue eventually.
>> _______________________________________________
>> lttng-dev mailing list
>> lttng-dev at lists.lttng.org
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 


  reply	other threads:[~2016-05-31 15:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-31 13:39 Sebastien Boisvert
2016-05-31 14:47 ` Jonathan Rajotte Julien
2016-05-31 15:12   ` Sebastien Boisvert [this message]
2016-05-31 21:52   ` Mathieu Desnoyers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=574DA9D3.5070903@gydle.com \
    --to=sboisvert@gydle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox