public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
* libtool can't build shared library unless -no-undefined specified
@ 2024-05-16 20:24 Brian Inglis
  2024-05-16 21:45 ` Ken Brown
  0 siblings, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2024-05-16 20:24 UTC (permalink / raw)
  To: Cygwin Apps

Hi folks,

Trying to update dateutils, autotools build fails with:

libtool: error: can't build x86_64-pc-cygwin shared library unless -no-undefined 
is specified

Suggestions for overrides or fixes?

Tried:

LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"

CYGCONF_ARGS="
	 --enable-contrib
	 --enable-tzmap-fetch
	 lt_no_undefined_flag=--no-undefined
	 no_undefined_flag=--no-undefined
"

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: libtool can't build shared library unless -no-undefined specified
  2024-05-16 20:24 libtool can't build shared library unless -no-undefined specified Brian Inglis
@ 2024-05-16 21:45 ` Ken Brown
  2024-05-17  4:50   ` Brian Inglis
  0 siblings, 1 reply; 6+ messages in thread
From: Ken Brown @ 2024-05-16 21:45 UTC (permalink / raw)
  To: cygwin-apps

On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:
> Hi folks,
> 
> Trying to update dateutils, autotools build fails with:
> 
> libtool: error: can't build x86_64-pc-cygwin shared library unless 
> -no-undefined is specified
> 
> Suggestions for overrides or fixes?
> 
> Tried:
> 
> LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"
> 
> CYGCONF_ARGS="
>       --enable-contrib
>       --enable-tzmap-fetch
>       lt_no_undefined_flag=--no-undefined
>       no_undefined_flag=--no-undefined

You and I discussed this a few years ago in connection with curl.  The 
solution there, and in most similar cases, is to add -no-undefined to 
the appropriate lib*_la_LDFLAGS variable(s) in Makefile.am.  See

   https://cygwin.com/pipermail/cygwin-apps/2020-August/040411.html

Ken

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: libtool can't build shared library unless -no-undefined specified
  2024-05-16 21:45 ` Ken Brown
@ 2024-05-17  4:50   ` Brian Inglis
  2024-05-21 13:18     ` Jon Turney
  0 siblings, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2024-05-17  4:50 UTC (permalink / raw)
  To: cygwin-apps

On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote:
> On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:
>> Hi folks,
>>
>> Trying to update dateutils, autotools build fails with:
>>
>> libtool: error: can't build x86_64-pc-cygwin shared library unless 
>> -no-undefined is specified
>>
>> Suggestions for overrides or fixes?
>>
>> Tried:
>>
>> LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"
>>
>> CYGCONF_ARGS="
>>       --enable-contrib
>>       --enable-tzmap-fetch
>>       lt_no_undefined_flag=--no-undefined
>>       no_undefined_flag=--no-undefined
> 
> You and I discussed this a few years ago in connection with curl.  The solution 
> there, and in most similar cases, is to add -no-undefined to the appropriate 
> lib*_la_LDFLAGS variable(s) in Makefile.am.  See
> 
>    https://cygwin.com/pipermail/cygwin-apps/2020-August/040411.html

Thanks for the reminder Ken,

You must have a great memory and/or search strategy.
Even checking back on curl and github I have zero memory of making this patch, 
and it being accepted upstream, but this should prompt me to remember to search 
wider in my email hierarchy, and in my own package repo clones and directories 
for patches.
Now your response is starred in my email.
Perhaps I worked contract gigs too long, my memory compressor kicked in, and 
swapped that out to external storage (here!)
Hoping this will perhaps hammer a nail in my memory to hang that info on.

Cheers!

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: libtool can't build shared library unless -no-undefined specified
  2024-05-17  4:50   ` Brian Inglis
@ 2024-05-21 13:18     ` Jon Turney
  2024-05-21 16:22       ` Brian Inglis
  0 siblings, 1 reply; 6+ messages in thread
From: Jon Turney @ 2024-05-21 13:18 UTC (permalink / raw)
  To: Brian Inglis; +Cc: cygwin-apps

On 17/05/2024 05:50, Brian Inglis via Cygwin-apps wrote:
> On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote:
>> On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:
>>> Hi folks,
>>>
>>> Trying to update dateutils, autotools build fails with:
>>>
>>> libtool: error: can't build x86_64-pc-cygwin shared library unless 
>>> -no-undefined is specified
>>>
>>> Suggestions for overrides or fixes?
>>>
>>> Tried:
>>>
>>> LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"
>>>
>>> CYGCONF_ARGS="
>>>       --enable-contrib
>>>       --enable-tzmap-fetch
>>>       lt_no_undefined_flag=--no-undefined
>>>       no_undefined_flag=--no-undefined
>>
>> You and I discussed this a few years ago in connection with curl.  The 
>> solution there, and in most similar cases, is to add -no-undefined to 
>> the appropriate lib*_la_LDFLAGS variable(s) in Makefile.am.  See

Yeah, building stuff for Cygwin often requires adding this flag in the 
appropriate places, to say "yes, I really do want a shared library".

https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode

> -no-undefined
> 
> Declare that output-file does not depend on any libraries other than
> the ones listed on the command line, i.e., after linking, it will not
> have unresolved symbols. Some platforms require all symbols in shared
> libraries to be resolved at library creation (see Inter-library
> dependencies), and using this parameter allows libtool to assume that
> this will not happen.

Note that because this flag doesn't do anything for non-PE targets, it's 
(a) always safe to upstream, and (b) doesn't actually prevent 
development from unwittingly introducing unresolved symbols.


This should probably be mentioned in the FAQ item on PE linkage 
peculiarities.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: libtool can't build shared library unless -no-undefined specified
  2024-05-21 13:18     ` Jon Turney
