Scott Michel wrote:
> Eliot wrote:
> 
>>If I just tweak the makefile by reordering the libraries, then the program
>>runs!
> 
> 
> Look at the Project window, you should see a "your_project.PRJ" listed.
> Right click on it, click on "Edit Project...". You should get a new window
> listing the sources and libraries in the project.
> 
> Click on the "wsock32_sc.lib" line and then click on "Remove" to remove it.
> 
> Click on the line ABOVE "winmm32_sc.lib", then locate the wsock32_sc library
> again and add it to the project. It should now appear before winmm32_sc.lib
> 
> Unless someone else has a better way -- it's a pain, but it will work.
> 
> 
> -scooter

Open the *.prj file in a text editor, remove all lines with starting with -1, order de *.lib files. Save file and reopen with the IDDE.

Arjan

[I'm crossposting this summary to wxwindows for future reference by other victims, Original thread title was "Linker commands generated by IDDE" (Thanks Arjan) ]

I found that the order of libraries in the link command affects whether the program runs or not!

Here is a working library order for controls sample:
..\..\LIB\wx_sc.lib ..\..\LIB\tiff_sc.lib ..\..\LIB\zlib_sc.lib ..\..\LIB\jpeg_sc.lib ..\..\LIB\png_sc.lib ..\..\LIB\shell32_sc.lib ..\..\LIB\wsock32_sc.lib ..\..\LIB\winmm32_sc.lib  gc.lib OLE32.LIB OLEAUT32.LIB snn.lib UUID.LIB COMCTL32.LIB COMDLG32.LIB ADVAPI32.LIB CTL3D32.LIB KERNEL32.LIB GDI32.LIB USER32.LIB

Not sure what the actual ordering contstraints are.  Possibly
wx_sc first
wsock32 before winmm32

To reorder the libraries in the IDDE:

Open the *.prj file in a text editor, remove all lines with starting with -1, order de *.lib files. Save file and reopen with the IDDE.


- Eliot

Eliot escreveu:
> [I'm crossposting this summary to wxwindows for future reference by other victims, Original thread title was "Linker commands generated by IDDE" (Thanks Arjan) ]
> 
> I found that the order of libraries in the link command affects whether the program runs or not!

Maybe the (some, at least two of them) libraries contain objects with the same name but w/slightly different behaviours?

"Cesar Rabak" <crabak@acm.org> wrote in message news:4047DF63.7090902@acm.org...
> Eliot escreveu:
> > [I'm crossposting this summary to wxwindows for future reference by other victims, Original thread title was "Linker commands generated by IDDE" (Thanks Arjan) ]
> >
> > I found that the order of libraries in the link command affects whether the program runs or not!
>
> Maybe the (some, at least two of them) libraries contain objects with the same name but w/slightly different behaviours?

That's really the only thing that library order should affect.

>[I'm crossposting this summary to wxwindows for future reference by other victims, Original thread title was "Linker commands generated by IDDE" (Thanks Arjan) ]

I'm a victim too :)


>Not sure what the actual ordering contstraints are.  Possibly
>wx_sc first
>wsock32 before winmm32
>To reorder the libraries in the IDDE:

I got the same problem, DMC 8.40 & WXWidgets 2.4.2. The information posted here is very useful.

Try this:

Delete all c:\wxwidgets\lib\*_SC.lib
Remove the line  ''_WSACleanup@0 = WSACleanup'' in file
c:\wxwidgets\lib\_sc\winmm32_sc.def
Rebuild wxwidgets.

I don't know if it's a good idea, but "it works for me" ;) Suggestions?

Jorge

I am sorry, but I missed this discussion earlier, and am rather confused. I'd like to fix this if I can:

1) When does a bug strike, and what are the symptoms?

2) is it in IDDE builds only, or with makefiles as well

3) is the solution to remove *or* reposition _WSACleanup@0 = WSACleanup in the def file?

4) if removal is needed, do the  samples still compile.

Thanks for more details, so i can look for the right bug
chris


