[Gambas-user] Revision: 2514
gambas3 Revision: 2514 does not compile for me , fails at reconf Charlie Remember to add `AC_PROG_LIBTOOL' to `configure.ac'. You should update your `aclocal.m4' by running aclocal. autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal autoreconf: configure.ac: tracing autoreconf: configure.ac: adding subdirectory main to autoreconf autoreconf: Entering directory `main' autoreconf: running: aclocal -I m4 --install configure.ac:7: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:7: the top level configure.ac:7: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:7: the top level autoreconf: configure.ac: not running libtoolize: --install not given autoreconf: running: /usr/bin/autoconf configure.ac:7: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:7: the top level autoreconf: running: /usr/bin/autoheader configure.ac:7: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:7: the top level autoreconf: running: automake --no-force configure.ac:7: warning: LTVERSION_VERSION is m4_require'd but not m4_defun'd m4/libtool.m4:67: LT_INIT is expanded from... configure.ac:7: the top level configure.ac:6: required file `./install-sh' not found configure.ac:6: `automake --add-missing' can install `install-sh' autoreconf: automake failed with exit status: 1 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Revision: 2514
Le jeudi 24 décembre 2009 16:27:14, Charlie Reinl a écrit : gambas3 Revision: 2514 does not compile for me , fails at reconf Charlie I guess it's because the m4/ltversion.m4 is missing There is really a big differences between libtool 1.5.x and 2.x ! Does the file is present ? With libtool 2.x (and install option) ltversion.m4 is automaticaly installed, files config.guess, ltmain.sh, config.sub, install-sh are not needed (i've remove them and it's building fine (they are created during make install). Users (benoit and others) should try to remove them and see if they are correctly created (and it's installing fine) Here it's libtool version 2.2.6b (libtool --version); We can keep compatibility with with 1.5.x libtool, but we will have lot of headache with libtool 2.x, ++ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Revision: 2514
Le jeudi 24 décembre 2009 16:27:14, Charlie Reinl a écrit : gambas3 Revision: 2514 does not compile for me , fails at reconf Charlie I guess it's because the m4/ltversion.m4 is missing There is really a big differences between libtool 1.5.x and 2.x ! Does the file is present ? With libtool 2.x (and install option) ltversion.m4 is automaticaly installed, files config.guess, ltmain.sh, config.sub, install-sh are not needed (i've remove them and it's building fine (they are created during make install). Users (benoit and others) should try to remove them and see if they are correctly created (and it's installing fine) Here it's libtool version 2.2.6b (libtool --version); We can keep compatibility with with 1.5.x libtool, but we will have lot of headache with libtool 2.x, ++ config.guess, ltmain.sh, config.sub and install.sh in source sub-directories are all symbolic links to the one located in the source root directory. I will remove them, and you will tell me what happens! :-) -- Benoît Minisini -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Revision: 2514
Le jeudi 24 décembre 2009 16:27:14, Charlie Reinl a écrit : gambas3 Revision: 2514 does not compile for me , fails at reconf Charlie I guess it's because the m4/ltversion.m4 is missing There is really a big differences between libtool 1.5.x and 2.x ! Does the file is present ? With libtool 2.x (and install option) ltversion.m4 is automaticaly installed, files config.guess, ltmain.sh, config.sub, install-sh are not needed (i've remove them and it's building fine (they are created during make install). Users (benoit and others) should try to remove them and see if they are correctly created (and it's installing fine) Here it's libtool version 2.2.6b (libtool --version); We can keep compatibility with with 1.5.x libtool, but we will have lot of headache with libtool 2.x, ++ config.guess, ltmain.sh, config.sub and install.sh in source sub-directories are all symbolic links to the one located in the source root directory. I will remove them, and you will tell me what happens! :-) I said rubbish. All these files are not versioned at all, so they are always recreated when you do a reconf after a checkout. So I don't see how Gambas could be compilable with both libtool 1.5 and libtool 2.x... -- Benoît Minisini -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Dinamic Libraries unused with ldd
Hello I'm seeing the dynamic libs that depends gbx2 file. For that I use: $ ldd / usr/local/bin/gbx2. The result gives me is: linux-gate.so.1 = (0xb8033000) libm.so.6 = /lib/tls/i686/cmov/libm.so.6 (0xb7ff3000) libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0xb7fef000) libpthread.so.0 = /lib/tls/i686/cmov/libpthread.so.0 (0xb7fd5000) libffi.so.5 = /usr/lib/libffi.so.5 (0xb7fcd000) libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7e6a000) /lib/ld-linux.so.2 (0xb8034000) Now with the -u option, the result is, the result is: /lib/tls/i686/cmov/libm.so.6 /lib/tls/i686/cmov/libdl.so.2 /lib/tls/i686/cmov/libpthread.so.0 The -u option (unused) shows me what dependencies are not being used. Question: Can I ignore these dependencies, since they are not being taken into account? Regards. No. Apparently the -u option is wrong: the mathematical library is used, otherwise how could the Sin() interpreter function work? libdl is used for loading component, and libpthread is needed by some components too, but not by the interpreter directly. Moreover, as the interpreter usually loads components at program startup, you will have to add all the dependencies of these components. Regards, -- Benoît Minisini -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] SHELL not working (GB_DIR)
Doriano Blengino ha scritto: Jesus Guardon ha scritto: Hi again Continuing my testings on GB_DIR, I'm running into a new problem: SHELL command has no effect at all. All sentences using SHELL are not executed. As you can guess, running my project executable the normal way (not using GB_DIR) it is running right. Could this be a bug? SHELL is just an equivalent of EXEC [sh, -c, XXX] where XXX is the string passed to the SHELL command. Not at all. No error message is displayed, simply SHELL command seems to be ignored by the interpreter. As for launch my program I'm using a shell script (you can see it in the previous posts), I'm not able to run gdb against myprogram.gambas, or myprogram (without .sh extension). In a previous mail you wrote: I am calling my executable from a bash script located in /usr/local/bin je...@jesus:~$ cat /usr/local/bin/dfhlog #!/bin/sh export PATH=/opt/dfhlog/gambas2/bin export GB_DIR=/opt/dfhlog/gambas2 exec /opt/dfhlog/dfhlog.gambas (In this case, LD_LIBRARY_PATH is not used, because they already are in my system). Your export PATH command imposes a path which excludes standard unix paths - you will never find system utilities like pidof(1), and neither the shell itself. You should write: export PATH=/opt/dfhlog/gambas2/bin:$PATH to add your personal path the the standard ones. Or, if you are a security paranoid, you could use: export PATH=/opt/dfhlog/gambas2/bin:/usr/bin:/bin This way you don't trust the existing path. This second form excludes /sbin and /usr/sbin; you should add them if you need system administration commands like route, fdisk, reboot, addgroup and many others. Regards, Just after hitting the send button, I realized that this idea is correct only in part. May be it solves, it is a quick try. The right part is that the PATH variable is used by the shell itself, so even if your gambas program finds the shell and asks it to execute something, the shell will fail to do it. Probably this is not considered an error by gambas, so the instruction SHELL pidof xxx fails silently. The ambigous part is in whether gambas uses PATH to search for the shell. If it is so, then your gambas program will not find the shell, and gambas should report this, because an internal instruction of gambas is failing. In this case, however, one can ask himself if makes it sense to use PATH to search for the shell, which traditionally is /bin/sh, and many scripts included system ones address the shell in this way. Assuming that SHELL is a substitute for EXEC [sh, -c, ], and that EXEC searches executables in PATH, this would explain all. Perhaps would be better to bind SHELL to EXEC [/bin/sh, -c, ...]. I am not sure if, natively, exec() searches executables in PATH. May be that there is the system call exec() which does one thing, and the C library wrapped exec() which does differently. In any case, if it is so, this would explain my sensation that SHELLs in gambas are slow. In my system (a normal Debian), the PATH variable looks like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 . Every time a gambas program invokes a SHELL, the system searches sh in 4 directories, and then sh searches for the executable in 4 directories again; the first four directories could be skipped. Regards, That's exactly the point: I send sh to the system, asking him to search it inside the PATH, by using the execvp() glibc function. I don't remember why I decided to do that. Maybe it is not useful, maybe I can use directly /bin/sh, and let the user use the EXEC instruction if he needs something else? -- Benoît Minisini -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Revision: 2514
Le jeudi 24 décembre 2009 17:33:56, Benoît Minisini a écrit : Le jeudi 24 décembre 2009 16:27:14, Charlie Reinl a écrit : gambas3 Revision: 2514 does not compile for me , fails at reconf Charlie I guess it's because the m4/ltversion.m4 is missing There is really a big differences between libtool 1.5.x and 2.x ! Does the file is present ? With libtool 2.x (and install option) ltversion.m4 is automaticaly installed, files config.guess, ltmain.sh, config.sub, install-sh are not needed (i've remove them and it's building fine (they are created during make install). Users (benoit and others) should try to remove them and see if they are correctly created (and it's installing fine) Here it's libtool version 2.2.6b (libtool --version); We can keep compatibility with with 1.5.x libtool, but we will have lot of headache with libtool 2.x, ++ config.guess, ltmain.sh, config.sub and install.sh in source sub-directories are all symbolic links to the one located in the source root directory. I will remove them, and you will tell me what happens! :-) I said rubbish. All these files are not versioned at all, so they are always recreated when you do a reconf after a checkout. So I don't see how Gambas could be compilable with both libtool 1.5 and libtool 2.x... And they are in the repository see: http://gambas.svn.sourceforge.net/viewvc/gambas/gambas/trunk/gb.opengl/ So they can be removed -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] SHELL not working (GB_DIR)
Benoît Minisini ha scritto: Doriano Blengino ha scritto: Jesus Guardon ha scritto: SHELL is just an equivalent of EXEC [sh, -c, XXX] where XXX is the string passed to the SHELL command. je...@jesus:~$ cat /usr/local/bin/dfhlog #!/bin/sh export PATH=/opt/dfhlog/gambas2/bin export GB_DIR=/opt/dfhlog/gambas2 exec /opt/dfhlog/dfhlog.gambas Your export PATH command imposes a path which excludes standard unix paths - you will never find system utilities like pidof(1), and neither the shell itself. You should write: export PATH=/opt/dfhlog/gambas2/bin:$PATH The right part is that the PATH variable is used by the shell itself, so even if your gambas program finds the shell and asks it to execute something, the shell will fail to do it. Probably this is not considered an error by gambas, so the instruction SHELL pidof xxx fails silently. The ambigous part is in whether gambas uses PATH to search for the shell. If it is so, then your gambas program will not find the shell, and gambas should report this, because an internal instruction of gambas is failing. In this case, however, one can ask himself if makes it sense to use PATH to search for the shell, which traditionally is /bin/sh, and many scripts included system ones address the shell in this way. Assuming that SHELL is a substitute for EXEC [sh, -c, ], and that EXEC searches executables in PATH, this would explain all. Perhaps would be better to bind SHELL to EXEC [/bin/sh, -c, ...]. I am not sure if, natively, exec() searches executables in PATH. May be that there is the system call exec() which does one thing, and the C library wrapped exec() which does differently. In any case, if it is so, this would explain my sensation that SHELLs in gambas are slow. In my system (a normal Debian), the PATH variable looks like /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 . Every time a gambas program invokes a SHELL, the system searches sh in 4 directories, and then sh searches for the executable in 4 directories again; the first four directories could be skipped. Regards, That's exactly the point: I send sh to the system, asking him to search it inside the PATH, by using the execvp() glibc function. I don't remember why I decided to do that. Maybe it is not useful, maybe I can use directly /bin/sh, and let the user use the EXEC instruction if he needs something else? I think there are a few pros in using /bin/sh directly, and perhaps a single con. The pros are: slightly faster; more traditional in the sense that SHELL should invoke the normal system shell (/bin/sh) and not an arbitrary shell due to a mangled PATH; in a case like this one by Jesus, where we find a little error in setting PATH, the SHELL statement would work anyway. The single con, perhaps, is that in a non standard system, with strange PATH set up, the SHELL could fail. But this could be overcome by using EXEC instead of SHELL: a user special enough to use a special setup, can well use EXEC instead of SHELL. Perhaps a little search in some sources analogue in concept to gambas (python, awk...) could be explanatory; I would propend for /bin/sh. Regards and happy Christmas, -- Doriano Blengino Listen twice before you speak. This is why we have two ears, but only one mouth. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Dinamic Libraries unused with ldd
Ok Benoit, Thank you very much. -Mensaje original- De: Benoît Minisini gam...@users.sourceforge.net Reply-to: mailing list for gambas users gambas-user@lists.sourceforge.net Para: mailing list for gambas users gambas-user@lists.sourceforge.net Asunto: Re: [Gambas-user] Dinamic Libraries unused with ldd Fecha: Thu, 24 Dec 2009 17:36:07 +0100 Hello I'm seeing the dynamic libs that depends gbx2 file. For that I use: $ ldd / usr/local/bin/gbx2. The result gives me is: linux-gate.so.1 = (0xb8033000) libm.so.6 = /lib/tls/i686/cmov/libm.so.6 (0xb7ff3000) libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0xb7fef000) libpthread.so.0 = /lib/tls/i686/cmov/libpthread.so.0 (0xb7fd5000) libffi.so.5 = /usr/lib/libffi.so.5 (0xb7fcd000) libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7e6a000) /lib/ld-linux.so.2 (0xb8034000) Now with the -u option, the result is, the result is: /lib/tls/i686/cmov/libm.so.6 /lib/tls/i686/cmov/libdl.so.2 /lib/tls/i686/cmov/libpthread.so.0 The -u option (unused) shows me what dependencies are not being used. Question: Can I ignore these dependencies, since they are not being taken into account? Regards. No. Apparently the -u option is wrong: the mathematical library is used, otherwise how could the Sin() interpreter function work? libdl is used for loading component, and libpthread is needed by some components too, but not by the interpreter directly. Moreover, as the interpreter usually loads components at program startup, you will have to add all the dependencies of these components. Regards, -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] Shell sudo
sudo allows you to pass a password to the shell with -S The following should do it. sudo -S apt-get install PACKAGENAME EOF PASSWORD EOF Regards Les Hardy M. Cs. wrote: I'd like to make my app able to download and install packages via apt-get (or any other command-line package manager). How can I do that? I know it will need the user's password but how can I pass the command? The simple SHELL sudo apt-get install ... won't do the thing! Thanks! -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