@ 2024-05-21 16:22       ` Brian Inglis
  2024-06-02 14:56         ` Jon Turney
  0 siblings, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2024-05-21 16:22 UTC (permalink / raw)
  To: cygwin-apps

On 2024-05-21 07:18, Jon Turney via Cygwin-apps wrote:
> On 17/05/2024 05:50, Brian Inglis via Cygwin-apps wrote:
>> On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote:
>>> On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:
>>>> Trying to update dateutils, autotools build fails with:
>>>> libtool: error: can't build x86_64-pc-cygwin shared library unless 
>>>> -no-undefined is specified
>>>> Suggestions for overrides or fixes?
>>>> Tried:
>>>> LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"
>>>> CYGCONF_ARGS="
>>>>       --enable-contrib
>>>>       --enable-tzmap-fetch
>>>>       lt_no_undefined_flag=--no-undefined
>>>>       no_undefined_flag=--no-undefined
>>> You and I discussed this a few years ago in connection with curl.  The 
>>> solution there, and in most similar cases, is to add -no-undefined to the 
>>> appropriate lib*_la_LDFLAGS variable(s) in Makefile.am.  See

Had to patch into lib AM_LDFLAGS variable, then found out that library was not 
for use in open source packages, but only required to link with a (missing) 
proprietary MatLab module, so dropped the config --enable-contrib option!

> Yeah, building stuff for Cygwin often requires adding this flag in the 
> appropriate places, to say "yes, I really do want a shared library".
> https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode
>> -no-undefined
>> Declare that output-file does not depend on any libraries other than
>> the ones listed on the command line, i.e., after linking, it will not
>> have unresolved symbols. Some platforms require all symbols in shared
>> libraries to be resolved at library creation (see Inter-library
>> dependencies), and using this parameter allows libtool to assume that
>> this will not happen.
> Note that because this flag doesn't do anything for non-PE targets, it's (a) 
> always safe to upstream, and (b) doesn't actually prevent development from 
> unwittingly introducing unresolved symbols.

In that case, could we ask Bruno to add into gnulib somewhere appropriate?

> This should probably be mentioned in the FAQ item on PE linkage peculiarities.

In libtool info?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: libtool can't build shared library unless -no-undefined specified
  2024-05-21 16:22       ` Brian Inglis
@ 2024-06-02 14:56         ` Jon Turney
  0 siblings, 0 replies; 6+ messages in thread
From: Jon Turney @ 2024-06-02 14:56 UTC (permalink / raw)
  To: Brian Inglis; +Cc: cygwin-apps

On 21/05/2024 17:22, Brian Inglis via Cygwin-apps wrote:
[...]
>> Note that because this flag doesn't do anything for non-PE targets, 
>> it's (a) always safe to upstream, and (b) doesn't actually prevent 
>> development from unwittingly introducing unresolved symbols.
> 
> In that case, could we ask Bruno to add into gnulib somewhere appropriate?

This doesn't seem like a solution.

There's lots of stuff which uses libtool which doesn't use gnulib.

There might be stuff which uses gnulib, but which does platform-specific 
gymnastics (i.e. has unresolved symbols on ELF platforms, but not on PE, 
or really, genuinely only wants a static library on PE).

All of which is to say, there is no "one size fits all" solution, 
individual projects need to decide how to handle this point, otherwise 
we'd (hopefully) be using it...

(which is not to say that the default could probably have been chosen to 
be less hassle)

>> This should probably be mentioned in the FAQ item on PE linkage 
>> peculiarities.
> 
> In libtool info?

I meant in https://cygwin.com/faq.html#faq.programming.linker, which 
touches on the issue, but doesn't go into libtool specifics currently.

(But looking at this again, the question would need adding to, also)


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-06-02 14:56 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-16 20:24 libtool can't build shared library unless -no-undefined specified Brian Inglis
2024-05-16 21:45 ` Ken Brown
2024-05-17  4:50   ` Brian Inglis
2024-05-21 13:18     ` Jon Turney
2024-05-21 16:22       ` Brian Inglis
2024-06-02 14:56         ` Jon Turney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).