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 » Developing U++ » Releasing U++ » Tarball issues
Tarball issues [message #47365] Mon, 09 January 2017 09:47 Go to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
amrein wrote on Mon, 09 January 2017 02:07
I can change the domake script and force the use of clang++ instead of gcc if gcc version is lower than 4.9.0 for example.

I didn't found a quick fix for abs and other methods producing compilation errors with old gcc versions.



Well, I am not 100% what is the correct solution here, but

- we need to add to README that required gcc should be >= 5.0 (as older have problems with C++14 standard)

- maybe add warning (or even error) to domake

- we need to provide a way how to proceeed in that case, which is IMO:

- install latest GCC from e.g. tarball, then provide a name of the compiler (like g++-6.1.0) to domake / make somehowe
- install clang from distro package, as usually it is more OK with c++14 and again, change the compiler used by make
- maybe install clang from tarball...

Now how to provide the name of compiler I am not 100++ sure, but IMO either environment variable/commandline switch?

Or maybe that warning in domake should try to pick the correct compiler and ask user? Let him choose?

Mirek
Re: Tarball issues [message #47367 is a reply to message #47365] Mon, 09 January 2017 11:22 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
This will force the use of clang++:
make -e CXX="clang++" -e CXXFLAGS="-O3 -ffunction-sections -fdata-sections -Wno-logical-op-parentheses -std=c++11"

[TODO] - Add to readme and web documentation: gcc should be >= 5.0 (as older versions have problems with C++14 standard).
[TODO] - Add to readme and web documentation: solutions like (1) install clang++ or (2) install latest GCC.
[TODO] - Add to readme and web documentation: how to force make to use those compilers from command line.
[TODO] - Add to domake: warnings and errors.
[TODO] - Add to domake: pick clang++ instead of gcc if gcc version is too old and if clang is available.
Re: Tarball issues [message #47379 is a reply to message #47365] Tue, 10 January 2017 19:57 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
[DONE] - Add to domake: pick clang++ instead of gcc if gcc version is too old and if clang is available. (in fact, I did a complete rewrite of domake)
[DONE] - Add to domake: warnings and errors.

But also:

[DONE] - Add to doinstall: several parameter options (in fact, I did a complete rewrite of doinstall).
[DONE] - Add to doinstall: standard POSIX installation.
[DONE] - Add to doinstall: warnings and errors.

I didn't commit those two scripts (domake and doinstall) in svn. I'm not sure if you (as the stable release manager) want me to, before stable release.
Please tell me.

Not done obviously:

[TODO] - Add to readme and web documentation: gcc should be >= 5.0 (as older versions have problems with C++14 standard).
[TODO] - Add to readme and web documentation: solutions like (1) install clang++ or (2) install latest GCC.
[TODO] - Add to readme and web documentation: how to force make to use those compilers from command line.
Re: Tarball issues [message #47380 is a reply to message #47379] Tue, 10 January 2017 21:09 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello amrein,

Quote:

[TODO] - Add to readme and web documentation: gcc should be >= 5.0 (as older versions have problems with C++14 standard).


Our target c++ standard for this release is c++11, not c++14 and GCC versions lesser that 5.0 have got problems with the older one. Currently, only Android Builder supports c++14 by default. When, you will write documentation - please keep this digression in mind.

Sincerely,
Klugier


U++ - one framework to rule them all.

[Updated on: Tue, 10 January 2017 21:13]

Report message to a moderator

Re: Tarball issues [message #47381 is a reply to message #47380] Tue, 10 January 2017 22:47 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Tue, 10 January 2017 21:09


Our target c++ standard for this release is c++11, not c++14 and GCC versions lesser that 5.0 have got problems with the older one. Currently, only Android Builder supports c++14 by default. When, you will write documentation - please keep this digression in mind.

Sincerely,
Klugier


Actually, it is sort of fuzzy: We are using some C++14 features that are already available in all conforming C++11 compilers...

GCC options are certainly set to C++14.

Mirek
Re: Tarball issues [message #47382 is a reply to message #47379] Tue, 10 January 2017 22:49 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
amrein wrote on Tue, 10 January 2017 19:57
[DONE] - Add to domake: pick clang++ instead of gcc if gcc version is too old and if clang is available. (in fact, I did a complete rewrite of domake)
[DONE] - Add to domake: warnings and errors.

But also:

[DONE] - Add to doinstall: several parameter options (in fact, I did a complete rewrite of doinstall).
[DONE] - Add to doinstall: standard POSIX installation.
[DONE] - Add to doinstall: warnings and errors.

I didn't commit those two scripts (domake and doinstall) in svn. I'm not sure if you (as the stable release manager) want me to, before stable release.
Please tell me.


Please commit.

Mirek
Re: Tarball issues [message #47384 is a reply to message #47382] Wed, 11 January 2017 04:54 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Committed.

If it works as it should (me testing my own code is not enough), I will modify the documentation accordingly.
Re: Tarball issues [message #47387 is a reply to message #47384] Wed, 11 January 2017 13:01 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello amrein,

While running - "make" command on Ubuntu 16.04 I came across following error:
/bin/sh domake
domake: 14: domake: Bad substitution
Makefile:5: polecenia dla obiektu 'all' nie powiodły się
make: *** [all] Błąd 2


I think the problem is with 14 line of domake script:
script_name=${0^^}


When I removed that line I have got one more error:
/bin/sh domake
domake: 36: domake: Syntax error: "(" unexpected
Makefile:5: polecenia dla obiektu 'all' nie powiodły się


Sincerely,
Klugier


U++ - one framework to rule them all.

[Updated on: Wed, 11 January 2017 13:01]

Report message to a moderator

Re: Tarball issues [message #47389 is a reply to message #47387] Wed, 11 January 2017 15:15 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Thank you for that.

Causes:

- ${variable^^} uppercase substitution only work in bash
- function only work in bash
- echo is replaced by internal sh version that doesn't support escape character (so no color without calling /bin/echo explicitly)
- on most rpm based distribution, calling /bin/sh will always call /bin/bash and so none of those errors will ever occurs. :/

Fixed in SVN. Tested. Should be ok and ready for release.

Does it works for you now?
Re: Tarball issues [message #47391 is a reply to message #47389] Wed, 11 January 2017 17:35 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello,

The build process starts without error on latest SVN version of the script.

Sincerely,
Klugier


U++ - one framework to rule them all.

[Updated on: Wed, 11 January 2017 17:35]

Report message to a moderator

Re: Tarball issues [message #47392 is a reply to message #47391] Wed, 11 January 2017 20:21 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Klugier wrote on Wed, 11 January 2017 17:35
Hello,

The build process starts without error on latest SVN version of the script.

Sincerely,
Klugier


Does it finish too? Producing theide?

Mirek
Re: Tarball issues [message #47394 is a reply to message #47365] Wed, 11 January 2017 22:09 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
'make' and 'make install' do work (at least for me) on Debian and on a few rpm based distributions.

More feedback will be awesome. I couldn't test BSD and alike.

If you want to compile faster (not as fast as BLITZ) and install somewhere without messing up your current installation:
if which nproc
then
  make -j$(nproc)
else
  make
fi

make install "DESTDIR=$HOME/UPP-TEMP"

It will install U++ in $HOME/UPP-TEMP/$HOME as if it was your home directory.

If you want to see the POSIX installation in action:

if which nproc
then
  make -j$(nproc)
else
  make
fi

make install "DESTDIR=$HOME/UPP-TEMP" prefix=/usr/local

Re: Tarball issues [message #47395 is a reply to message #47394] Wed, 11 January 2017 22:42 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
Question:

- When creating POSIX binary packages, where should I copy the dictionaries (like en-gb.scd and en-us.scd) for theide to pick them?

-> I can't put them in /usr/bin, even if I know that it will work.
-> theide doesn't find them in /usr/share/upp nor does it in /usr/share/upp/scd and I can't figure it out (where does theide search for those files at first start...).

Could, but didn't help:
https:// sourceforge.net/projects/upp/files/SpellerDictionaries/Aspel l/

Re: Tarball issues [message #47398 is a reply to message #47395] Thu, 12 January 2017 07:47 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

Hi amrein,
amrein wrote on Wed, 11 January 2017 22:42
Question:

- When creating POSIX binary packages, where should I copy the dictionaries (like en-gb.scd and en-us.scd) for theide to pick them?

-> I can't put them in /usr/bin, even if I know that it will work.
-> theide doesn't find them in /usr/share/upp nor does it in /usr/share/upp/scd and I can't figure it out (where does theide search for those files at first start...).

Same problem as with the default GCC.bm... IIRC, I ended up putting it in /usr/share and copying it to $HOME/.upp/theide/ in the install step, which launches when the user first starts TheIDE. The dictionaries will be picked up by TheIDE when placed into the config directory. The unpleasant thing about this is, that it requires makeing this in code in TheIDE itself...

It would by great if U++ or at least TheIDE supported having global configuration in /etc and separate user configs that would overload the global settings. This is kind of standard behavior in posix world... But I think it would be pretty big change.

Best regards,
Honza
Re: Tarball issues [message #47399 is a reply to message #47395] Thu, 12 January 2017 08:49 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
amrein wrote on Wed, 11 January 2017 22:42

-> theide doesn't find them in /usr/share/upp nor does it in /usr/share/upp/scd and I can't figure it out (where does theide search for those files at first start...).


Core/Speller.cpp 149

I have added some for POSIX:

Speller *sGetSpeller(int lang)
{
	static ArrayMap<int, Speller> speller;
	int q = speller.Find(lang);
	if(q < 0) {
		String pp = spell_path;
		DoSpellerPath(pp, GetExeDirFile("scd"));
		DoSpellerPath(pp, ConfigFile("scd"));
		pp << spell_path << ';' << getenv("LIB") << ';' << getenv("PATH") << ';';
#ifdef PLATFORM_POSIX
		pp << "/usr/share/upp;/usr/local/share/upp;/usr/share/upp/scd;/usr/local/share/upp/scd";
#endif
		String path = GetFileOnPath(ToLower(LNGAsText(lang)) + ".udc", pp);
Re: Tarball issues [message #47401 is a reply to message #47394] Thu, 12 January 2017 09:10 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi Amrein,

I can confirm a successful build and install from source tarball 10699M using the instructions (make and make install) in readme file on Linux Mint 18.1 (based on Ubuntu). It was a clean install on a machine which did not have even gcc installed. And actually I left gcc out intentionally to test the tarball with clang which worked out of the box just as expected.

Best regards,

Tom
Re: Tarball issues [message #47403 is a reply to message #47401] Thu, 12 January 2017 12:27 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi,

Tested on a freshly installed TrueOS (based on FreeBSD).

After installing llvm39 and libnotify, make starts working. Making theide fails but umk gets built.

...
make[1]: don't know how to make ide/app.tpp/Aboutn-us.tppi. Stop

make[1]: stopped in /usr/home/tom/upp-x11-src-10699M/uppsrc


When compiling, strangely, the flags defined in compilation include flagGCC and flagLINUX, while compiling with CLANG on FreeBSD:
...
clang++ -c -x c++ -O3 -ffunction-sections -fdata-sections -Wno-logical-op-parentheses -std=c++11 -I./ -I/usr/local/include/gtk-2.0 -I/usr/local/include/pango-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libdrm -I/usr/local/include/libpng16 -I/usr/local/include/harfbuzz -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/atk-1.0   -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/X11R6/include -I/usr/X11R6/include/freetype2 -I/usr/X11R6/include/gtk-2.0 -I/usr/X11R6/include/glib-2.0 -I/usr/X11R6/lib/glib-2.0/include -I/usr/X11R6/lib/gtk-2.0/include -I/usr/X11R6/include/cairo -I/usr/X11R6/include/pango-1.0 -I/usr/X11R6/include/atk-1.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/gtkglext-1.0 -I/usr/lib/gtkglext-1.0/include -I/usr/lib/i386-linux-gnu/glib-2.0/include -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/lib/i386-linux-gnu/gtk-2.0/include -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -DflagGUI -DflagMT -DflagGCC -DflagSHARED -DflagLINUX -DflagPOSIX -DflagMAIN  ide/BaseDlg.cpp -o _out/ide//home/cxl/Scripts/GCCMK.bm-Gcc-Gui-Linux-Main-Mt-Posix-Shared/BaseDlg.o
...


Using umk I tried to rebuild theide but linking fails at -lfontconfig. Fontconfig is installed, but does not get linked. The library resides below /usr/local/lib, but only /usr/lib is included in library path.

Best regards,

Tom
Re: Tarball issues [message #47404 is a reply to message #47401] Thu, 12 January 2017 16:41 Go to previous messageGo to next message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
-> Thank Tom1.
So:
[ OK ] - Linux Mint 18.1
[ KO ] - TrueOS

Fontconfig in /usr/local? Manual install?
If possible, can you post the output on TrueOS of those three commands:
pkg-config --variable pcfiledir gtk+-2.0
pkg-config --variable pcfiledir fontconfig
cat "$(pkg-config --variable pcfiledir fontconfig)/fontconfig.pc"

My guess: pkg-config won't find fontconfig and "fontconfig.pc" is in /usr/local/lib*/pkgconfig/

-> Mirek: I tested with the new Core/Speller.cpp. It didn't work. Build Falgs: -DflagGCC -DflagSHARED -DflagLINUX -DflagPOSIX
There is somewhere in U++ ide package the code coping files and folders from /usr/share/upp/. This is what I fail to find. Because there I would be able to not just copy *.scd but instead move them to ~/.upp/theide.
I guess the good directory name could be /usr/share/upp/scd-usd/ or something similar.

-> dolik.rce: I agree. Great point. Hard-coded path can easily break because POSIX OS are moving targets.
This kind of thing needs coordination between packagers and developers as U++ is cross-platform.
Re: Tarball issues [message #47406 is a reply to message #47404] Thu, 12 January 2017 21:17 Go to previous messageGo to next message
Klugier is currently offline  Klugier
Messages: 1075
Registered: September 2012
Location: Poland, Kraków
Senior Contributor
Hello,

Yes, it compiles fine on my Ubuntu 16.04 machine, but at the end I have got following output:

_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/Builders.a \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/CppBuilder.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/MakeFile.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/GccBuilder.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/MscBuilder.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/JavaBuilder.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/ScriptBuilder.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/AndroidProject.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/AndroidApplicationMakeFile.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/AndroidMakeFile.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/AndroidModuleMakeFile.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/AndroidBuilder.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/AndroidBuilderCommands.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/AndroidBuilderUtils.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/AndroidModuleMakeFileBuilder.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/Blitz.o \
	_out/ide/Builders//home/cxl/Scripts/GCCMK.bm-Gcc-Linux-Posix-Shared/Build.o


And, I have one question - why this directory is appended "/home/cxl/". Am I cxl? Wink This is probably cosmetic issue, but should be fixed.

Sincerely,
Klugier



U++ - one framework to rule them all.
Re: Tarball issues [message #47409 is a reply to message #47406] Thu, 12 January 2017 23:06 Go to previous messageGo to previous message
amrein is currently offline  amrein
Messages: 278
Registered: August 2008
Location: France
Experienced Member
You have "/home/cxl/" appended because Makefile.in and uMakefile.in were built on the U++ server using umk.
The corresponding script is svn/trunk/uppbox/Scripts/src.

Those lines are what you are looking for:

Quote:

cp -p ~/Scripts/GCCMK.bm ~/.upp/theide

~/bin/umk ~/upp.src/uppsrc ide ~/Scripts/GCCMK.bm -asrXk ~/upp.tmp/upp/uppsrc

mv ~/upp.tmp/upp/uppsrc/Makefile ~/upp.tmp/upp/uppsrc/Makefile.in

~/bin/umk ~/upp.src/uppsrc umk ~/Scripts/GCCMK.bm -asrXk ~/upp.tmp/upp/uppsrc

mv ~/upp.tmp/upp/uppsrc/Makefile ~/upp.tmp/upp/uppsrc/uMakefile.in


Those modifications should fix it:

Quote:

cp -p ~/Scripts/GCCMK.bm ~/.upp/theide

~/bin/umk ~/upp.src/uppsrc ide GCCMK -asrXk ~/upp.tmp/upp/uppsrc

mv ~/upp.tmp/upp/uppsrc/Makefile ~/upp.tmp/upp/uppsrc/Makefile.in

~/bin/umk ~/upp.src/uppsrc umk GCCMK -asrXk ~/upp.tmp/upp/uppsrc

mv ~/upp.tmp/upp/uppsrc/Makefile ~/upp.tmp/upp/uppsrc/uMakefile.in


Committing...

[Updated on: Thu, 12 January 2017 23:11]

Report message to a moderator

Previous Topic: umk on U++ server is obsolete and creates bad Makefiles
Next Topic: Archlinux AUR
Goto Forum:
  


Current Time: Thu Mar 28 18:39:31 CET 2024

Total time taken to generate the page: 0.01550 seconds