#873 Bundled libs

None
closed-wont-fix
None
5
2016-07-24
2013-09-15
Hubbitus
No

Hello.

As I mentioned before I try package Tora for Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=979166).

Now I found you bundle several libs in extlibs directory of sources. It is strongly prohibited by our guidelines - https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

Could you please help me use system libraries instead?

Discussion

1 2 > >> (Page 1 of 2)
  • Ivan Brezina

    Ivan Brezina - 2013-10-21

    Which ones are bothering you?

    • libantlr3c - it does not make sense to use system provided library. ANTLR versions are not backward not forward compatible. We must use EXACTLY the same version as our parser files. This library is not mandatory and will be deleted soon.
    • libantlr3cpp - this is header only library. So far it was not packaged. Also contains some fixes not yet pulled into trunk.
    • liberrmodel - this library was not packaged yet by anybody. It's planar graph drawing library made as an extract from kgraphviewer. Tora specific library not used by any other project.
    • Loki - Header only library. Theoretically we could use distribution one (with one exception)
    • qscintilla2 - used mostly for Windows builds - not recommended to use on Linux.
    • stack - Tora specific library not used by any other project
    • trotl - Tora specific library not used by any other project.
     
  • Hubbitus

    Hubbitus - 2013-10-22

    Hello Ivan.
    Thanks to the answer.
    For the libraries which is part of tora project we can leave its here. If such may be not used please say switch, option how to archive that - I'll then just remove it before build. All other must be unbundled as condition to hit Fedora. If you are interesting and ready start that work on tora side I could package required libraries also.

     
  • Ivan Brezina

    Ivan Brezina - 2013-10-22

    I think you first should check this thread:
    https://sourceforge.net/p/tora/mailman/message/31549255/

    Petr is working on SUSE packages.

    Now about the libraries in extlibs forlder

    • libantlr3c-3.3 - ANTLR C runtime libs. Are not needed at this moment as we are going to use C++ runtime libs. Feel free to delete it

    • libantlr3cpp-3.5.1 - ANTLR C++ runtime libs. Not packaged yet and library API is still under development.
      ANTLR is good candidate for an exception. ANTLR versions are not backward nor forward compatible and rest of our parser generated sources (src/parsing/)
      depend on EXACT ANRLR version. There is no other way of doing that. It does not make any sense to package this anyway.
      Or you would have to do it like libpng does. You would end up with several packages named libantlr32 libantlr33 libantlr34 libantlr35 libantlr351 libantlr352.

    • libermodel - Tora specific library. Not used by any other project

    • loki - the most problematic one. There are several forks of this library and I do not know which one to choose and I do not want waste my time searching for the right one.
      We use only very limited subset of library features, but anyway I had to add few patches in it. I'm trying to build Tora on Ubuntu with distrib. version and it does not work.
      This thinks that long long int is not a numerical datatype. I'm afraid I would have to push my fixes into all the distributions. It does not seem to be realistic.
      Just try to compare the contents of extlibs/loki/include with the package(s) provided by Fedora.

    • loki-extra - One header only - not a library. Alternative Factory implementation.

    • parsing

    • parsing.cpp
      These are not libraries but sandboxes for various tests. These are excluded from the build anyway

    • qscintilla2
      Excluded from default build. Attached mostly for Windows builds. But on the other hand I must say that this contemporary version has many handy fixes.

    • stack - Tora specific library. Used only for debug builds.

    • trotl - Tora specific library. C++ OCI wrapper. This one must stay.

    Just try to delete libraries you do not like and remove reference in extlibs/CMakeLists.txt

    At this moment the default build does not use:
    - loki (it tries to use distrib one but it does not work)
    - qscintilla2 (also not included in default build)
    - stack - is excluded if you use -DCMAKE_BUILD_TYPE=Release

    Ivan

     
    • Hubbitus

      Hubbitus - 2013-10-23

      loki - the most problematic one. There are several forks of this library and I do not know which one to choose and I do not want waste my time searching for the right one.

      I'm afraid I would have to push my fixes into all the distributions. It does not seem to be realistic.

      Did you tried push your patches to upstream loki authors?

       
      • Ivan Brezina

        Ivan Brezina - 2013-10-23

        No. finally I have found a workaround(or proper solution). Now it can be compiled with distribution provided header.

         
    • Hubbitus

      Hubbitus - 2013-10-26

      libantlr3cpp-3.5.1 - ANTLR C++ runtime libs. Not packaged yet and library API is still under development.
      ANTLR is good candidate for an exception. ANTLR versions are not backward nor forward compatible and rest of our parser generated sources (src/parsing/)
      depend on EXACT ANRLR version. There is no other way of doing that. It does not make any sense to package this anyway.
      Or you would have to do it like libpng does. You would end up with several packages named libantlr32 libantlr33 libantlr34 libantlr35 libantlr351 libantlr352.

      If i understand correctly it is just C++ wrapper under antlr3 library? Last already packaged:
      ant-antlr3.noarch : Antlr3 task for Ant
      ant-antlr3-javadoc.noarch : Javadoc for ant-antlr3
      antlr3-debuginfo.x86_64 : Debug information for package antlr3
      antlr3-C.x86_64 : C run-time support for ANTLR-generated parsers
      antlr3-C-devel.i686 : Header files for the C bindings for ANTLR-generated parsers
      antlr3-C-devel.x86_64 : Header files for the C bindings for ANTLR-generated parsers
      antlr3-C-docs.noarch : API documentation for the C run-time support for ANTLR-generated parsers
      antlr3-java.noarch : Java run-time support for ANTLR-generated parsers
      antlr3-javascript.noarch : Javascript run-time support for ANTLR-generated parsers
      antlr3-tool.noarch : ANother Tool for Language Recognition

      Could you please point me on its site?

       
      • Ivan Brezina

        Ivan Brezina - 2013-10-26

        No it is not a wrapper. It is alternative C++ implementation. And is it compatible with the ANTLR tool ver. 3.5.1. While Fedora has packaged ver 3.4 of C runtime.
        As I stated several times before. ANTLR versions are not backward nor forward compatible. The code generated with version 3.4 will not work with runtimme ver. 3.5 and vice versa. Moreover the version shipped with Fedora is buggy as hell. Also it does not make any sense to name the package antlr3 - behavirour of such a package is unpredicable.

         
        • Hubbitus

          Hubbitus - 2013-10-28

          Could you please point me on project site?

           
          • Ivan Brezina

            Ivan Brezina - 2013-10-28
             
            • Hubbitus

              Hubbitus - 2013-11-03

              Is last 4.1 version satisfy Tora needs?

               
              • Ivan Brezina

                Ivan Brezina - 2013-11-03

                Version 4,x supports Java na C# only. So far nobody started working on C/C++ support.

                 
                • Hubbitus

                  Hubbitus - 2013-11-03

                  What last version is support C++? Does it satisfy tora needs? I then just may (try) ask maintainer update it Fedora.

                   
                  • Ivan Brezina

                    Ivan Brezina - 2013-11-04

                    I'm afraid this discussion leads to nowhere. Tora works with the latest trunk (plus needs several patches on top of it). The C++ runtime port was not packaged yet and most likely it's API will change before it gets packaged.

                     
                    • Hubbitus

                      Hubbitus - 2013-11-04

                      Sorry for I insist. But with you help I be able remove all external libraries except that. So far thank you very much. So, I search possibility do it with it also. If it absolutely not possible I'll try fill request to exception ( https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions ), but for it I also should have awesome arguments. Did you tried push tora patches against antlr3 to upstream?

                       
                      • Ivan Brezina

                        Ivan Brezina - 2013-11-04
                        * Yes - see https://github.com/antlr/antlr3/pulls - pull request 129
                        * Fedora/RHEL use package 3.4
                        * ver 3.4 is not 100% compatible with current version 3.5.1
                        * ver 3.5.1 is not 100% compatible with version 3.4
                        * ver 3.4 (C runtime)included in RHEL segfaults. See this bug: https://bugzilla.redhat.com/show_bug.cgi?id=966973. The pull request 43 was created by MySQLWorkbech authors. So far not aplied into upstream nor included in RHEL package.
                        * neither of RHEL/Fedora packages include C++ runtime
                        * I expect that the C++ runtime API will slightly change in the future
                        * ANTLR C++ runtime is quite new and only few projects use it
                        * ANTLR C++ runtime is not a library at all. It is set of 45 headers. It does have any binaries
                        
                         
                        • Hubbitus

                          Hubbitus - 2013-11-07

                          Thank you very much for help.
                          I'he fill update request - https://bugzilla.redhat.com/show_bug.cgi?id=1026440
                          Waiting answer. Then will deal dependant on solution (have dep, or try request exception).

                           
                          • Ivan Brezina

                            Ivan Brezina - 2013-11-07

                            Good to hear. It started moving - somehow: see: https://github.com/antlr/antlr3/pull/43. But anyway I still think the "only" solution for Fedora would be to have two packages named: antlr34, antlr35. It is not soo easy to switch from one version onto another one. Can you tell how many projects in Fedora do depend on antlr?

                             
                            Last edit: Ivan Brezina 2013-11-07
                            • Hubbitus

                              Hubbitus - 2013-11-07

                              Glad to heard also, thanks.

                              repoquery --whatrequire 'antlr*'

                              OmegaT-0:2.6.1-0.9.Beta.fc19.x86_64
                              ant-antlr-0:1.8.4-6.fc19.noarch
                              antlr-maven-plugin-0:2.2-9.fc19.noarch
                              antlr3-C-devel-0:3.4-14.fc19.i686
                              antlr3-C-devel-0:3.4-14.fc19.x86_64
                              antlr3-C-docs-0:3.4-14.fc19.noarch
                              antlr3-tool-0:3.4-14.fc19.noarch
                              antlrworks-0:1.4.3-8.fc19.noarch
                              apacheds-shared-0:0.9.19-3.fc19.noarch
                              checkstyle-0:5.6-5.fc19.noarch
                              eclipse-checkstyle-0:5.1.0-8.fc19.noarch
                              eclipse-epic-0:0.6.44-3.fc19.noarch
                              eclipselink-0:2.3.2-2.fc19.noarch
                              eucalyptus-common-java-0:3.2.1-3.fc19.x86_64
                              glassfish-toplink-essentials-0:2.0.46-5.fc19.noarch
                              gluegen-0:1-0.20102506svn15.fc19.x86_64
                              gmaven-0:1.4-4.fc19.noarch
                              gradle-0:1.0-13.fc19.noarch
                              groovy-0:1.8.8-4.fc19.noarch
                              groovy-0:1.8.9-4.fc19.noarch
                              groovy18-0:1.8.9-3.fc19.noarch
                              hibernate-0:4.1.7-6.fc19.noarch
                              jabref-0:2.9.2-1.fc19.noarch
                              jacorb-0:2.3.1-5.fc19.noarch
                              jacorb-0:2.3.1-8.fc19.noarch
                              jboss-as-0:7.1.1-19.fc19.noarch
                              jboss-as-0:7.1.1-21.fc19.noarch
                              jboss-jts-0:4.16.2-11.fc19.noarch
                              jgettext-0:0.13-2.fc19.noarch
                              mysql-workbench-0:5.2.47-2.fc19.x86_64
                              ovirt-engine-backend-0:3.1.0-1.fc19.noarch
                              python-xlwt-0:0.7.4-3.fc19.noarch
                              sqljet-0:1.1.4-4.fc19.noarch
                              stringtemplate-0:3.2.1-5.fc19.noarch
                              struts-0:1.3.10-7.fc19.noarch
                              ws-jaxme-0:0.5.2-8.fc19.noarch

                               
                              • Ivan Brezina

                                Ivan Brezina - 2013-11-08

                                That's bad. I do not believe, that all these projects can be modified to use newest ANTLR version. EclipseLink and Jboss? No way.

                                 
                                • Hubbitus

                                  Hubbitus - 2013-11-09

                                  May be with java backward compatibility there better situation? Anyway my request assigned and I think we should await few days answer from maintainer.

                                   
    • Hubbitus

      Hubbitus - 2013-10-26

      Unfortunately trotl unconditionally search Oracle libraries even besides -DENABLE_ORACLE:BOOLEAN=false and then fail:

      • /usr/bin/cmake -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 -DBUILD_SHARED_LIBS:BOOL=ON -DCMAKE_INSTALL_PREFIX:PATH=/usr -DPOSTGRESQL_PATH_INCLUDES=/usr/include -DENABLE_ORACLE:BOOLEAN=false
        Qt4 Found OK
        QScintilla2 Found OK

      CMake Error at extlibs/trotl/CMakeLists.txt:76 (MESSAGE):
      No Oracle client found

       
      • Ivan Brezina

        Ivan Brezina - 2013-10-26

        Ok fixed in trunk, although it does not make to much sense. (To build "Tool for Oracle" without Oracle support). Support for MySQL and PostgreSQL is still heavily experimental. So far we do not have any maintainer for these.

         
        • Hubbitus

          Hubbitus - 2013-10-28

          Thank you.
          Unfortunately Oracle is not free software. So in Fedora we can ship only Postgres and MySQL support only. But in spec leaved two strings to just uncomment end recompile src.rpm for whom need it. I hope.
          Personally I've used it for Postgresql.

           
          • Ivan Brezina

            Ivan Brezina - 2013-10-28

            You do not have to ship Oracle libs. Just compile Tora with Oracle connector plugin. So far we do not have any maintainer for MySQL nor PostgeSQL port. It's still experimental and a lot for work have to be done.

             
        • Hubbitus

          Hubbitus - 2013-10-28

          Additionally trunc revision 4913 failed with:

          CMake Error at src/CMakeLists.txt:1060 (ADD_EXECUTABLE):
            Cannot find source file:
          
              connection/moc_tooraclesetting.cxx
          
            Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
            .hxx .in .txx
          
           
1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks