Przemek:
[Przemek]
>Calling LD directly usually creates more or less serious problems
>because some important switches set by GCC automatically may not
>be added by us.
>BTW the problem is caused by too long list of files passed
>from GCC to LD because GCC does not use intermediate files.
>But maybe it's possible to use small trick. DJGPP and as
>I can see OS2 GNU ports expands @<filename> used in parameters.
>So maybe we can simply create 2 files. One with GCC/LD options
>only and with reference to second file __flst__.tmp will have
>list of object files. Such reference can be stored in first file
>as: '-Wl, at __flst__.tmp'. If gcc expects at least one .o file then
>we can pass first object file directly as GCC parameter and not
>include in __flst__.tmp.
>If Maurilio or David can verify it works then we can use such
>method and it should resolve the problem.
[Viktor]
>The file list is already separate, so to try this solution out,
>only '-Wl,' needs to be added right in front of '@__dyn__.tmp':
>--- [gcc.mk]
> $(DY) $(DFLAGS) $(HB_USER_DFLAGS) $(DY_OUT)$(DYN_DIR)/$@ -Wl, at
>__dyn__.tmp __dyn__.def $(DLIBS) $(DYSTRIP)
>---
>This assumes vanilla 2.0.0 gcc.mk, not the hacked ones currently
>on SVN.
Unfortunatelly we do not have matter to test right now
As I posted recently, changes in libraries caused all .dll can be build
fine, no one fails
I will look for older versions to find which fail and to test this
approach.
13841 is an option. How must be specified in SVN ?
In all these messages ping-pong I was tempted to insert the question:
"Do we really need to force direct ld.exe/emxomfld.exe right now ?"
My answer is no
David Macias
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
