Unable to build Codelite 1.0 (bld 1789) on Fedora-8 (64-bit)

[rajkrish]

I am trying to build Codelite (v1.0 build 1789) from source. After the "confugure" and the usual global "make" steps, the build failed. I tracked down that building Gizmos is failing due to missing "pluginu" library:

Code: Select all

  $ cd Codelite*/Gizmos
  $ make
=================================================
Building target Gizmos
=================================================
test -d  Release_gcc_unicode || mkdir Release_gcc_unicode
test -d  ../lib || mkdir ../lib
g++  -fPIC   -O3 -DREGEXP_UNICODE    -shared  -o ../lib/Gizmos.so Release_gcc_unicode/gizmos.o Release_gcc_unicode/newclassbasedlg.o Release_gcc_unicode/newclassdlg.o Release_gcc_unicode/newinheritancebasedlg.o Release_gcc_unicode/newinheritancedlg.o Release_gcc_unicode/newplugindata.o Release_gcc_unicode/newwxprojectbasedlg.o Release_gcc_unicode/newwxprojectdlg.o Release_gcc_unicode/newwxprojectinfo.o Release_gcc_unicode/pluginwizard.o Release_gcc_unicode/pluginwizard_pag2.o Release_gcc_unicode/pluginwizard_page1.o  -L../lib -lcurl -lpluginu -lcodeliteu -lwxsqlite3u -lwxscintillau -L../sdk/sqlite3/lib -pthread   -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
/usr/bin/ld: cannot find -lpluginu
collect2: ld returned 1 exit status
make: *** [Gizmos] Error 1

Any ideas why?

I checked under the Plugin/ folder that there is no Makefile there. Is that missing from the source distribution (if that is what I am missing)?

Thanks in advance.

[eranif]

Hi,

1. I strongly recommed you build the latest version (if you are building from sources) - which should be revision 1962

2. Check under path/to/codelite/sources/trunk/lib --> do you see the libpluginu.a there?

Eran

[rajkrish]

The one I am compiling (v1789) I don't have any libpluginu.a anywhere in the source tree.

I don't mind building v1962, if you recommend it. But I am not able to find the zipped sources or a tarball for that version.

I would appreciate if someone could upload the latest tarball for 1962. This is because if I am able to build Codelite, I might possibly submit it to the Fedora distribution. For this reason, a specific, versioned source-only tarball (preferable, but zip will do) needs to be made available at your site.

I am afraid you might be referring to the svn/trunk at version 1962. If that is the case, I may not prefer to use it to build that for Fedora. The only other latest version I see is rev1927:
https://sourceforge.net/project/showfil ... /&abmode=1

Could you verify the status of ref1927 (that is, how stable it would be) if you are not planning to upload a versioned rev1962 source package anytime soon?
-Rajesh

[eranif]

OK, lets focus on the rev1789 which you are currently trying to build - I will upload version later but I want to make sure it has no regressions before I do.

libpluginu.a is supposed to be created before codelite's makefile compiles the Gizmos plugin.

The problem is here:

$ cd Codelite*/Gizmos
$ make

What is this CodeLite*/Gizmos command? this is not the way to build codelite.

To build codelite you should do this (rev1789):
Assuming you opened codelite's zip into '/CodeLite-Rev1789-V1.0':

Code: Select all

cd /CodeLite-Rev1789-V1.0
chmod +x ./configure
./configure
make

You should not 'cd' manually to any of the sub directories. For some reason, the ./configure lost its execution permission, my guess that it is something to do with the zip format, next time I will upload tar.gz

Once you succeeded (I dont see any reason why you should not succeed ), I prefer that you will submit a more recent version - but lets talk about it once you manage to compile it.

Eran

[rajkrish]

Eran,

I figured out that the configure needs its execute permission. I first tried the whole "./configure; make" thing, and it failed. Only then I started delving deeper into where the failure was occurring. Only then I went into the Gizmos folder (and hence the cd command) and figured out that pluginu.a is missing, causing a build failure.

On further investigation it seems that the "make" step fails if you specify parallel build, like so:
$ make -j3
I have a dual core machine, and the -jN is the usual way to speed up compilation for standard makefiles. If you try with the default (-j1), it builds correctly. I had a setting of -j3 elsewhere for my dual-core machine to speedup the builds.

So if you have access to a dual/quad core machine and try the -jN, N>3 option, I bet you would see the libpluginu.a error. Here is the standard-error output of the "make -j3" build:

Code: Select all

  $ make -j3 2>&1 > /tmp/codelite-1.0.1789.failure.txt
svn: '.' is not a working copy
gdb_lexer.cpp: In function ‘int le_gdb_lex()’:
gdb_lexer.cpp:728: warning: label ‘find_rule’ defined but not used
gdb_lexer.cpp: At global scope:
gdb_lexer.cpp:1768: warning: ‘void* yy_flex_realloc(void*, yy_size_t)’ defined but not used
gdb_lexer.cpp:1251: warning: ‘void yyunput(int, char*)’ defined but not used
/usr/bin/ld: cannot find -lpluginu
collect2: ld returned 1 exit status
make[1]: *** [Debugger] Error 1
make: *** [Debugger] Error 2
make: *** Waiting for unfinished jobs....
/usr/bin/ld: cannot find -lpluginu
collect2: ld returned 1 exit status
make[1]: *** [cscope] Error 1
make: *** [cscope] Error 2
/usr/bin/ld: cannot find -lpluginu
collect2: ld returned 1 exit status
make[1]: *** [Gizmos] Error 1
make: *** [Gizmos] Error 2

I believe the "make -jN", N > 1 error would occur if the build dependencies are not specified correctly throughout the project.

