U++ framework
Do not panic. Ask here before giving up.

Home » Community » U++ community news and announcements » 2020.1 officially released
Re: 2020.1 officially released [message #54130 is a reply to message #54123] Tue, 02 June 2020 16:35 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Mon, 01 June 2020 17:32
Maybe you can try cross-compilation.

https://github.com/mstorsjo/llvm-mingw/releases

If you do not have ubuntu 18.04, building llvm-mingw for you linux distro should be relatively simple....

It could be interesting experiment. Actually, we can even add a simple support in ide / umake to prepend binary with "wine" for execution... Smile

Mirek

First attempt is unsuccessful.
umk completely ignores all my attempts to set path to a different clang version.
I changed PATH and even put absolute path to clang into COMPILER.
Everything was ignored.

BTW, you put in PATH folders with dll-s ... What is that for?


Regards,
Novo
Re: 2020.1 officially released [message #54131 is a reply to message #54130] Tue, 02 June 2020 17:40 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Tue, 02 June 2020 16:35
mirek wrote on Mon, 01 June 2020 17:32
Maybe you can try cross-compilation.

https://github.com/mstorsjo/llvm-mingw/releases

If you do not have ubuntu 18.04, building llvm-mingw for you linux distro should be relatively simple....

It could be interesting experiment. Actually, we can even add a simple support in ide / umake to prepend binary with "wine" for execution... Smile

Mirek

First attempt is unsuccessful.
umk completely ignores all my attempts to set path to a different clang version.
I changed PATH and even put absolute path to clang into COMPILER.
Everything was ignored.



Can you post .bm?

Quote:
BTW, you put in PATH folders with dll-s ... What is that for?


Well, thats in case you somehow link with shared (.dll) standard library. PATH is used to running .exe from the ide as well. Also mysql, sdl and pgsql dlls.

Mirek

[Updated on: Tue, 02 June 2020 17:40]

Report message to a moderator

Re: 2020.1 officially released [message #54134 is a reply to message #54131] Tue, 02 June 2020 18:56 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Tue, 02 June 2020 11:40
Can you post .bm?

I fixed problem with clang++ by using x86_64-w64-mingw32-clang++ instead of it. Before that I was trying to use /home/ssg/.local/soft/llvm-mingw/llvm-mingw-20200325-ubuntu- 18.04/bin/clang++ as a compiler ... Plain clang++ didn't work by definition.

A new problem is that umk is passing POSIX and LINUX flags to x86_64-w64-mingw32-clang++ because it runs on Linux ... Smile
Basically, this makes cross-compilation impossible with the current umk ...

BTW, Upp is currently broken ...
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/Core/Ops.h:165:29: error: use of undeclared identifier 'HASH64_CONST3'
        return (dword)SwapEndian64(HASH64_CONST3 * h);
  • Attachment: CLANG.bm
    (Size: 1.25KB, Downloaded 349 times)


Regards,
Novo
Re: 2020.1 officially released [message #54135 is a reply to message #54134] Tue, 02 June 2020 21:07 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Tue, 02 June 2020 18:56
mirek wrote on Tue, 02 June 2020 11:40
Can you post .bm?

I fixed problem with clang++ by using x86_64-w64-mingw32-clang++ instead of it. Before that I was trying to use /home/ssg/.local/soft/llvm-mingw/llvm-mingw-20200325-ubuntu- 18.04/bin/clang++ as a compiler ... Plain clang++ didn't work by definition.

A new problem is that umk is passing POSIX and LINUX flags to x86_64-w64-mingw32-clang++ because it runs on Linux ... Smile
Basically, this makes cross-compilation impossible with the current umk ...


Hm, we probably need to add flags override to .bm, right?
Re: 2020.1 officially released [message #54136 is a reply to message #54135] Tue, 02 June 2020 21:20 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Tue, 02 June 2020 15:07
Novo wrote on Tue, 02 June 2020 18:56
mirek wrote on Tue, 02 June 2020 11:40
Can you post .bm?

I fixed problem with clang++ by using x86_64-w64-mingw32-clang++ instead of it. Before that I was trying to use /home/ssg/.local/soft/llvm-mingw/llvm-mingw-20200325-ubuntu- 18.04/bin/clang++ as a compiler ... Plain clang++ didn't work by definition.

A new problem is that umk is passing POSIX and LINUX flags to x86_64-w64-mingw32-clang++ because it runs on Linux ... Smile
Basically, this makes cross-compilation impossible with the current umk ...


Hm, we probably need to add flags override to .bm, right?

IMHO, we need an option for umk. Something like "target platform", "-t", I guess. Possible values should be "windows", "linux", "mac", "native", e.t.c.

Another useful option for umk on Windows is "use POSIX-like configuration files". I'm already doing this, but I manually change source code for that.


Regards,
Novo
Re: 2020.1 officially released [message #54137 is a reply to message #53839] Tue, 02 June 2020 21:26 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
This is how a command line looks at the moment ...
x86_64-w64-mingw32-clang++ -c `pkg-config --cflags freetype2` `pkg-config --cflags x11` `pkg-config --cflags xinerama` `pkg-config --cflags xrender` `pkg-config --cflags xft` `pkg-config --cflags xdmcp` `pkg-config --cflags fontconfig` `pkg-config --cflags xcb` `pkg-config --cflags xext` `pkg-config --cflags gtk+-3.0` `pkg-config --cflags libnotify` `pkg-config --cflags expat` `pkg-config --cflags libpng`  -I"/home/ssg/.local/soft/bb-worker/worker/mingw-sdb/build" -I"/home/ssg/dvlp/cpp/code/upp/git/bazaar" -I"/home/ssg/dvlp/cpp/code/upp/git/uppsrc" -I"/home/ssg/.wine/drive_c/local/apps/upp/bin/SDL2/include" -I"/home/ssg/.wine/drive_c/local/apps/upp/bin/pgsql/x64/include" -I"/home/ssg/.wine/drive_c/local/apps/upp/bin/mysql/include" -I"/home/ssg/.local/soft/bb-worker/worker/mingw-sdb/build/dvlp/plugin/sol3" -I"/home/ssg/.local/soft/bb-worker/worker/mingw-sdb/build/dvlp/plugin/lua/lib" -I"/home/ssg/.local/soft/bb-worker/worker/mingw-sdb/build/.cache/upp.out/Painter/CLANGcpp17.Debug.Debug_Full.Gui.Shared" -DflagGUI -DflagCLANG -DflagDEBUG -DflagSHARED -DflagDEBUG_FULL -DflagBLITZ -DflagPOSIX -DflagLINUX -ggdb -g2  -fexceptions -D_DEBUG -O0 -x c++ -Wall -Wno-logical-op-parentheses -std=c++17 "/home/ssg/dvlp/cpp/code/upp/git/uppsrc/Painter/SvgUtil.cpp"  -o "/home/ssg/.local/soft/bb-worker/worker/mingw-sdb/build/.cache/upp.out/Painter/CLANGcpp17.Debug.Debug_Full.Gui.Shared/SvgUtil.o"


Regards,
Novo
Re: 2020.1 officially released [message #54138 is a reply to message #54136] Tue, 02 June 2020 21:27 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Tue, 02 June 2020 21:20
mirek wrote on Tue, 02 June 2020 15:07
Novo wrote on Tue, 02 June 2020 18:56
mirek wrote on Tue, 02 June 2020 11:40
Can you post .bm?

I fixed problem with clang++ by using x86_64-w64-mingw32-clang++ instead of it. Before that I was trying to use /home/ssg/.local/soft/llvm-mingw/llvm-mingw-20200325-ubuntu- 18.04/bin/clang++ as a compiler ... Plain clang++ didn't work by definition.

A new problem is that umk is passing POSIX and LINUX flags to x86_64-w64-mingw32-clang++ because it runs on Linux ... Smile
Basically, this makes cross-compilation impossible with the current umk ...


Hm, we probably need to add flags override to .bm, right?

IMHO, we need an option for umk. Something like "target platform", "-t", I guess. Possible values should be "windows", "linux", "mac", "native", e.t.c.

Another useful option for umk on Windows is "use POSIX-like configuration files". I'm already doing this, but I manually change source code for that.


Well, we already can add flags via "Common fixed flags". I think all we need is "override" option that would avoid adding platform flags before adding these fixed. And then of replace any PLATFORM_ #ifdefs in GCC builder with if(HasFlag(...
Re: 2020.1 officially released [message #54139 is a reply to message #54138] Tue, 02 June 2020 21:33 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Tue, 02 June 2020 15:27

Well, we already can add flags via "Common fixed flags". I think all we need is "override" option that would avoid adding platform flags before adding these fixed. And then of replace any PLATFORM_ #ifdefs in GCC builder with if(HasFlag(...

IMHO, that won't affect stuff like `pkg-config --cflags x11` Smile
This is done by umk...

Edited: Or I'm missing something.


Regards,
Novo

[Updated on: Tue, 02 June 2020 21:37]

Report message to a moderator

Re: 2020.1 officially released [message #54140 is a reply to message #53839] Tue, 02 June 2020 21:39 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Another thing. umk is ignoring options from bm-files.
Even if I enable BLITZ in a bm-file, I still have to pass "-b" to umk...

Edited: I need to double-check that. Probably, I've got lost among ide, theide, and umk configuration folders ...
Edited again: Yes, umk ignores settings from bm-files.


Regards,
Novo

[Updated on: Wed, 03 June 2020 06:41]

Report message to a moderator

Re: 2020.1 officially released [message #54141 is a reply to message #54140] Wed, 03 June 2020 01:30 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
reference/GLDrawDemo is still broken. Smile
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/GLDraw/GLShaders.cpp:30:3: error: expected expression
                DLOG(error);
                ^


Regards,
Novo
Re: 2020.1 officially released [message #54142 is a reply to message #54138] Wed, 03 June 2020 07:37 Go to previous messageGo to next message
Sender Ghost is currently offline  Sender Ghost
Messages: 301
Registered: November 2008
Senior Member
mirek wrote on Tue, 02 June 2020 19:27

Well, we already can add flags via "Common fixed flags". I think all we need is "override" option that would avoid adding platform flags before adding these fixed.

As far as I know, there is a possibility to override platform related flags. This feature is implemented in LocalHost::AddFlags and LocalHost::HasPlatformFlag methods [1, 2, 3].
For example, possible to generate Makefile(s) for WIN32 platform, e.g.:
./umk uppsrc ide CLANG -r -M=Makefile +WIN32,GUI
or FreeBSD:
./umk uppsrc ide CLANG -rs -M=BSDMakefile +POSIX,BSD,FREEBSD,GUI
or Linux:
./umk uppsrc ide CLANG -rs -M=GNUMakefile +POSIX,LINUX,GUI
etc.

There is just a need to use correct build method for them. But I didn't test this for cross-platform/remote build(s), just for Makefile generation.

May suggest to add "OSX" flag to platformFlags also (based on order of appearance in LocalHost::AddFlags method). Patch attached.

[Updated on: Wed, 03 June 2020 08:28]

Report message to a moderator

Re: 2020.1 officially released [message #54143 is a reply to message #54136] Wed, 03 June 2020 09:28 Go to previous messageGo to next message
Tom1
Messages: 1319
Registered: March 2007
Ultimate Contributor
Quote:

IMHO, we need an option for umk. Something like "target platform", "-t", I guess. Possible values should be "windows", "linux", "mac", "native", e.t.c.

Hi,

This idea sounds very interesting. Especially if this could be possible to extend to TheIDE on Windows. Then it would be possible to build with CLANG on Windows directly for Raspberry Pi. This would make developing for RPi so much more convenient!

Best regards,

Tom
Re: 2020.1 officially released [message #54144 is a reply to message #54142] Wed, 03 June 2020 12:46 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Sender Ghost wrote on Wed, 03 June 2020 07:37
mirek wrote on Tue, 02 June 2020 19:27

Well, we already can add flags via "Common fixed flags". I think all we need is "override" option that would avoid adding platform flags before adding these fixed.

As far as I know, there is a possibility to override platform related flags. This feature is implemented in LocalHost::AddFlags and LocalHost::HasPlatformFlag methods [1, 2, 3].
For example, possible to generate Makefile(s) for WIN32 platform, e.g.:
./umk uppsrc ide CLANG -r -M=Makefile +WIN32,GUI
or FreeBSD:
./umk uppsrc ide CLANG -rs -M=BSDMakefile +POSIX,BSD,FREEBSD,GUI
or Linux:
./umk uppsrc ide CLANG -rs -M=GNUMakefile +POSIX,LINUX,GUI
etc.

There is just a need to use correct build method for them. But I didn't test this for cross-platform/remote build(s), just for Makefile generation.

May suggest to add "OSX" flag to platformFlags also (based on order of appearance in LocalHost::AddFlags method). Patch attached.


Yes, but that ADDs flags. The problem is that there are default, platform defined flags too. We need a method to clear those...

Well, radical solution would be to remove them completely and move them strictly to build method. Less radical is to add an option "No default flags" to build method.

Second problem is that there are some #ifdef PLATFORM_ conditional compilation flags in GCC builder. Those need to be replaced to actually react to current flag configuration.

Mirek
Re: 2020.1 officially released [message #54145 is a reply to message #54141] Wed, 03 June 2020 13:51 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Wed, 03 June 2020 01:30
reference/GLDrawDemo is still broken. Smile
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/GLDraw/GLShaders.cpp:30:3: error: expected expression
                DLOG(error);
                ^

Thanks, fixed.
Re: 2020.1 officially released [message #54147 is a reply to message #54145] Wed, 03 June 2020 16:16 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Wed, 03 June 2020 07:51
Novo wrote on Wed, 03 June 2020 01:30
reference/GLDrawDemo is still broken. Smile
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/GLDraw/GLShaders.cpp:30:3: error: expected expression
                DLOG(error);
                ^

Thanks, fixed.

This fix didn't get propagated into git ...


Regards,
Novo
Re: 2020.1 officially released [message #54148 is a reply to message #54144] Thu, 04 June 2020 05:16 Go to previous messageGo to next message
Sender Ghost is currently offline  Sender Ghost
Messages: 301
Registered: November 2008
Senior Member
mirek wrote on Wed, 03 June 2020 10:46

Yes, but that ADDs flags. The problem is that there are default, platform defined flags too. We need a method to clear those...

Actually, this is what it does before adding default platform flags, defined by #if(def)(s), if some platform flag was found for override:
if(HasPlatformFlag(cfg))
	return;

Novo wrote on Tue, 02 June 2020 19:20

IMHO, we need an option for umk. Something like "target platform", "-t", I guess.

Thanks for suggestion. I proposed this feature on Redmine #2041.
Re: 2020.1 officially released [message #54149 is a reply to message #53839] Thu, 04 June 2020 10:31 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
I have removed all #ifdef PLATFORM_* from GCC builder (except one case where this was not possible, but that one should not affect POSIX -> WIN32 compilation).

As for target option, I do not think it is necessarry (as corretly pointed out by SenderGhost). As long as you specify any platform flag in commandline, the build process will avoid adding these, so you should be OK.

Mirek
Re: 2020.1 officially released [message #54150 is a reply to message #54113] Thu, 04 June 2020 10:37 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Mon, 01 June 2020 21:35
There is another unexpected problem with Clang on Windows.
If I add "-std=c++17" to cpp options, then in case of GUI app (example: tutorial/Gui01) in Debug configuration I get this (Release is fine):
[code]Linking...
lld-link: error: duplicate symbol: std::__throw_bad_alloc()
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:315
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debu g_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)

lld-link: error: duplicate symbol: operator new(unsigned long long)
>>> defined at c:\local\apps\upp\uppsrc\Core\heap.cpp:301
>>> c:/local/apps/upp/out/tutorial/Core/CLANGx64cpp17.Debug.Debu g_Full.Gui\heap.o
>>> defined at libc++.a(new.cpp.obj)


I have checked this one and unfortunately it seems like another instance of weak symbol bug

https://github.com/mstorsjo/llvm-mingw/issues/91

so the options are:

- USEMALLOC flag (this will switch off U++ allocator completely)
- STD_NEWDELETE flag (this will keep U++ allocator and use it where possible but will use standard new/delete - this is default on MacOS BTW)
- Try with GIT head, as Martin claims this is now fixed. This would be most interesting option for me Smile (Being there, you could check msvcrt version too).

Mirek
Re: 2020.1 officially released [message #54151 is a reply to message #54149] Thu, 04 June 2020 13:52 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Thu, 04 June 2020 04:31
I have removed all #ifdef PLATFORM_* from GCC builder (except one case where this was not possible, but that one should not affect POSIX -> WIN32 compilation).

Thanks.
Unfortunately, your last commit broke linking of Linux console apps.
Linking...
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/.cache/upp.out/ide/Builders/CLANG.Debug.Debug_Full.Noblitz.Shared/Builders.a(Cocoa.o): in function `GccBuilder::CocoaAppBundle()':
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:18: undefined reference to `Upp::StreamRaster::LoadFileAny(char const*, Upp::Function<bool (int, int)>)'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:26: undefined reference to `Upp::Image::~Image()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:26: undefined reference to `Upp::Image::~Image()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:48: undefined reference to `Upp::Image::Image(Upp::Image const&)'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:51: undefined reference to `Upp::PNGEncoder::PNGEncoder(int, Upp::ImageKind, bool)'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:51: undefined reference to `Upp::Rescale(Upp::Image const&, int, int, Upp::Function<bool (int, int)>)'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:51: undefined reference to `Upp::StreamRasterEncoder::SaveFile(char const*, Upp::Image const&)'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:51: undefined reference to `Upp::Image::~Image()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:51: undefined reference to `Upp::PNGEncoder::~PNGEncoder()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:52: undefined reference to `Upp::Image::~Image()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:51: undefined reference to `Upp::Image::~Image()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:51: undefined reference to `Upp::PNGEncoder::~PNGEncoder()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/ide/Builders/Cocoa.cpp:52: undefined reference to `Upp::Image::~Image()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/.cache/upp.out/ide/Builders/CLANG.Debug.Debug_Full.Noblitz.Shared/Builders.a(Cocoa.o): in function `PNGRaster__initialize_struct':
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/plugin/png/png.h:8: undefined reference to `Upp::PNGRaster__initializer()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/.cache/upp.out/ide/Builders/CLANG.Debug.Debug_Full.Noblitz.Shared/Builders.a(Cocoa.o): in function `Upp::SortedVectorMap<int, Upp::Image, Upp::StdLess<int> >::Add(int const&, Upp::Image const&)':
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/Core/InVector.h:650: undefined reference to `Upp::Image::operator=(Upp::Image const&)'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/Core/InVector.h:650: undefined reference to `Upp::Image::~Image()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/Core/InVector.h:650: undefined reference to `Upp::Image::~Image()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/.cache/upp.out/ide/Builders/CLANG.Debug.Debug_Full.Noblitz.Shared/Builders.a(Cocoa.o): in function `void Upp::Destroy<Upp::Image>(Upp::Image*, Upp::Image const*)':
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/Core/Vcont.h:28: undefined reference to `Upp::Image::~Image()'
/usr/bin/ld: /home/ssg/.local/soft/bb-worker/worker/l-upp/build/.cache/upp.out/ide/Builders/CLANG.Debug.Debug_Full.Noblitz.Shared/Builders.a(Cocoa.o): in function `Upp::Image Upp::clone<Upp::Image>(Upp::Image const&)':
/home/ssg/.local/soft/bb-worker/worker/l-upp/build/uppsrc/Core/Defs.h:398: undefined reference to `Upp::Image::Image(Upp::Image const&)'

Basically, umk cannot be built either using a Makefile or umk itself ...


Regards,
Novo

[Updated on: Thu, 04 June 2020 14:10]

Report message to a moderator

Re: 2020.1 officially released [message #54152 is a reply to message #54151] Thu, 04 June 2020 14:24 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Sorry, fixed at the price of another #ifdef, which will mean you cannot build OSX GUI appliaction in LINUX (which is impossible anyway).

Mirek

[Updated on: Thu, 04 June 2020 14:24]

Report message to a moderator

Re: 2020.1 officially released [message #54153 is a reply to message #54152] Thu, 04 June 2020 16:00 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Thu, 04 June 2020 08:24
Sorry, fixed at the price of another #ifdef, which will mean you cannot build OSX GUI appliaction in LINUX (which is impossible anyway).

Mirek

Thanks!


Regards,
Novo
Re: 2020.1 officially released [message #54156 is a reply to message #53839] Thu, 04 June 2020 17:35 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
A minor issue with mingw on Linux.
umk calls x86_64-w64-mingw32-windres.exe, which is called x86_64-w64-mingw32-windres (no extension) on Linux, otherwise +WIN32 seems to work ...


Regards,
Novo
Re: 2020.1 officially released [message #54165 is a reply to message #53839] Thu, 04 June 2020 21:14 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Another interesting observation. Size of executable.

mingw:
:~/.local/soft/bb-worker/worker/mingw-upp/build/.cache/upp.out/CLANG.Blitz.Gui.Win32$ ll AK.exe 
-rwx------ 1 ssg ssg 2541056 Jun  4 14:56 AK.exe*

wine:
:~/.local/soft/bb-worker/worker/wine-upp/build/.cache/upp.out/CLANGx64.Blitz.Gui$ ll AK.exe 
-rwxrwxr-x 1 ssg ssg 5104128 Jun  4 14:28 AK.exe*

Two times bigger.
Both are 64-bit executables.


Regards,
Novo
Re: 2020.1 officially released [message #54167 is a reply to message #54165] Fri, 05 June 2020 04:59 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Problem with mingw & linking when compiling reference/GuiWebCrawler.
Command line contains "-lcrypto -lssl".
Linker is looking for libcrypto.a & libssl.a, which are named crypto.lib & ssl.lib.
Even after creating of links with correct names linker is still looking for libLIBCMT.a & libOLDNAMES.a, which are not available ...


Regards,
Novo
Re: 2020.1 officially released [message #54168 is a reply to message #54156] Fri, 05 June 2020 05:03 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Novo wrote on Thu, 04 June 2020 11:35
A minor issue with mingw on Linux.
umk calls x86_64-w64-mingw32-windres.exe, which is called x86_64-w64-mingw32-windres (no extension) on Linux, otherwise +WIN32 seems to work ...

Could you please fix that?
You just need to replace
String windres = "windres.exe";

with
String windres = "windres";


TIA


Regards,
Novo
Re: 2020.1 officially released [message #54169 is a reply to message #53839] Fri, 05 June 2020 05:44 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Compilation speed of mingw is good.
Eigen_demo compiles in 35 sec. Smile

This is Debug:
$ ./umk reference Eigen_demo CLANG -bu
...
----- Eigen_demo ( WIN32 MAIN CLANG DEBUG DEBUG_FULL BLITZ ) (4 / 4)
BLITZ: eigen_demo.cpp non-linear.cpp fft.cpp
In file included from /home/ssg/.local/soft/bb-worker/worker/mingw-upp/build/.cache/upp.out/Eigen_demo/CLANG.Debug.Debug_Full.Main.Win32/Eigen_demo$blitz.cpp:3:
In file included from /home/ssg/.local/soft/bb-worker/worker/mingw-upp/build/reference/Eigen_demo/eigen_demo.cpp:1:
In file included from /home/ssg/.local/soft/bb-worker/worker/mingw-upp/build/uppsrc/Core/Core.h:281:
/home/ssg/.local/soft/bb-worker/worker/mingw-upp/build/uppsrc/Core/Mem.h:342:8: warning: unused variable 'Cmp128' [-Wunused-variable]
                auto Cmp128 = [&](size_t at) { return _mm_cmpeq_epi32(_mm_loadu_si128((__m128i *)(s + at)), _mm_loadu_si128((__m128i *)(t + at))); };
                     ^
In file included from /home/ssg/.local/soft/bb-worker/worker/mingw-upp/build/.cache/upp.out/Eigen_demo/CLANG.Debug.Debug_Full.Main.Win32/Eigen_demo$blitz.cpp:3:
In file included from /home/ssg/.local/soft/bb-worker/worker/mingw-upp/build/reference/Eigen_demo/eigen_demo.cpp:1:
In file included from /home/ssg/.local/soft/bb-worker/worker/mingw-upp/build/uppsrc/Core/Core.h:285:
In file included from /home/ssg/.local/soft/bb-worker/worker/mingw-upp/build/uppsrc/Core/String.h:956:
/home/ssg/.local/soft/bb-worker/worker/mingw-upp/build/uppsrc/Core/AString.hpp:270:14: warning: unused variable 't' [-Wunused-variable]
        const char *t = begin();
                    ^
2 warnings generated.
Eigen_demo: 3 file(s) built in (0:34.91), 11637 msecs / file

Release takes 45 sec.
Mission is acomplished Smile


Regards,
Novo

[Updated on: Fri, 05 June 2020 05:56]

Report message to a moderator

Re: 2020.1 officially released [message #54171 is a reply to message #54165] Fri, 05 June 2020 09:34 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Thu, 04 June 2020 21:14
Another interesting observation. Size of executable.

mingw:
:~/.local/soft/bb-worker/worker/mingw-upp/build/.cache/upp.out/CLANG.Blitz.Gui.Win32$ ll AK.exe 
-rwx------ 1 ssg ssg 2541056 Jun  4 14:56 AK.exe*



Not sure what is "mingw" here... Do you mean llvm-mingw toolchain in crosscompile mode?

If yes, could you activate Verbose mode and compare all compiler/linker options?

Mirek
Re: 2020.1 officially released [message #54172 is a reply to message #54168] Fri, 05 June 2020 09:37 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Fri, 05 June 2020 05:03
Novo wrote on Thu, 04 June 2020 11:35
A minor issue with mingw on Linux.
umk calls x86_64-w64-mingw32-windres.exe, which is called x86_64-w64-mingw32-windres (no extension) on Linux, otherwise +WIN32 seems to work ...

Could you please fix that?
You just need to replace
String windres = "windres.exe";

with
String windres = "windres";


TIA


I will, but it is not that easy - if I do above, it will stop working in Win32. I can add #ifdef PLATFORM_ perhaps, or I can try to test which variant exists...

Mirek
Re: 2020.1 officially released [message #54173 is a reply to message #54167] Fri, 05 June 2020 09:44 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Fri, 05 June 2020 04:59
Problem with mingw & linking when compiling reference/GuiWebCrawler.
Command line contains "-lcrypto -lssl".
Linker is looking for libcrypto.a & libssl.a, which are named crypto.lib & ssl.lib.


Can you try to add .lib in package organizer? Just to know it that helps.

Re: 2020.1 officially released [message #54181 is a reply to message #54171] Fri, 05 June 2020 17:16 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Fri, 05 June 2020 03:34
Novo wrote on Thu, 04 June 2020 21:14
Another interesting observation. Size of executable.

mingw:
:~/.local/soft/bb-worker/worker/mingw-upp/build/.cache/upp.out/CLANG.Blitz.Gui.Win32$ ll AK.exe 
-rwx------ 1 ssg ssg 2541056 Jun  4 14:56 AK.exe*



Not sure what is "mingw" here... Do you mean llvm-mingw toolchain in crosscompile mode?

If yes, could you activate Verbose mode and compare all compiler/linker options?

Mirek

Yes, "mingw" is llvm-mingw toolchain in cross-compile mode.
Please check attached file.
txt-files is what you asked for.
log-files - complete build logs.
  • Attachment: 01.zip
    (Size: 14.77KB, Downloaded 286 times)


Regards,
Novo
Re: 2020.1 officially released [message #54183 is a reply to message #54173] Fri, 05 June 2020 20:09 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Fri, 05 June 2020 03:44
Novo wrote on Fri, 05 June 2020 04:59
Problem with mingw & linking when compiling reference/GuiWebCrawler.
Command line contains "-lcrypto -lssl".
Linker is looking for libcrypto.a & libssl.a, which are named crypto.lib & ssl.lib.


Can you try to add .lib in package organizer? Just to know it that helps.


Adding .lib to crypto & ssl doesn't affect anything.

BTW, precompiled ssl is already included into Clang distribution bundled with Upp.
And, I guess, Clang is using its own ssl ...
And one shipped with Upp seems to be compiled with msvc ...

Another thing. llvm-mingw-20200325-ubuntu-18.04 doesn't include a prebuilt version of ssl ...
This is weird ...


Regards,
Novo

[Updated on: Fri, 05 June 2020 20:21]

Report message to a moderator

Re: 2020.1 officially released [message #54185 is a reply to message #54145] Fri, 05 June 2020 22:24 Go to previous messageGo to next message
luoganda is currently offline  luoganda
Messages: 217
Registered: November 2016
Experienced Member
reference/GLDrawDemo doesn't work properly..
Tested in kubuntu 18.04, without changing anything, that is: GUI.NOGTK, GCC Debug.

App compiles ok, but when it's run - window is ok - but where GLCtrl is - nothing is drawn.
And when app is closed, there comes a dialog with 'Fatal error:' and message 'Heap leaks detected!'
Re: 2020.1 officially released [message #54186 is a reply to message #54150] Fri, 05 June 2020 22:24 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Thu, 04 June 2020 04:37

- Try with GIT head, as Martin claims this is now fixed. This would be most interesting option for me Smile (Being there, you could check msvcrt version too).

Mirek

Checked against GIT head. The problem is still there.

What do you mean by msvcrt version?


Regards,
Novo
Re: 2020.1 officially released [message #54191 is a reply to message #54183] Sat, 06 June 2020 10:26 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Fri, 05 June 2020 20:09
mirek wrote on Fri, 05 June 2020 03:44
Novo wrote on Fri, 05 June 2020 04:59
Problem with mingw & linking when compiling reference/GuiWebCrawler.
Command line contains "-lcrypto -lssl".
Linker is looking for libcrypto.a & libssl.a, which are named crypto.lib & ssl.lib.


Can you try to add .lib in package organizer? Just to know it that helps.


Adding .lib to crypto & ssl doesn't affect anything.

BTW, precompiled ssl is already included into Clang distribution bundled with Upp.


Yes, but that one does not work with MSVC...

Frankly, it is dancing between blades.... I was really happy to find working solution for genuine windows for all small issues involved. It is really stupid that it has wine problem.

Mirek
Re: 2020.1 officially released [message #54192 is a reply to message #54186] Sat, 06 June 2020 10:30 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 14290
Registered: November 2005
Ultimate Member
Novo wrote on Fri, 05 June 2020 22:24
mirek wrote on Thu, 04 June 2020 04:37

- Try with GIT head, as Martin claims this is now fixed. This would be most interesting option for me Smile (Being there, you could check msvcrt version too).

Mirek

Checked against GIT head. The problem is still there.


Just to be sure: I mean llvm-mingw head (not U++)....

Quote:

What do you mean by msvcrt version?


By default, llvm-mingw builds for universal CRT, which is the new Windows OS C library in Win10 (and via system updates, since Win7). There is older one, "msvcrt.dll" which is present sice WinNT. However, situation is more complicated:

https://github.com/mstorsjo/llvm-mingw/issues/104

Still, it would probably be better to ship with msvcrt version... maybe next release.

Mirek
Re: 2020.1 officially released [message #54199 is a reply to message #54192] Sun, 07 June 2020 15:22 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Sat, 06 June 2020 04:30
Novo wrote on Fri, 05 June 2020 22:24
mirek wrote on Thu, 04 June 2020 04:37

- Try with GIT head, as Martin claims this is now fixed. This would be most interesting option for me Smile (Being there, you could check msvcrt version too).

Mirek

Checked against GIT head. The problem is still there.


Just to be sure: I mean llvm-mingw head (not U++)....

Yes, I've built llvm-mingw from git. This is easy. Just one simple command.
I'm still getting the same "duplicated symbols" error messages.


Regards,
Novo
Re: 2020.1 officially released [message #54200 is a reply to message #54192] Sun, 07 June 2020 15:45 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Sat, 06 June 2020 04:30

By default, llvm-mingw builds for universal CRT, which is the new Windows OS C library in Win10 (and via system updates, since Win7). There is older one, "msvcrt.dll" which is present sice WinNT. However, situation is more complicated:

https://github.com/mstorsjo/llvm-mingw/issues/104

Still, it would probably be better to ship with msvcrt version... maybe next release.

Mirek

I'm a little bit confused. I thought that x86_64-w64-mingw32-clang++ builds for msvcrt, and x86_64-w64-mingw32uwp-clang++ builds for ucrt.

Anyway, I'll try to recompile llvm-mingw with --with-default-msvcrt=msvcrt on the build-mingw-w64.sh line.


Regards,
Novo
Re: 2020.1 officially released [message #54201 is a reply to message #54200] Sun, 07 June 2020 16:08 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
Novo wrote on Sun, 07 June 2020 09:45

Anyway, I'll try to recompile llvm-mingw with --with-default-msvcrt=msvcrt on the build-mingw-w64.sh line.

That didn't help. I'm still getting same errors.
The only solution so far is to use the USEMALLOC flag.


Regards,
Novo
Re: 2020.1 officially released [message #54202 is a reply to message #54201] Sun, 07 June 2020 16:52 Go to previous messageGo to next message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
A minor issue with umk.
It doesn't check for duplicate flags.
I have USEMALLOC defined in a project file and in a bm-file. In the end I get this:
CLANGx64cpp17.Debug.Debug_Full.Gui.Usemalloc.Usemalloc


Regards,
Novo
Re: 2020.1 officially released [message #54203 is a reply to message #54191] Sun, 07 June 2020 17:41 Go to previous messageGo to previous message
Novo is currently offline  Novo
Messages: 1431
Registered: December 2006
Ultimate Contributor
mirek wrote on Sat, 06 June 2020 04:26

Frankly, it is dancing between blades.... I was really happy to find working solution for genuine windows for all small issues involved. It is really stupid that it has wine problem.

Mirek

IMHO, the "wine problem" is not a problem anymore.
Wine is not needed anymore because we have cross-compilation now. (It would be interesting to check Upp against a a standard gcc-based mingw)

IMHO, a real problem is a problem with new/delete and cpp17. But even this problem has a workaround ...

Life is good Smile


Regards,
Novo
Previous Topic: get_i
Next Topic: theide: New Threads tab in PDB debugger
Goto Forum:
  


Current Time: Sat Apr 25 17:53:56 GMT+2 2026

Total time taken to generate the page: 0.02050 seconds