NO

Author Topic: Disable warnings for compiler and POLINK?  (Read 3730 times)

Offline jj2007

  • Member
  • *
  • Posts: 503
Disable warnings for compiler and POLINK?
« on: January 21, 2013, 07:26:27 am »
Hi all,

I get plenty of warnings of this type:

POCC:
*.c(131): warning #2216: The return value from 'fprintf' is never used.

POLINK:
...warning: Section '.debug_info' is missing contents flag; assuming DATA.

The second one creates an output of 110kBytes - for a source of less than 50 lines!
The proggie links to the GNU Scientific Library aka GSL, so I might not be the only one to see this.

The added value of these warnings seems to be limited, the added risk to overlook serious problems embedded in the 110k is considerable. Therefore my question:

Is there any way to disable them for good?

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1696
Re: Disable warnings for compiler and POLINK?
« Reply #1 on: January 21, 2013, 01:10:22 pm »
For POCC warnings:
 - lower the warning level in project options->compiler
 - To disable specific warnings use the #pragma warn
i.e.
 
Code: [Select]
#pragma warn(disable: 2216) to disable the warning for unused return value

For POLINK is not possible to disable the warnings that are due to misworked object PE format.

Offline jj2007

  • Member
  • *
  • Posts: 503
Re: Disable warnings for compiler and POLINK?
« Reply #2 on: January 22, 2013, 12:20:56 am »
For POCC warnings:
 - To disable specific warnings use the #pragma warn

Thanks, that's a huge improvement! From over 50 meaningless "The return value from 'fprintf' is never used" down to just three lines :)

Quote
For POLINK is not possible to disable the warnings that are due to misworked object PE format.

The "misworked" object file is the official Windows build of the GNU Scientific Library. But I found a workaround - a little filter for the polink output:

Writing debug information
Compacting CodeView information
9       warnings 'is longer than 8 characters; truncated'
1396    warnings 'missing contents flag; assuming DATA'


Looks a lot tidier that way. In case somebody has similar problems, I attach the exe and a sample ini file, both to be placed in PellesC\Bin\

Usage is straightforward:
:okcc
echo.
echo --------------- LINK -----------------
\PellesC\Bin\polinkfilter -subsystem:console -machine:x86 "%~dpn1.obj" %oCRT% xTimer.lib kernel32.lib advapi32.lib delayimp.lib ../../GSL/lib/libgsl.a ../../GSL/lib/libgslcblas.a -out:"%~dpn1.exe"

if exist "%~dpn1.exe" goto oklink


I wanted to use if errorlevel 0 goto oklink but it seems not to work :(
« Last Edit: January 22, 2013, 10:22:43 am by jj2007 »

Offline Bitbeisser

  • Global Moderator
  • Member
  • *****
  • Posts: 760
Re: Disable warnings for compiler and POLINK?
« Reply #3 on: January 22, 2013, 05:12:24 am »
I wanted to use
Code: [Select]
if errorlevel 0 goto oklink but it seems not to work :(
Try
Code: [Select]
IF NOT ERRORLEVEL 1 GOTO OKLink
Ralf

Offline jj2007

  • Member
  • *
  • Posts: 503
Re: Disable warnings for compiler and POLINK?
« Reply #4 on: January 22, 2013, 10:24:15 am »
Thanks, Ralf. I have added a check for "fatal error" in the filter above, it will pass errorlevel 1 if the string is found.

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 1696
Re: Disable warnings for compiler and POLINK?
« Reply #5 on: January 22, 2013, 11:07:48 am »
The "misworked" object file is the official Windows build of the GNU Scientific Library. But I found a workaround - a little filter for the polink output:

Writing debug information
Compacting CodeView information
9       warnings 'is longer than 8 characters; truncated'
1396    warnings 'missing contents flag; assuming DATA'


This is well known "misbehaviour" of MS linker, it usually sets the write flag on READONLY DATA sections or, as in this case doesn't set section access flags at all. Happen many times using precompiled libraries.
If you like MS point of view PellesC compiler is wrong, else MS is wrong  ;D
IMO MS is wrong, normally PellesC settings are compliant with section type.
Anyway this normally isn't a big issue and the executable works anyway.

Moreover the MS and PellesC debugging informations diverged long time ago, since MS started to not pubblish anymore the last formats. So don't care about them.

The best solution is to recompile the library with PellesC, or use MS tools for the whole project.
« Last Edit: January 22, 2013, 11:10:19 am by frankie »