libpng malformed archive

[Maurizio la Cecilia]

Hi Viktor,

after your recent commits I'm no more able to build 32bit applications involving the png lib.

The hbmk2 reported error is:
C:/SVN/hb/lib/win/mingw/libpng.a: error adding symbols: Malformed archive

The 64bit builds aren't affected by this problem.

Any hint?

TIA.

--
Maurizio

[vszakats]

Hi Maurizio,

In libpng, the only change was to rename its .dif to .diff,

and that file isn't even used in the build. Can't see other

commits that'd change the build process in any ways. 

I haven't seen this particular message in the past, so not

sure what may cause it.

FWIW that nightly builds (also based on 32-bit mingw) are

being built fine, including libpng.a.

Based on these, my guess would be something unrelated

to my committed changes.

-Viktor

[Maurizio la Cecilia]

Hi Viktor, surely the problem is on my side. I'm only trying to understand why this is happening.
I said about your commits because the only changed thing after updating was the png package.
In addition to the renamed .dif, also the sources of png library went updated.
After a clean build only 64bit compile succeed, on 32bit the libpng.a is rejected.
Maybe something about my MinGW 7.1 compiler?
But it worked fine for months...
I'm trying to start from a fresh checkout before a clean build. I'll report if that's the solution, but I don't think so.
Any further suggestion is very appreciated.
Best regards.
--
Maurizio

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[vszakats]

On Thursday, September 21, 2017 at 11:49:51 AM UTC+2, Maurizio la Cecilia wrote:

Hi Viktor, surely the problem is on my side. I'm only trying to understand why this is happening.
I said about your commits because the only changed thing after updating was the png package.
In addition to the renamed .dif, also the sources of png library went updated.

I'm not sure what you're seeing, the last update to the

png source code was made in this commit:

2014-01-24 12:35 UTC+0100

 

After a clean build only 64bit compile succeed, on 32bit the libpng.a is rejected.
Maybe something about my MinGW 7.1 compiler?

I've used 7.1 since it came out (till 7.2), but I haven't seen

such error. My Harbour production builds are in the cloud,

you can inspect the exact environment and output:

   https://ci.appveyor.com/project/vsz/harbour-core/history/branch/prod

But it worked fine for months...
I'm trying to start from a fresh checkout before a clean build. I'll report if that's the solution, but I don't think so.
Any further suggestion is very appreciated.

It _may_ be some binutils bug or other corruption that results

in that. You may try reinstalling the toolchain, or even better

upgrade to 7.2. Or try existing 7.1 against 3.4 to see if it helps.

-Viktor

[Andi Jahja]

Hi Maurizio:

 

Try to patch the souce as follows:

 

--- begin ---

 

*** ..\harbour\src\3rd\png\pngconf.h Tue Aug  4 07:43:34 2015
--- src\3rd\png\pngconf.h Fri Sep 15 14:25:19 2017
***************
*** 337,342 ****
--- 337,345 ----
  #  define PNG_REMOVED(ordinal, type, name, args, attributes)
  #endif

+ #undef  PNG_RESTRICT
+ #define PNG_RESTRICT
+
  #ifndef PNG_CALLBACK
  #  define PNG_CALLBACK(type, name, args) type (PNGCBAPI name) PNGARG(args)
  #endif

--- end ---

 

Andi

Virus-free. www.avast.com

[Maurizio la Cecilia]

Hi Viktor,
also the fresh checkout and clean build doesn't solve my problem.
I'll try the next steps you suggested:
1. rebuild using a fresh toolchain
2. test the current toolchain on 3.4
I'll report ASAP.
Thanks.
--
Maurizio

[Maurizio la Cecilia]

Hi Andi, thanks a lot for the suggestion, but that not worked for me.
Best regards.
--
Maurizio

[Rafael Culik]

I got am similiar situation this days.

an file with .png as extension and content not binary

i used an png_check utility to verify the images. you probaly has an corrupt image

Regards

Luiz

To unsubscribe from this group and stop receiving emails from it, send an email to harbour-devel+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Harbour Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to harbour-devel+unsubscribe@googlegroups.com.

[Maurizio la Cecilia]

Hi Rafael, thanks for the info but my problem is at building 32bit applications and not managing png files.
Best regards.
--
Maurizio

To unsubscribe from this group and stop receiving emails from it, send an email to harbour-deve...@googlegroups.com.

[Maurizio la Cecilia]

Hi Viktor,

after the steps below:

1. fresh checkout of both 3.2 and 3.4 Harbour sources in new and empty folders
2. fresh download of both MinGW32 and MinGW64 ( i686-7.1.0-release-posix-dwarf-rt_v5-rev2 and x86_64-7.1.0-release-posix-seh-rt_v5-rev2 from sourceforge.net/projects/mingw-w64/ )
3. fresh and clean rebuilding of both 32 and 64 Harbour binaries and libraries for both 3.2 and 3.4 versions (all ended without errors)

trying to build the same application in all possible scenarios, I'm obtaining:

Harbour 3.2 based 32bit application : ERROR (libpng malformed archive)
Harbour 3.2 based 64bit application : successfull
Harbour 3.4 based 32bit application : successfull
Harbour 3.4 based 64bit application : successfull

