Dietmar Maurer wrote:
>
> Dear Brian,
>
> today we discovered a problem with your brilliant Inline-0.31 module running
> under Win2000 (Visual C++ 6.0, latest service-pack; problem also occurs in
> VC++ 4.2)
>
> Here is the line from the Makefile
>
> $(LD) -out:$@ $(LDDLFLAGS) $(LDFROM) $(OTHERLDFLAGS) $(MYEXTLIB)
> $(PERL_ARCHIVE) $(LDLOADLIBS) -def:$(EXPORT_LIST)
>
> The problem is the '-out:$@': the MS linker return an error if the target is
> too long (ie. the filename - which indeed could be _very_ long)
>
> When running a script in "d:\tmp\" everythink is fine, but when running the
> script in "d:\tmp\test\database" I get the message
>
> ...
> LINK : fatal error LNK1104: cannot open file
> "blib\arch\auto\main_C_D__TMP_TEST_DATABASE_TEST_PL_a0b8c2a56732b7be13b57312
> a130a2c6\main_C_D__TMP_TEST_DATABASE_TEST_PL_a0b8c2a56732b7be13b57312a130a2c
> 6.dll"
> NMAKE : fatal error U1077: 'link' : return code '0x450'
Hmmm. Inline should not be putting path parts into the dll name. That's
definitely a bug.
>
> Maybe the filename mustn't exceed 128 chars, but I haven't found anything in
> the MS-Linker-Documentation
>
> Would you like me to try to patch your module or is it possible for you to
> fix it for yourself ?
I am in the midst of reworking Inline so that your example would produce
the files:
blib\arch\auto\TEST\TEST.dll
blib\arch\auto\TEST\TEST.inline
The .inline file will contain all the meta data like
'a0b8c2a56732b7be13b57312a130a2c6'.
This will solve your problem for good, and also resolves a lot of other
issues with Inline.
Look for it in one of the next two releases. If I don't put it into the
next release, I'll at least fix the path bug.
Cheers, Brian
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
