Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
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: 1358
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: 13975
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: 1358
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 168 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: 13975
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: 1358
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: 1358
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: 13975
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: 1358
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: 1358
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: 1358
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: 1212
Registered: March 2007
Senior 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: 13975
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: 13975
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: 1358
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: 13975
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: 13975
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: 1358
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 previous message
mirek is currently offline  mirek
Messages: 13975
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

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


Current Time: Thu Mar 28 21:56:18 CET 2024

Total time taken to generate the page: 0.01617 seconds