So, I'm very confused about this problem.
The same 32bit toolchain works for 3.4 but not for 3.2, so I guess that isn't a problem related to MinGW compiler.
The png lib version in 3.2 tree could be bugged in 32bit building? I suspect that many of us are building 32bit applications linking png without problems...
And, in addition, ar doesn't shows errors listing the lib content.

Now I decided to migrate to 3.4, but I would know anyway the reason of this behaviour.
It could be useful to know if anyone is building successfully a 32bit app (linking also png lib) with Harbour 3.2 and MinGW i686-7.1.0-release-posix-dwarf-rt_v5-rev2.
The sourceforge.net/projects/mingw-w64/  isn't offering yet a 7.2 distro, thus I didn't the try with the last version of MinGW, but as soon as available I'll try for sure.

Any further opinion or suggestion or practical test report will be welcome.
TIA
Best regards.
--
Maurizio
 

Il 21/09/2017 12:45, vszakats ha scritto:

[vszakats]

Hi Maurizio,

On Friday, September 22, 2017 at 12:08:49 PM UTC+2, Maurizio la Cecilia wrote:

Hi Viktor,

after the steps below:

1. fresh checkout of both 3.2 and 3.4 Harbour sources in new and empty folders
2. fresh download of both MinGW32 and MinGW64 ( i686-7.1.0-release-posix-dwarf-rt_v5-rev2 and x86_64-7.1.0-release-posix-seh-rt_v5-rev2 from sourceforge.net/projects/mingw-w64/ )
3. fresh and clean rebuilding of both 32 and 64 Harbour binaries and libraries for both 3.2 and 3.4 versions (all ended without errors)

trying to build the same application in all possible scenarios, I'm obtaining:

Harbour 3.2 based 32bit application : ERROR (libpng malformed archive)
Harbour 3.2 based 64bit application : successfull
Harbour 3.4 based 32bit application : successfull
Harbour 3.4 based 64bit application : successfull

So, I'm very confused about this problem.
The same 32bit toolchain works for 3.4 but not for 3.2, so I guess that isn't a problem related to MinGW compiler.
The png lib version in 3.2 tree could be bugged in 32bit building? I suspect that many of us are building 32bit applications linking png without problems...
And, in addition, ar doesn't shows errors listing the lib content.

Now I decided to migrate to 3.4, but I would know anyway the reason of this behaviour.
It could be useful to know if anyone is building successfully a 32bit app (linking also png lib) with Harbour 3.2 and MinGW i686-7.1.0-release-posix- 

dwarf-rt_v5-rev2.
The sourceforge.net/projects/mingw-w64/  isn't offering yet a 7.2 distro, thus I didn't the try with the last version of MinGW, but as soon as available I'll try for sure.

Any further opinion or suggestion or practical test report will be welcome.

Thanks for your investigation, really interesting.

It could have been related to the '_dyn' objects (where I did rename

one internal variable). These are only generated in 3.2 and only in

32-bit mode, but libpng specifically never got  '_dyn' objects generated

at all, because it's not part of harbour.dll.

Anyhow libpng may not be special here, it's simply the first library

created in the build process. You may try to remove it from 

/src/3rd/Makefile, and see if the next lib, jpeg fails the same.

I've now tried to build 3.2 using mingw-w64 7.2 32-bit from MSYS2,

and libpng.a was generated correctly.

One more thing you may try is rewinding the source to last month

using:

git checkout f496daa711774162eac7bfa07859d2acf276d3df

And see what happens with 3.2 32-bit. If it's correct, the breaking

commit can be bisected in a few steps. Here are my commits:

git log --pretty=online f496daa711774162eac7bfa07859d2acf276d3df..HEAD

(there is also 'git bisect', if you feel adventurous.)

-Viktor

[Mel Smith]

Hi Viktor and Maurizio:

FYI:

My GCC 7.1 compiler is : gcc ( i686-posix-sjlj-rev0)

For Build 1709181715 under HB 3.2, I created successfully the PNG library for MinGW 7.1, VC2017, and BCC73

Here are the libs:

MinGW 7.1  :  libpng.a   2017-09-18  Size : 308,148 bytes

VC2017 : png.lib  2017-09-18 Size : 415,736 bytes

BCC73 : png.lib Size : 335,360 bytes

Question: Why can I create these libs when Maurizio has difficulties ??

-Mel Smith

[Maurizio la Cecilia]

Hi Mel,
maybe you got the answer.

As I wrote, I'm building Harbour with i686-7.1.0-release-posix-dwarf-rt_v5-rev2 not sjlj.
I'm downloading the i686-7.1.0-release-posix-sjlj-rt_v5-rev2 from MinGW-w64 and I'll report if with this exception handler the link succeed.

Anyway, my Harbour 3.2 32bit libpng.a (the wrong one) is 325 KB (333.346 byte) long.
The Harbour 3.4 32 bit libpng.a (the working one) is 322 KB (330.304 byte) long.

Best regards.
--
Maurizio

