* why does i686-w64-mingw32-gcc -static fail?
@ 2020-12-18 3:45 Lee
2020-12-18 5:29 ` Brian Inglis
0 siblings, 1 reply; 4+ messages in thread
From: Lee @ 2020-12-18 3:45 UTC (permalink / raw)
To: cygwin
Would someone please explain why adding "-static" makes
i686-w64-mingw32-gcc fail?
This works (or at least the compiler doesn't complain)
$ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix -lpcre
This does not work
$ i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix -lpcre
/usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
cannot find -lpcreposix
/usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
cannot find -lpcre
collect2: error: ld returned 1 exit status
Why does adding "-static" make it fail?
$ cat conftest-pcre.c
/* i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix -lpcre
* and yet this works
* i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix -lpcre
*/
char pcre_compile ();
char regcomp ();
int main () {
return pcre_compile ();
return regcomp ();
;
return 0;
}
Thanks
Lee
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: why does i686-w64-mingw32-gcc -static fail?
2020-12-18 3:45 why does i686-w64-mingw32-gcc -static fail? Lee
@ 2020-12-18 5:29 ` Brian Inglis
2020-12-19 7:37 ` Lee
0 siblings, 1 reply; 4+ messages in thread
From: Brian Inglis @ 2020-12-18 5:29 UTC (permalink / raw)
To: cygwin
On 2020-12-17 20:45, Lee via Cygwin wrote:
> Would someone please explain why adding "-static" makes
> i686-w64-mingw32-gcc fail?
>
> This works (or at least the compiler doesn't complain)
>
> $ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix -lpcre
>
> This does not work
>
> $ i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix -lpcre
> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
> cannot find -lpcreposix
> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
> cannot find -lpcre
> collect2: error: ld returned 1 exit status
>
> Why does adding "-static" make it fail?
Because the mingw64-*86*-pcre/2 packages provide only dynamic libraries and
their linkage archives:
usr/i686-w64-mingw32/sys-root/mingw/bin/libpcre-1.dll
usr/i686-w64-mingw32/sys-root/mingw/bin/libpcre16-0.dll
usr/i686-w64-mingw32/sys-root/mingw/bin/libpcre32-0.dll
usr/i686-w64-mingw32/sys-root/mingw/bin/libpcrecpp-0.dll
usr/i686-w64-mingw32/sys-root/mingw/bin/libpcreposix-0.dll
usr/i686-w64-mingw32/sys-root/mingw/lib/libpcre.dll.a
usr/i686-w64-mingw32/sys-root/mingw/lib/libpcre16.dll.a
usr/i686-w64-mingw32/sys-root/mingw/lib/libpcre32.dll.a
usr/i686-w64-mingw32/sys-root/mingw/lib/libpcrecpp.dll.a
usr/i686-w64-mingw32/sys-root/mingw/lib/libpcreposix.dll.a
where others provide both dynamic and static libraries e.g. mingw64-i686-zstd:
usr/i686-w64-mingw32/sys-root/mingw/bin/libzstd-1.dll
usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.a
usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.dll.a
possibly where the size of useful library members are reasonably small enough,
and unlikely to need significantly updated, to be statically linked into an
standalone executable or embedded system component, that itself may be regularly
updated, rather than requiring large chunks of a framework to be linked that may
need regular updates.
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: why does i686-w64-mingw32-gcc -static fail?
2020-12-18 5:29 ` Brian Inglis
@ 2020-12-19 7:37 ` Lee
2020-12-19 16:39 ` Ken Brown
0 siblings, 1 reply; 4+ messages in thread
From: Lee @ 2020-12-19 7:37 UTC (permalink / raw)
To: cygwin
On 12/18/20, Brian Inglis wrote:
> On 2020-12-17 20:45, Lee via Cygwin wrote:
>> Would someone please explain why adding "-static" makes
>> i686-w64-mingw32-gcc fail?
>>
>> This works (or at least the compiler doesn't complain)
>>
>> $ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix
>> -lpcre
>>
>> This does not work
>>
>> $ i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix
>> -lpcre
>> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
>> cannot find -lpcreposix
>> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
>> cannot find -lpcre
>> collect2: error: ld returned 1 exit status
>>
>> Why does adding "-static" make it fail?
>
> Because the mingw64-*86*-pcre/2 packages provide only dynamic libraries and
> their linkage archives:
<.. snip list of libpcre*.dll and .dll.a files ..>
> where others provide both dynamic and static libraries e.g.
> mingw64-i686-zstd:
>
> usr/i686-w64-mingw32/sys-root/mingw/bin/libzstd-1.dll
> usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.a
> usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.dll.a
>
> possibly where the size of useful library members are reasonably small
> enough,
> and unlikely to need significantly updated, to be statically linked into an
> standalone executable or embedded system component, that itself may be
> regularly
> updated, rather than requiring large chunks of a framework to be linked that
> may need regular updates.
Thanks for the explanation :)
I went looking to see how the mingw pcre package was built and ended up here:
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-i686-pcre.git;a=summary
If that's correct and the latest then it looks to be a bit out of
date; the current release is 8.44
https://ftp.pcre.org/pub/pcre/
Looking at the latest cygport info
https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-i686-pcre.git;a=blob;f=mingw64-i686-pcre.cygport;h=7456c41e6c45aad8403303aee413144fcf5d1b58;hb=3200774765aabbdda5cf4e5e9934c3d25e6e7196
and going off the current pcre doc included with the 8.44 tarball:
The Autotools PCRE building process uses libtool to build both shared
and static libraries by default. You can suppress one of these by
adding one of
--disable-shared
--disable-static
to the configure command, as required.
The cygport info doesn't have "--disable-static" so maybe not having
static libraries wasn't an intentional omission??
Thanks
Lee
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: why does i686-w64-mingw32-gcc -static fail?
2020-12-19 7:37 ` Lee
@ 2020-12-19 16:39 ` Ken Brown
0 siblings, 0 replies; 4+ messages in thread
From: Ken Brown @ 2020-12-19 16:39 UTC (permalink / raw)
To: cygwin
On 12/19/2020 2:37 AM, Lee via Cygwin wrote:
> On 12/18/20, Brian Inglis wrote:
>> On 2020-12-17 20:45, Lee via Cygwin wrote:
>>> Would someone please explain why adding "-static" makes
>>> i686-w64-mingw32-gcc fail?
>>>
>>> This works (or at least the compiler doesn't complain)
>>>
>>> $ i686-w64-mingw32-gcc -o a.exe conftest-pcre.c -lpcreposix
>>> -lpcre
>>>
>>> This does not work
>>>
>>> $ i686-w64-mingw32-gcc -o a.exe -static conftest-pcre.c -lpcreposix
>>> -lpcre
>>> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
>>> cannot find -lpcreposix
>>> /usr/lib/gcc/i686-w64-mingw32/10/../../../../i686-w64-mingw32/bin/ld:
>>> cannot find -lpcre
>>> collect2: error: ld returned 1 exit status
>>>
>>> Why does adding "-static" make it fail?
>>
>> Because the mingw64-*86*-pcre/2 packages provide only dynamic libraries and
>> their linkage archives:
> <.. snip list of libpcre*.dll and .dll.a files ..>
>> where others provide both dynamic and static libraries e.g.
>> mingw64-i686-zstd:
>>
>> usr/i686-w64-mingw32/sys-root/mingw/bin/libzstd-1.dll
>> usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.a
>> usr/i686-w64-mingw32/sys-root/mingw/lib/libzstd.dll.a
>>
>> possibly where the size of useful library members are reasonably small
>> enough,
>> and unlikely to need significantly updated, to be statically linked into an
>> standalone executable or embedded system component, that itself may be
>> regularly
>> updated, rather than requiring large chunks of a framework to be linked that
>> may need regular updates.
>
> Thanks for the explanation :)
>
> I went looking to see how the mingw pcre package was built and ended up here:
> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-i686-pcre.git;a=summary
>
> If that's correct and the latest then it looks to be a bit out of
> date; the current release is 8.44
> https://ftp.pcre.org/pub/pcre/
The maintainer has retired from Cygwin package maintenance, so it's not likely
to be updated until someone volunteers to take over.
> Looking at the latest cygport info
> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/mingw64-i686-pcre.git;a=blob;f=mingw64-i686-pcre.cygport;h=7456c41e6c45aad8403303aee413144fcf5d1b58;hb=3200774765aabbdda5cf4e5e9934c3d25e6e7196
>
> and going off the current pcre doc included with the 8.44 tarball:
> The Autotools PCRE building process uses libtool to build both shared
> and static libraries by default. You can suppress one of these by
> adding one of
>
> --disable-shared
> --disable-static
>
> to the configure command, as required.
>
> The cygport info doesn't have "--disable-static" so maybe not having
> static libraries wasn't an intentional omission??
No, it's intentional. cygport itself supplies "--disable-static". See
/usr/share/cygport/cygclass/autotools.cygclass:715:
confargs+=" --enable-shared --disable-static"
The cygport user (i.e., the package maintainer) would have to add
"--enable-static" to override this.
Ken
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-12-19 16:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-18 3:45 why does i686-w64-mingw32-gcc -static fail? Lee
2020-12-18 5:29 ` Brian Inglis
2020-12-19 7:37 ` Lee
2020-12-19 16:39 ` Ken Brown
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).