Several libs now fail with typedefs conflicting with themselves about calypso

[Syniurge]

Hi Kelly,

Could you paste your module map files so that I get a clearer picture. What looks odd is that a struct seems to have been mapped as part of your core.stdc.zmq Clang module?

[wilsonk]

Hello Elie,

It is strange here because I can't seem to replicate this error. I uninstalled the old verison of zmq and installed a hand compiled one and this error doesn't show up now...but I can't get things to work correctly when calling zmq_socket() now either!?! Darnit. I am not sure what is going on but I will just keep this open until I can get zmq to compile, in case this error shows up again.

Hmm, I can't see the pthread_t errors in the libstdc++ examples either, so maybe that last set of commits fixed this? Anyways, as I said, we can leave this open for a few more commits and I'll keep trying to find out what is going on.

Thanks,
Kelly

[wilsonk]

Ok, I kept trying other examples and ended up hitting this error again while trying to compile an example using opencv-3.0.0-beta. The modulemap's I am using are just the three that are in the utils/modulemap[/sys] directories without modification. My test file is just:

modmap (C++) "opencv2/core/cvstd.hpp";
modmap (C++) "opencv2/core/optim.hpp";
import std.stdio;
import (C++) cv._;
void main() {}

Both modmap's are required. My command line is:

ldc2 test.d -L-lstdc++ -cpp-args -I/home/wilsonk/Downloads/opencv-3.0.0-beta/modules/core/include/ -L-L/home/wilsonk/Downloads/opencv-3.0.0-beta/build/lib -L-lopencv_core -L-lopencv_ml -L-lopencv_imgproc -L-lopencv_imgcodecs -Llopencv_objdetect -L-lopencv_photo -L-lopencv_shape -L-lopencv_features2d

and I get these error messages:

/home/wilsonk/Downloads/opencv-3.0.0-beta/modules/core/include/opencv2/core.hpp(69): Error: class Exception only object.d can define this reserved class name
/usr/include/_G_config.h(21): Error: struct cpp.core.stdc.stdio._G_fpos_t conflicts with static import cpp.core.stdc.stdio._G_fpos_t at /usr/include/_G_config.h(21)
/usr/include/_G_config.h(26): Error: struct cpp.core.stdc.stdio._G_fpos64_t conflicts with static import cpp.core.stdc.stdio._G_fpos64_t at /usr/include/_G_config.h(26)
/usr/include/libio.h(369): Error: struct cpp.core.stdc.stdio._IO_cookie_io_functions_t conflicts with static import cpp.core.stdc.stdio._IO_cookie_io_functions_t at /usr/include/libio.h(369)

I am still not sure what is going on with these strange errors. After looking at this again, I think the other error in #14 is much more prevalent and important to fix, as I now see it in about 8 libs (including libstdc++ examples) and I only see this error in opencv (and maybe libzmw still)...just so you know.

Thanks,
Kelly

[Syniurge]

Does 7cc1ca0 make a difference?

I think I've seen this error today, you're right it's everywhere as soon as I make a non-static import (C++) in a D file and try to use a class or struct symbol from the global namespace.

[wilsonk]

Darnit, nope. The last few updates (including 7cc1ca0...) didn't fix the errors listed above for opencv. I did, however, find a similar error when trying to modmap/import vtkArray.h from the VTK lib.

