Re: [Libcdio-devel] W32 problems

[Rocky Bernstein]

You have a CC this time, but I think this will be the last time from me. If
you post to a developers mailing list, especially one of as low volume of
this then you should be prepared to read it.

If you want personal email you should use the bug tracker. In fact, that is
where bugs generally are reported.


On Tue, Sep 18, 2012 at 10:13 AM, LRN <address@hidden> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > I spent some time today looking at these patches. While there are
> > probably some aspects that will help things, it doesn't look like I
> > can apply any of these as is. In some cases things might be worse
> > in other environments.
> I do not insist that these patches are 100% correct. Especially 0007.
> 0002 is practically there just for things to compile for me.
>
> > Are these patches go again the current git sources. If not please
> > use git sources  https://savannah.gnu.org/git/?group=libcdio
> 0002, 0004 and 0005 are against 0.83
> 0006 and 0007 are against git 5cd2f07
>

Ok. So 2 was fixed last April, and 4 I discussed last time. There was no 5
attached. 6 I just applied and 7 has the problems I mentioned previously.

Thanks for the information. If you want 7 not to get forgotten, open a bug
report on that.



>
> >> 0006-fix-differences-in-_img_private_t-definition.all.patch -
> >> stdbool REDEFINES (!) "bool" to be _Bool, not int. Therefore all
> >> files that define something with "bool" type have to include
> >> stdbool.h, otherwise different source files will have different
> >> sizes for some structures.
> >>
> >
> > I tried compiling on Mingw and I do not see an error in compiling
> > win32_ioctl.c. Again old sources?
> It's not an "error compiling", the difference is apparent at runtime,
> and results in a segfault (when one piece of code tries to modify a
> structure it got from another piece of code, but misjudges its size
> and modifies wrong memory location).
> Just break on functions that work with _img_private_t in different
> files and check sizeof().
> You can also compile libcdio, logging make output to a file, get the
> commands make invokes from the log, then re-issue them manually,
> adding -E to make gcc output pre-processed sources. Then look at
> _img_private_t definitions in each of the preprocessed files
> (win32_ioctl.c and win32.c)
>
> >> 0007-fix-struct-packing-on-latest.mingw32.patch - as of
> >> gcc-4.7.0 - -mms-bitfields is enabled by default. Problem is,
> >> when it is enabled, gcc struct member packing attributes have no
> >> effect. Pragma pack has to be used to pack structures. This patch
> >> makes sure that on W32 structures are packed (requires
> >> configuring with CFLAGS=-std=iso9899:1999).
> >>
> >
> > I tried applying this on mingw and I get a warning about that a
> > pragma attribute is ignored. Possibly you need a better test on the
> > gcc version. Also, I didn't see any noticable change on tests. So
> > what test does this fix? Or what behavior do you get before the
> > patch that you don't get after?
> Structure size tests fail, obviously. Have you looked at test.log i
> attached to my previous message?
>

Test log has lots of stuff in it.  Iappreciate including all of it, but
also it would have been nice to also include a annotated excerpts , that
has the parts specific to the specific patches.

Overall, the lackadaisical reporting and vagueness has meant I have had to
spend far too much time going down blind alleys. It makes me not want to
deal with this.


> P.S. CC me, please, i'm not subscribed to this list.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJQWIFrAAoJEOs4Jb6SI2CwMC0H/R6vpPWAlOZEnseVLFlDISh8
> 2k78onJuHX5WzZeXPCGufxvup3+DbBXagNW4rLCYDqcRMaBYmLdYoRwHkUWWgyXa
> aLuKWwbrvhf+O97cUHo1AlZ7QHeuPvUbXZ3tMKrPj5X6EIg+KNLGyQDjbzLp46OM
> LuDj62O553G70gIJN1uOGG+6JFFUlgW3R+2oI1/ZxWoa3vI0jbk2e9YBtOVZKSfZ
> mYnVF7TQ50VCYEOrQGNHbTz1jlDGmE8upJJhjWNlb6EWdgktrRPcD99I4+nloHwF
> SUsvyMMKYPgF3HU8oxuz5F+wSXzhvIniUmR4zdAEzna2HP27L7VQxycT+oYlH3o=
> =GdfO
> -----END PGP SIGNATURE-----
>
>