David,
Knut says gcc does not create a response file, but what happens if we call ld
or/and emxomfld directly, without passing through gcc, after having created
the correct response file?
We could end up with a solution which works with every version of gcc without
requiring a patch at all.
BTW, they build mozilla or firebird, can it be possibile that those monster
projects have fewer files than harbour?
Maurilio.
David Arturo Macias Corona wrote:
> Viktor:
>
>>It's also possible they parse the disk option file,
>>convert it to string and pass it as plain command-line
>>(with 32KB limit) to subprocess.
>
>>While disk option files are not _only_ meant to get
>>around cmdline length limitations, but this is one
>>of their primary functions, so IMO this is a bug in
>>OS/2 GCC implementation and should be reported and
>>fixed. Otherwise it defeats the purpose of disk option
>>file almost completely.
>
> We know we are in same state as months ago and with Harbour grow "the
> future catched us"
>
> I send a public request to some well-known people in OS/2 world
>
> The first response few minutes later is from Knut St. Osmundsen
> ("bird"), the "brain" in Netlabs os2gcc development years ago ( gcc335
> age ) and now "brain" of Sun VirtualBox too
>
> Message is included below and is very clear
>
> I hope Paul Smedley can trace this case and based in Knut proposal then
> implement some solution
>
> David Macias
>
>
>
> David Arturo Macias Corona wrote:
>> Hi All:
>>
>> As I do not know who/where can help us I send this message to all of you
>> with hope of a solution
>> Please review, response and/or redirect to proper people
>>
>> In Harbour for OS/2 development ( www.harbour-project.org ) we face from
>> long time a problem using os2gcc compilers when we try to build some
>> .dll files
>>
>> Tracing I found an now famous 32 Kb limit:
>> -------------------------------------
>> Somewhere gcc is using 32 Kb limit for our case
>> gcc --> emxomfld.exe ( ld.exe )
>>
>> ( or is OS/2 limit ? :-) )
>
> Yes, this is an OS/2 limitation. The usual workaround is to pass the
> arguments in a response file (emxomfld @filename.rsp). Without checking
> all the relevant code, I'm pretty sure that the compiler/linker driver
> (gcc) will not create a response file when invoking sub programs like
> as, ld or emxomfld. The easiest way to hack it into doing this would be
> to change pexecute() in libiberty/pexecute.c to create a response file
> for arguments exceeding, say, 24 KB.
> http://svn.netlabs.org/libc/browser/branches/libc-0.6/src/gcc/libiberty/pexecute.c#L803
>
>
>
>
> For all future communication, could you and your team please use the
> libc/gcc mailing list: http://svn.netlabs.org/libc#MailinglistBugs
>
> You can file bugs in the ticket tracker on that site, although, if it's
> gcc related and you want it fixed soon you're probably better off filing
> them with Paul's bug tracker. :-)
>
--
__________
| | | |__| Maurilio Longo
|_|_|_|____| farmaconsult s.r.l.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