But for now I think we should advise everyone who want to build from source, to use only -J1 during the "make" step, in order for the compilation to go through. But do try out with -j3 (for dual-core machines) or -j5 (for quad-core machines) and doublecheck if the build-errors happen.

-Rajesh Krishnan

[eranif]

it is a bug in make. since the -jN flag, should use only single build when it comes to link/archive rules. It should only build dependencies in parallel. The problem is that for each file there are 2 steps:
- build the dependency for the file (-MT/-MF)
- build the file itself

Code: Select all

Release_gcc_unicode/LexLisp.o.d:
        $(CMP) $(CCFLAGS) $(INCLUDES) -MTRelease_gcc_unicode/LexLisp.o -MFRelease_gcc_unicode/LexLisp.o.d  -MM sdk/wxscintilla/src/scintilla/src/LexLisp.cxx

If you run first with -j1 (or no -j at all), it will work well, next builds (with -jN) will work properly since there is no need to create .o.d file.

Btw, CodeLite's build system itself uses the -j feature and it works great (my machines are all dual core) this is done automatically on startup, codelite will ask you if it can adjust the number of concurrent build processes.

Eran

[rajkrish]

If -jN feature is a bug in make, then how come so many other autoconf based packages build cleanly with the -jN, N>1 option? I am asking this as I am not too familiar with the internals of autoconf packages, though I have built a lot of them.

And though the following question may not be relevant to the topic of this thread, I will ask anyway.
Do you have any plans to migrate to other well-known build systems like Autoconf or Cmake? Note that I am not arguing about how good or bad these alternatives are, when compared to the custom configure setup Codelite has currently. Just that when I looked at the configure and other build related scripts inside the Codelite package, I found found things like hardcoded "/usr/local" everywhere. This is the reason I am not able to package it into an RPM for Fedora. And I am so not surprised as to why such a nice IDE like Codelite is not more popular with some of the most popular Linux distributions out there (besides the custom .deb you provide on SF.net, which may be good enough for Debian based distros, but not others).

I believe that:
1. if codelite was packaged "correctly", that is with the "generally accepted" package naming convention like "codelite-1.0.1789.tar.gz" for the *nix platforms, instead of the cryptic "CodeLite.app-rev1927.zip" or "CodeLite-rev1789-v1.0.src.zip", and

2. if codelite was more easily buildable using the "standard" *nix build toolchains like Autoconf or Cmake (I know they are not the greatest, but a vast number of them use those for a reason, because they are easy to build and deploy for multiple platforms),

then Codelite would have found itself much bigger audience and a set of contributors.

Again, please don't take this personally. I am not trying to criticize anyone. I admire your ability for developing such a great IDE and making it opensource to the public. I just feel that a lot many more users could benefit from it, had it not been for the custom configure system that has hardcoded paths and non-standard naming policies that impedes deployability.

Hope you would understand where I am coming from.

-Rajesh

[eranif]

Do you have any plans to migrate to other well-known build systems like Autoconf

Actually, I dont see any reason why should I move. My current shell configure script is pretty good, the problem is not with that configure but with the g++ dependencies generated - this problem needs to be solved regardless the tool I may use to generate the makefile

or Cmake?

Well, a good friend of mine is managing a well known open source project (dont know if you heard of it, http://krusader.org, and he is using CMake, and told me to stay out of it.

I found found things like hardcoded "/usr/local" everywhere.

You should have a look at the latest revision - all hard coded entries are removed and replaced with $(DESTIR) and $(PREFIX) ( you can run the configure using --prefix)

This is the reason I am not able to package it into an RPM for Fedora

see my previous comment about the configure script modifications

instead of the cryptic "CodeLite.app-rev1927.zip"

This is not the *nix package but the Mac OS X package MacOSX knows that the bundle app is always named AppName.app

2. if codelite was more easily buildable using the "standard" *nix build toolchains like Autoconf or Cmake (I know they are not the greatest, but a vast number of them use those for a reason, because they are easy to build and deploy for multiple platforms),

Again, the standard way of building is:

Code: Select all

./configre && make && make install

Running this command for codelite works for many distros including andLinux, Ubuntu, Fedora, FreeBSD, archLinux and others
Also, I dont know if you noticed or not, but codelite is currently a one man show, patches are most welcome especially in an areas where I am less familiar (packaging rpm for example), if you will look at SF.net developer count for codelite you will see 5 developer, well, there are actually 4 where I am the only developer while the others are packagers (one for Mac PPC, the other guy is for Fedora and SUSE) I just never released the his binaries, but next release I will release RPMs as well.

To summarize things, I encourage you to help me make codelite a better and more popular by patching its build system and make it more standard - since my resources are very limited

Eran

[rajkrish]

Eran,

Thank you for the feedback. I understand your viewpoints, though I may not agree with all of them.

Anyway, You mentioned the latest being rev1962, but I was not able to find a code drop with that build number last time I checked. I would really appreciate if you could take the trouble and drop me a source tarball for that revision.

I would be doubly thankful to you if you could name it in the traditional *nix way, like "codelite-1.0.1962.tar.gz" (with no other qualifiers like "rev", or "beta" or "src" in between, and it expands to a single top-level directory called "codelite-1.0.1962" containing all the files).

Thanks again, and keep up the good work.
-Rajesh

[eranif]

Anyway, You mentioned the latest being rev1962

This is not so true now, the latest is 2002

I would really appreciate if you could take the trouble and drop me a source tarball for that revision.

You can get the latest tar ball for experiments from here: http://codelite.org/download/codelite-1.0.2002.tar.gz

I will be releasing new build snapshot in a couple of days, revision 2002 is latest stable release, which include many modifications to configure script that
removed all hard coded values from the generated makefile (in fact, it is being used to generate 4 rpms)

Eran