Jorge wrote:
>>[I'm crossposting this summary to wxwindows for future reference by other victims, Original thread title was "Linker commands generated by IDDE" (Thanks Arjan) ]
> 
> 
> I'm a victim too :)
> 
> 
> 
>>Not sure what the actual ordering contstraints are.  Possibly
>>wx_sc first
>>wsock32 before winmm32
>>To reorder the libraries in the IDDE:
> 
> 
> I got the same problem, DMC 8.40 & WXWidgets 2.4.2. The information posted here
> is very useful.
> 
> Try this:
> 
> Delete all c:\wxwidgets\lib\*_SC.lib
> Remove the line  ''_WSACleanup@0 = WSACleanup'' in file
> c:\wxwidgets\lib\_sc\winmm32_sc.def
> Rebuild wxwidgets.
> 
> I don't know if it's a good idea, but "it works for me" ;) Suggestions?
> 
> Jorge

chris elliott wrote:

> I am sorry, but I missed this discussion earlier, and am rather confused. I'd like to fix this if I can:

Hi Chris.  I am the OP.  I'm not working with DM right at the moment but will try to summarise.

This thread has had the successive subjects:
1) Controls sample fails when linked using IDDE, OK using makefile. (c++.wxwindows NG)
2) Linker commands generated by IDDE (in c++.idde NG)
3) Library order affects program operation. (both NG)

> 1) When does a bug strike, and what are the symptoms?
Running the sample I'd get this error in a dialog box: "the procedure entry point WSACleanup could not be located in the dynamic link library winmm.DLL"

Using the makefile I can trigger the bug by altering this line in makesc.env (swapped last 2 items)
SUPPORTLIBS = png$(SC_SUFFIX) tiff$(SC_SUFFIX) jpeg$(SC_SUFFIX) zlib$(SC_SUFFIX) $(SHELLLIB) $(WINMMLIB) $(WINSOCKLIB)

> 2) is it in IDDE builds only, or with makefiles as well

For me it was only with IDDE files.  The difference was in the order that I added source files and libraries to the IDDE project.

If I used the IDDE to generate the obj files, then the (your) makefile to do the final link step, I didn't have a problem.

> 3) is the solution to remove *or* reposition _WSACleanup@0 = WSACleanup in the def file?

I am using wxWidgets 2.4.2, the def file doesnt contain the above.

> 4) if removal is needed, do the  samples still compile.

Thank you for this response. I have not yet had time to sit down with my copy of the IDDE (its on a single computer)

The paid for IDDE comes with the full library set, whereas the 8.3x series of DMC compilers which were freely available did not have a complete library set. Thus a .lib had to be built for the missing components. Walter has generously rectified this by supplying the libraries now.

My guess is that the IDDE builds dragged in (either explicitly or implictily) the dm/lib/*.lib files rather than the wxwin/lib/*.lib files, so that a conflict would occur during linking.

I will look some more at this as the 8.4 compilers have a full library set

chris

Eliot wrote:

> chris elliott wrote:
> 
>> I am sorry, but I missed this discussion earlier, and am rather confused. I'd like to fix this if I can:
> 
> 
> Hi Chris.  I am the OP.  I'm not working with DM right at the moment but will try to summarise.
> 
> This thread has had the successive subjects:
> 1) Controls sample fails when linked using IDDE, OK using makefile. (c++.wxwindows NG)
> 2) Linker commands generated by IDDE (in c++.idde NG)
> 3) Library order affects program operation. (both NG)
> 
>> 1) When does a bug strike, and what are the symptoms?
> 
> Running the sample I'd get this error in a dialog box: "the procedure entry point WSACleanup could not be located in the dynamic link library winmm.DLL"
> 
> Using the makefile I can trigger the bug by altering this line in makesc.env (swapped last 2 items)
> SUPPORTLIBS = png$(SC_SUFFIX) tiff$(SC_SUFFIX) jpeg$(SC_SUFFIX) zlib$(SC_SUFFIX) $(SHELLLIB) $(WINMMLIB) $(WINSOCKLIB)
> 
>> 2) is it in IDDE builds only, or with makefiles as well
> 
> 
> For me it was only with IDDE files.  The difference was in the order that I added source files and libraries to the IDDE project.
> 
> If I used the IDDE to generate the obj files, then the (your) makefile to do the final link step, I didn't have a problem.
> 
>> 3) is the solution to remove *or* reposition _WSACleanup@0 = WSACleanup in the def file?
> 
> 
> I am using wxWidgets 2.4.2, the def file doesnt contain the above.
> 
>> 4) if removal is needed, do the  samples still compile.
> 
> 
>