Perl on Netshare and compiling of modules

[avorop]

Hello, I've tried to compile few modules for 5.40 and failed because no libraries could be found. The check has shown that the files are available. Then I've tried installing of same module but for perl that was itself installed locally - everything worked.

So, the tests show that if perl is installed on a netshare, then there is no way to update Modules for it.

An example of error from building Win32::Process::List

//svpowerwebp01/m/StrawberryPerl-5.40/c/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find //svpowerwebp01/m/StrawberryPerl-5.40/c/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/dllcrt2.o: Invalid argument /

Any hope, that some next release would support working with Netshares just like 5.32 did?

[shawnlaffan]

Is this with a portable or MSI install?

Assuming the former, and that you loaded the portableshell.bat so the paths are all set, then this could be an issue with winlibs. That is where we get the .../c/bin contents from.
https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/binutils.winlib

Are you able to generate a reproducer using only ld.exe?

[avorop]

Sorry, it is portable install. And of course I've set up the PATH appropriately.

What do you mean by "reproducer using only ld.exe"? As far as I can see, the error happens at the last step of linking the library. Here is for example the command from my module:

g++.exe Summer.def -o blib\arch\auto\LG\Summer\Summer.xs.dll -mdll -s -L"M:\NeuPerl\perl\lib\CORE" -L"M:\NeuPerl\c\lib" Summer.o cal.o err_help.o hack_time.o ora.o sum.o workhorse.o zeitreihe.o zr_atable.o zr_blob.o zr_paged.o zr_periodical.o zr_prog.o zr_prog_res.o zr_pwr.o zr_tageswerte.o -L"c:\Users\voropaev.andrey\instantclient_19_14" -loci "M:\NeuPerl\perl\lib\CORE\libperl540.a" -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32 -Wl,--enable-auto-image-base

Reight after it comes first error:
//svpowerwebp01/m/NeuPerl/c/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find //svpowerwebp01/m/NeuPerl/c/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/lib/../lib/dllcrt2.o: Invalid argument

I'm not sure why regular paths "M:\NeuPerl" get replaced with Netshare path, but looks like lg.exe does not like it.

[shawnlaffan]

Thanks. I should have been clearer when referring to a reproducer. This is a minimal set of steps that reproduces the problem, and that could perhaps be reported upstream. One that does not need perl would be useful as then it can be reproduced on other systems.

Also, is this in a Cmd shell or powershell?

#174 is possibly related.

[avorop]

I'm using cmd.exe

Ok, I'll try to put together something

[avorop]

Actually, any attempt to link a program fails. I've created file chk.c

#include <stdio.h>

int
main(void)
{
printf("Ok\n");
return 0;
}

then tried

gcc -o chk chk.c

It didn't work

[avorop]

Hm, it seems this explains it: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189

[sisyphus]

The latest releases at https://winlibs.com have version 2.43.1 of binutils, according to ld --version. (Strawberry's is at 2.42.)

Maybe grab one of the "latest" gcc releases from there and see if that enables your chk.c to be built.
If chk.c does then build, then you've pretty much proven 2 things:

1. that the bugzilla bug 115189 is the problem you're up against;
2. that the issue has now been fixed.

However, if the problem still persists then I would recommend raising an issue with winlibs at https://github.com/brechtsanders/winlibs_mingw/issues.

[avorop]

Well, newest version works without problem. How could I replace the version in package with this one? Or that is not so simple because of libraries involved?

[shawnlaffan]

By newest version are you referring to the most recent GCC 13.x? Or 14.x?

If 13.x is fixed then we should be able to do a drop-in replacement.

[shawnlaffan]

For info, SP 5.40 uses Winlibs GCC 13.2 release 8.

https://github.com/StrawberryPerl/spbuild/blob/a6ea44d9a5f9d7a0cd9f63288a1ee70db5c76133/gcc13.2_ucrt_posix/Dockerfile#L19

If the GCC 13.3 release has this fixed then it should be possible to drop it into the ...c/bin dir.

[sisyphus]

Looking at https://github.com/brechtsanders/winlibs_mingw/releases, it seems that latest 13.x builds are at binutils-2.42.
Probably worth testing, however.

[avorop]

Na, I've used 14.02 for my test. I'll try 13.3 just in case.

[avorop]

No luck. 13.3 still can not compile if located on a Netshare

[shawnlaffan]

Thanks for the testing and detective work. This looks like it needs to be reported upstream to winlibs.

[sisyphus]

On Mon, Sep 16, 2024 at 6:36 PM avorop ***@***.***> wrote: Unfortunately, there is one more bad news. Version 14.02 does work, when it is located on Netshare. But it works only if executable to be created is located on local disk. If I try to create an executable on some other or same Netshare, then I don't get anything, even error is not produced. There is simply no result of linking.

Hmmm ... I'm not seeing this post of yours at #215. I don't know why. Anyway .... replying to the email Like Shawn, I was originally thinking that this should be raised with winlibs, but maybe you should be raising it with mingw-w64 developers. I don't know what the preferred method of contacting the mingw-w64 guys is. I usually contact mingw-w64-public at lists dot sourceforge dot net, which works quite well for me. I'm not sure if you need to be subscribed. Cheers, Rob

[avorop]

I've deleted it, because the files were removed by some Antivirus, or something else. So, it was not a problem of MinGW. Sorry.

…

On Tue, Sep 17, 2024, 01:35 sisyphus ***@***.***> wrote: On Mon, Sep 16, 2024 at 6:36 PM avorop ***@***.***> wrote: > Unfortunately, there is one more bad news. Version 14.02 does work, when > it is located on Netshare. But it works only if executable to be created is > located on local disk. If I try to create an executable on some other or > same Netshare, then I don't get anything, even error is not produced. There > is simply no result of linking. > Hmmm ... I'm not seeing this post of yours at #215. I don't know why. Anyway .... replying to the email Like Shawn, I was originally thinking that this should be raised with winlibs, but maybe you should be raising it with mingw-w64 developers. I don't know what the preferred method of contacting the mingw-w64 guys is. I usually send email to ***@***.***, which works quite well for me. I'm not sure if you need to be subscribed. Cheers, Rob — Reply to this email directly, view it on GitHub <#215 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHVTP3MUR624GO4MFB6S3XLZW5TMZAVCNFSM6AAAAABN6ZOUEGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJUGIYTEMJZGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[sisyphus]

I've deleted it, because the files were removed by some Antivirus, or something else

I think that happens only when you install a winlibs build that includes the "LLVM/Clang/LLD/LLDB" stuff.
If you install the "without LLVM/Clang/LLD/LLDB" version, I think you should find that nothing gets removed.
Of course, that might not help, anyway ....

I've never come across a need for the "LLVM/Clang/LLD/LLDB" stuff in my own builds of perl, and Strawberry Perl itself is built using a "without LLVM/Clang/LLD/LLDB" version.