Maurilio:
>it seems it does not find os2.a and rtl c library.
When we call ld.exe/emxomfld.exe directly perhaps is missing all
environment values used by gcc settings
>I was going to create a ld.exe which simply spits out what it received
>from gcc so we can see what it needs :)
>here it is my ld.exe while building ld.exe itself after substituing it
>with itself :))
>(E:\harbour\ld)hbmk2 -st -shared ld.prg
>hbmk2: Processing environment options: -mt -compiler=gcc
-st and -mt ?
[...]
>my ld.exe is a simple
>function main( ... )
> ? ...
>return 0
>So, we can see that it points to a lot of libs, now let's see what
>happens when it is called in building harbour.dll
OK
>And here, in all of its beauty, the call to build harbour.dll
>
>:)
>gcc -shared -L../../../../../lib/os2/gcc -o
>../../../../../bin/os2/gcc/harbour.dll @__dyn__.tmp __dyn__.def
>-lsocket -s
>------------8<--------------------
>-Zdll -o ../../../../../bin/os2/gcc/harbour.dll -s
>E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o -L../../../../../lib/os2/gcc
>-LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5
>-LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib
>-LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5
>-LE:/SVILUPPO/GCC/V3.3.5/USR/lib
>-LE:/REPOSITORY/HARBOUR/src/dynlib/obj/os2/gcc
>-LE:/SVILUPPO/GCC/V3.3.5/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5
>-LE:/Sviluppo/gcc/v3.3.5/usr/i386-pc-os2-emx/lib
>-LE:/SVILUPPO/GCC/V3.3.5/USR/i386-pc-os2-emx/lib
>-LE:/Sviluppo/gcc/v3.3.5/usr/lib
>../../../../../src/common/obj/os2/gcc/expropt1.o
[...]
>../../../../../src/vm/obj/os2/gcc/runner.o
>../../../../../src/vm/obj/os2/gcc/vm.o __dyn__.def -lsocket -lc_alias
>-lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias
>-lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias
>-lc_dll -los2
>------------>8--------------------
You obtain same info as I reported before using -v switch in gcc.
See next part of original message
You can see detailed info in messages from:
OS/2: harbourm.dll
4/10/09 07:28 AM
>>>==========
At last gcc is expanding __dyn__.tmp generating a long expression
I am intrigued with long expression reported as obtained with -v in gcc
Recalling the parsed structure:
-----------------------
emxomfld.exe -Zdll
-o ../../../../../bin/os2/gcc/harbour.dll
E:/usr/lib/dll0.obj
-L../../../../../lib/os2/gcc
-LE:/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5
-LE:/usr/lib/gcc-lib
-LE:/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5
-LE:/usr/lib
-LE:/harbour909f/harbour/source/dynlib/obj/os2/gcc
-LE:/USR/lib/gcc-lib/i386-pc-os2-emx/3.3.5
-LE:/usr/i386-pc-os2-emx/lib
-LE:/USR/i386-pc-os2-emx/lib
-LE:/usr/lib
-LE:/usr/lib
..\..\..\..\..\source\common\obj\os2\gcc\expropt1.obj
[rest of .obj files list]
..\..\..\..\..\source\vm\obj\os2\gcc\vm.obj
__dyn__.def -lsocket
-lc_alias
-lc_dll
-los2
-lgcc_so_d
-lc_alias
-lc_dll
-los2
-lend
--------------------------
excluding "ld.exe" or "emxomfld.exe" rest are send to ld or emxomfld
Is a long chain
<<<<==========
What I see as differences with your and my results
- You are using:
gcc -shared ... -lsocket -s
and I am using
gcc -shared -Zomf... -lsocket
-Zomf is explained by OMF type, but -s ?
- In my case gcc add this list
-lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lend
while in your case is:
-lc_alias
-lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias
-lc_dll -los2 -lgcc_so_d -lc_alias -lc_dll -los2 -lgcc_so_d -lc_alias
-lc_dll -los2
Long chain of:
[rest of .obj files list]
is what surpass 32K limit, as found before and Knut explained
>Ok,
>this command
>ld -Zdll -s -o harbour.dll E:/SVILUPPO/GCC/V3.3.5/USR/lib/dll0.o
>-L../../../../../lib/os2/gcc
>-LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib/i386-pc-os2-emx/3.3.5
>-LE:/Sviluppo/gcc/v3.3.5/usr/lib/gcc-lib
>-LE:/Sviluppo/gcc/v3.3.5/usr/lib
>@__dyn__.tmp __dyn__.def -lsocket -lc_alias -lc_dll -los2 -lgcc_so_d
>-lc_alias
>-lc_dll -los2 -lgcc_so_d
>builds harbour.dll without errors,
You are adding the rest of environment values used by gcc settings, as
gcc does when it call ld.exe/emxomfld.exe
It can work, but taking care of all values used in each compiler environment
For example, for os2gcc442:
-------------------------
PATH_EMXPGCC=E:\usr
CCENV=EMX
BUILD_ENV=EMX
BUILD_PLATFORM=OS2
DPATH=E:\usr\local442\lib;E:\usr\lib;E:\MPTN; ...
PATH=E:\usr\local442\libexec\gcc\i386-pc-os2-emx\4.4.2;E:\usr\local442\bin;E:\usr\bin;
...
C_INCLUDE_PATH=E:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2/include;E:/usr/local442/include;E:/usr/include;
CPLUS_INCLUDE_PATH=E:/usr/local442/include/c++/4.4.2;E:/usr/local442/include/c++/4.4.2/i386-pc-os2-emx;E:/usr/local442/include/c++/4.4.2/backward;E:/usr/local442/include;E:/usr/include;
LIBRARY_PATH=E:/usr/local442/lib/gcc/i386-pc-os2-emx/4.4.2;E:/usr/local442/lib;E:/usr/lib;
INFOPATH=E:/usr/local442/info;E:/usr/info;
PROTODIR=E:/usr/include/c++/gen
BEGINLIBPATH=E:\usr\local442\lib;E:\usr\lib;
-------------------------
>now, it remains to be seen if the .dll works .)
Can you post a code sample for test .dll ?
I do not know how it is used
David Macias
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