[Maurizio la Cecilia]

Hi Mel,
no luck.
Also with sjlj the problem still persist.
Best regards.
--
Maurizio

Il 22/09/2017 16:42, Mel Smith ha scritto:

[Mel Smith]

On Friday, September 22, 2017 at 1:27:50 PM UTC-6, Maurizio la Cecilia wrote:

Hi Mel,
no luck.
Also with sjlj the problem still persist.
Best regards.
--
Maurizio

Hi Maurizio:

   I don't know what else to do :(

-Mel

 

[Maurizio la Cecilia]

Hi Viktor and all,
just for clarify what's the problem I'm fighting:

1. Harbour does compile fine in all cases: the libpng.a is always created without any error message. Thus I'm obtaining four Harbour distro fully working (3.4/32, 3.4/64, 3.2/32, 3.2/64).
2. The problem arises when I try to build a business application: the linking succeed in all distros but only 3.2/32 stops with the error in subject.
3. The gcc compiler I'm using is always the same (7.1.0) and also changing the exception handler the problem remains the same.

So, I'm asking if someone compiling a business application based on current version of Harbour 3.2/32bit and linking png lib (in my case is the hbhpdf lib that requires it) obtains the same error. 
Sorry if my previous posts was fuorviating.
Best regards.
--
Maurizio

[Andi Jahja]

Hi Maurizio:

 

I just run: harbour\contrib\hbhpdf\tests\harupdf.prg (3.2/32) and it created myharu.pdf as expected.

 

Andi

 

On Sat, 23 Sep 2017 13:15:31 +0200

Maurizio la Cecilia <m.lac...@gmail.com> wrote:

 

Virus-free. www.avast.com

[Andi Jahja]

And, if you wish to try, these are my libs compiled with 3.2/32 GCC71-DW2:

 

https://drive.google.com/open?id=0B-SRn0-JvtQzQmRadzgwc0V1MzA

https://drive.google.com/open?id=0B-SRn0-JvtQzMjNNb2hvWXo1d3c

 

Andi

Virus-free. www.avast.com

[Maurizio la Cecilia]

Hi Andi,
with your lib the application is built successfully.
But also harupdf.exe is working fine.

I don't have any idea about this problem.

Below the link to my libpng.a compiled with 3.2/32 MinGW i686-7.1.0-release-posix-dwarf-rt_v5-rev2.
https://drive.google.com/file/d/0B5uLJ1qxIpKvOTNXZl9adkRfUWc/view?usp=sharing

Can you confirm that also on your side it produces the error in subject?
TIA
--
Maurizio

[Andi Jahja]

Hi Maurizio:

 

I have tried libpng.a that you compiled, and the result is: __IT_WORKS__ as expected.

 

No malform warning or whatsoever.

 

I suspect you have a bad drive. Some sector might be bad.

 

Have you tried yours in other machine?

 

Thanks.

 

Andi

 

On Mon, 25 Sep 2017 09:39:18 +0200

Maurizio la Cecilia <m.lac...@gmail.com> wrote:

 

[Maurizio la Cecilia]

Hi Andi and all,
after a lot of time and thanks to the suggestions of Francesco Perillo I resolved the linking problem in subject.
The culprit wasn't my libpng.a (it works, as you said), nor my hard disk, nor my environment, but the order of the hbc files in my project.

I wasn't aware that the order of hbc files is important, mainly when hbhpdf lib is involved.

My problem was due to the coexhistence of hbhpdf, hbwin and xhb libs and some rearrangement I made to my scripts in late past year.

After a deep investigation I can affirm that if hbhpdf is linked with hbwin and/or xhb it needs that hbhpdf is referenced before each of the latter in hbp/hbc file.

I hope that somebody can confirm this behaviour, maybe due to some symbol conflict between the libs.
To test if I'm right, just put hbhpdf after hbwin or hbc in the linking script and see if a malformed archive error arises.
Any feedback will be appreciated, as this error could be cause of many headhaches...
Best regards.
--
Maurizio

[Antonio Linares]

Maurizio,

I confirm it and still happens.

I had to modify modharbour.hbp this way to solve it with MinGW 32:

-hbdynvm 

-olibharbour

-l-hbfship

-l-hbxpp

-dflag=-lhbhpdf -llibhpdf

apache.prg

#hbcurl.hbc

hbwin.hbc

xhb.hbc

hbct.hbc

Please notice the use of -dflag=-lhbhpdf -llibhpdf to force those libs to be linked before

regards

Antonio

[Mauricio Ventura Faria]

I confirm that this behavior still existis when using the current nightly build.

And moving hbhpdf.hbc in the hbp solves it.

 

Regards,
 
Maurício Faria

[Nenad Batoćanin]

Hi to all :)

Has anyone found a solid solution to this problem? I have the script with: 

hbct.hbc

hbmxml.hbc

hbmisc.hbc

hbmemio.hbc

hbwin.hbc

hbziparc.hbc

hbnf.hbc

xhb.hbc

and this script working fine. But, when I add hbmzip.hbc in any position, I receive: 

libmxml.a: error adding symbols: Malformed archive

Regards, NB