/usr/include/x86_64-linux-gnu/bits/sched.h(125): Error: struct cpp..cpu_set_t conflicts with static import cpp..cpu_set_t at /usr/include/x86_64-linux-gnu/bits/sched.h(125)
/usr/include/x86_64-linux-gnu/bits/pthreadtypes.h(90): Error: union cpp..pthread_mutex_t conflicts with static import cpp..pthread_mutex_t at /usr/include/x86_64-linux-gnu/bits/pthreadtypes.h(90)
/usr/include/x86_64-linux-gnu/bits/pthreadtypes.h(129): Error: union cpp..pthread_mutexattr_t conflicts with static import cpp..pthread_mutexattr_t at /usr/include/x86_64-linux-gnu/bits/pthreadtypes.h(129)
/usr/include/x86_64-linux-gnu/bits/pthreadtypes.h(138): Error: union cpp..pthread_cond_t conflicts with static import cpp..pthread_cond_t at /usr/include/x86_64-linux-gnu/bits/pthreadtypes.h(138)
/usr/include/x86_64-linux-gnu/bits/pthreadtypes.h(155): Error: union cpp..pthread_condattr_t conflicts with static import cpp..pthread_condattr_t at /usr/include/x86_64-linux-gnu/bits/pthreadtypes.h(155

So I made up a new modulemap file called: /usr/include/x86_64-linux-gnu/bits/bits.modulemap_d with this inside:

module core {
module posix {
module bits {
module sched {
header "sched.h"
export *
}
module pthreadtypes {
header "pthreadtypes.h"
export *
}
}
}
}

and then the vtkArray.h file would modmap and import fine (and Calypso stated that I couldn't instantiate vtkArray, when I tried that, because it was abstract and I hadn't implemented a bunch of function overrides...so I think it is working fine).

So it seems like a proper modulemap file can get rid of this type of error..? No clue why it wouldn't work for opencv/_G_config.h though????

Thanks,
Kelly

[Syniurge]

Sounds definitely like a bug because these structs and unions aren't supposed to be affected by Clang modules, and their full name should be e.g cpp..cpu_set_t.cpu_set_t, not cpp..cpu_set_t.

I'm busy with getting Qt to work but I'll devise a simple libc with module maps test case as soon as it's done (soon!).

[wilsonk]

Cool, sounds good Elie.

I have tested some more of the VTK lib and large parts of it modmap and import fine...some classes also instantiate from the few tests I ran, so that is good. I am still using that modmap file I made for pthreadtypes, etc. but at least it is working for now.

I think large parts of VTK will probably be close to working once Qt works :)

Thanks,
Kelly

[wilsonk]

Hello Elie,

It seems like this issue has shown up again (if it ever really went away). I decided to try to compile a simple example using the GDAL library because Suliman was asking about it, but I get this error:

/usr/include/gdalwarper.h(50): Error: enum cpp.gdal.gdalwarper.GDALResampleAlg conflicts with static import cpp.gdal.gdalwarper.GDALResampleAlg at /usr/include/gdalwarper.h(50)
/usr/include/gdalwarper.h(118): Error: struct cpp.gdal.gdalwarper.GDALWarpOptions conflicts with static import cpp.gdal.gdalwarper.GDALWarpOptions at /usr/include/gdalwarper.h(118)

My test file is really simple (I import core.stdc.ctype just to make sure the libstdc modulemap is being picked up...to prove to myself that one modulemap file works here, at least) . The error shows up wherther I modmap gdalwarper.h or not:

import (C++) core.stdc.ctype;
import (C++) gdal.gdalwarper;

void main () {}

My modulemap file is simple just to test for this error (and I tried a file with all the .h files from GDAL in it, just in case it made a difference):

// Generated by: modularize -root-module=gdal -module-map-path=gdal.modulemap_d header.list

module gdal {
  module gdalwarper {
    header "gdalwarper.h"
    export *
  }
}

I tried with the gdal library installed in /usr/local, or my home directory or /usr. Of course, I figured that it would work when installed in /usr, but it didn't so I figured I would try the others. So I am still not sure what is going on here.

I can import a couple different header files for gdal and it really seems like typedef'ed enum/struct/unions in the global namespace are the issue.

[Syniurge]

Typedef'd anonymous tags seem to be wrongly mapped as part of the Clang module (they should be in their own module).

I'm still working on the class pointer fix (already ~650 line changes, still freefalling down the rabbit hole), then I'll address this.

If you want to investigate yourself it's figuring out why DeclMapper::VisitTypedefNameDecl isn't skipping those typedef. isAnonTagTypedef() isn't working as it should.

[Syniurge]

Woops nevermind found it, pushing a fix

[wilsonk]

Cool, thanks Elie.

That last fix seems to have worked. There is another one needed for the GDAL example to compile so I pushed a fix for skipping opaque struct's while mapping that has fixed things.

There is one more problem left to get the GDAL example that Suliman asked about to work, but I just commented out two lines in /usr/include/x86_64-linux-gnu/bits/stat.h to test ... and the example at http://www.gdal.org/warptut.html does actually compile and run!! :)

I will look into an actual fix tomorrow...it seems that 'struct stat' in that file and the function called 'stat'
in /usr/include/x86_64-linux-gnu/sys/stat.h are colliding?? Not sure why. I have a modulemap file in the bits directory that was necessary to get past a couple other collisions, but this one is not being resolved unfortunately.

Amazing that the class pointer fix is taking more than 650 lines...yikes!!

[Syniurge]

Nice! And damn about stat. There's no way around it with modulemap files, the static import "stat" needs to be renamed.

[Syniurge]

Fixed! And without renaming which seems a bit suspicious (shouldn't the "stat" import conflict with the "stat" function?).

Does your GDAL demo compile without hacks now?

[wilsonk]

Yes, my GDAL example compiles now without hacks...sweet!!