Hi Friedrich, On 24 Jun 2013, at 11:50, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

I have had this connection via ODBC running on Linux before. So I guess you are right with some libraries, but they seem not to be related to libpam.

Have you tried using ldd to find dependencies (libs used by the vm or its plugins) ? For example, root@stfx:~# ldd pharo-vm/pharo linux-gate.so.1 => (0xb7709000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb76be000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb76b9000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb769d000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74ea000) /lib/ld-linux.so.2 (0xb770a000) root@stfx:~# ldd pharo-vm/lib*.so pharo-vm/libB3DAcceleratorPlugin.so: linux-gate.so.1 => (0xb77d1000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7606000) /lib/ld-linux.so.2 (0xb77d2000) pharo-vm/libFT2Plugin.so: linux-gate.so.1 => (0xb7748000) libfreetype.so.6 => /usr/lib/i386-linux-gnu/libfreetype.so.6 (0xb769d000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74ea000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb74d0000) /lib/ld-linux.so.2 (0xb7749000) pharo-vm/libInternetConfigPlugin.so: linux-gate.so.1 => (0xb76ec000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb752d000) /lib/ld-linux.so.2 (0xb76ed000) pharo-vm/libSqueakFFIPrims.so: linux-gate.so.1 => (0xb7763000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75a0000) /lib/ld-linux.so.2 (0xb7764000) pharo-vm/libSqueakSSL.so: linux-gate.so.1 => (0xb7761000) libssl.so.0.9.8 => /lib/i386-linux-gnu/libssl.so.0.9.8 (0xb7705000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7552000) libcrypto.so.0.9.8 => /lib/i386-linux-gnu/libcrypto.so.0.9.8 (0xb73d8000) /lib/ld-linux.so.2 (0xb7762000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb73d3000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb73ba000) BTW, this is on a 32 bit machine. HTH, Sven PS: I think I remember you from my Common Lisp days, right ? In that case, welcome to Pharo ! -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

On 24 Jun 2013, at 15:50, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

Sven Van Caekenberghe <sven@stfx.eu> writes:

...

Hi Friedrich,

On 24 Jun 2013, at 11:50, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

...

I have had this connection via ODBC running on Linux before. So I guess you are right with some libraries, but they seem not to be related to libpam.

Have you tried using ldd to find dependencies (libs used by the vm or its plugins) ? Thanks for taking the time. I got the following output: libB3DAcceleratorPlugin.so: linux-gate.so.1 (0xf778f000) libc.so.6 => /lib32/libc.so.6 (0xf75a3000) /lib/ld-linux.so.2 (0xf7790000) libFT2Plugin.so: linux-gate.so.1 (0xf772f000) libfreetype.so.6 => /usr/lib32/libfreetype.so.6 (0xf7683000) libc.so.6 => /lib32/libc.so.6 (0xf74d3000) libz.so.1 => /usr/lib32/libz.so.1 (0xf74bb000) /lib/ld-linux.so.2 (0xf7730000) libInternetConfigPlugin.so: linux-gate.so.1 (0xf776d000) libc.so.6 => /lib32/libc.so.6 (0xf758d000) /lib/ld-linux.so.2 (0xf776e000) libodbccr.so: statically linked libodbccr.so.1: statically linked libodbcinst.so: statically linked libodbcinst.so.1: statically linked libodbc.so: statically linked libodbc.so.1: statically linked libSqueakFFIPrims.so: linux-gate.so.1 (0xf76ee000) libc.so.6 => /lib32/libc.so.6 (0xf750a000) /lib/ld-linux.so.2 (0xf76ef000) libSqueakSSL.so: linux-gate.so.1 (0xf7717000) libssl.so.0.9.8 => /usr/lib32/i686/cmov/libssl.so.0.9.8 (0xf769b000) libc.so.6 => /lib32/libc.so.6 (0xf74eb000) libcrypto.so.0.9.8 => /usr/lib32/i686/cmov/libcrypto.so.0.9.8 (0xf7393000) libdl.so.2 => /lib32/libdl.so.2 (0xf738e000) libz.so.1 => /usr/lib32/libz.so.1 (0xf7376000) /lib/ld-linux.so.2 (0xf7718000) pharo: linux-gate.so.1 (0xf7726000) libm.so.6 => /lib32/libm.so.6 (0xf76b7000) libdl.so.2 => /lib32/libdl.so.2 (0xf76b2000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7697000) libc.so.6 => /lib32/libc.so.6 (0xf74e7000) /lib/ld-linux.so.2 (0xf7727000) vm-display-null: linux-gate.so.1 (0xf7724000) libm.so.6 => /lib32/libm.so.6 (0xf76b1000) libdl.so.2 => /lib32/libdl.so.2 (0xf76ac000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7691000) libc.so.6 => /lib32/libc.so.6 (0xf74e1000) /lib/ld-linux.so.2 (0xf7725000) vm-display-X11: linux-gate.so.1 (0xf776d000) libm.so.6 => /lib32/libm.so.6 (0xf76e5000) libdl.so.2 => /lib32/libdl.so.2 (0xf76e0000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf76c5000) libSM.so.6 => /usr/lib32/libSM.so.6 (0xf76bd000) libICE.so.6 => /usr/lib32/libICE.so.6 (0xf76a6000) libGL.so.1 => /usr/lib32/libGL.so.1 (0xf7641000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7523000) libnsl.so.1 => /lib32/libnsl.so.1 (0xf750a000) libc.so.6 => /lib32/libc.so.6 (0xf735a000) /lib/ld-linux.so.2 (0xf776e000) libuuid.so.1 => /lib32/libuuid.so.1 (0xf7356000) libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7347000) libXxf86vm.so.1 => /usr/lib32/libXxf86vm.so.1 (0xf7341000) libXdamage.so.1 => /usr/lib32/libXdamage.so.1 (0xf733e000) libXfixes.so.3 => /usr/lib32/libXfixes.so.3 (0xf7339000) libdrm.so.2 => /usr/lib32/libdrm.so.2 (0xf732f000) libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7316000) librt.so.1 => /lib32/librt.so.1 (0xf730c000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7309000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7304000) vm-sound-ALSA: linux-gate.so.1 (0xf77b4000) libm.so.6 => /lib32/libm.so.6 (0xf773f000) libdl.so.2 => /lib32/libdl.so.2 (0xf773a000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf771f000) libc.so.6 => /lib32/libc.so.6 (0xf756f000) /lib/ld-linux.so.2 (0xf77b5000) vm-sound-null: linux-gate.so.1 (0xf76f0000) libm.so.6 => /lib32/libm.so.6 (0xf767e000) libdl.so.2 => /lib32/libdl.so.2 (0xf7679000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf765e000) libc.so.6 => /lib32/libc.so.6 (0xf74ae000) /lib/ld-linux.so.2 (0xf76f1000)

I can not see any ling in it which seems to indicate a problem.

It look OK to me as well, although not much can be said about the statically linked .so files, which are of course the ODBC ones. I am afraid that I can't help much further, this is too low level and OS specific for me and I never used ODBC myself. I would hope that the DBX people know more… It is of course very annoying if you need the connectivity and even more so if it worked before.

...

HTH,

Sven

PS: I think I remember you from my Common Lisp days, right ? In that case, welcome to Pharo ! I know who you are also, but I'm in Smalltalk for quite some time now ;-), anyway thanks for the welcome :)

Even better.

Regards Friedrich

On 24 June 2013 12:21, jtuchel@objektfabrik.de <jtuchel@objektfabrik.de>wrote:

false ifTrue: [ self sqlSetEnvAttr: 200 value: 2 "SQL_ATTR_ODBC_VERSION" ].

what does this false ifTrue: thing mean here?

That's how you comment code in Smalltalk - becuase it doesn't support nested comments. -- Milan Mimica http://sparklet.sf.net

I was stunned and curious.  There's plenty of "false ifTrue:" code in Squeak 4.2...  Did I miss something too ???  :)   ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blogue: endormitoire.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: "jtuchel@objektfabrik.de" <jtuchel@objektfabrik.de> To: pharo-users@lists.pharo.org Sent: Monday, June 24, 2013 4:28:50 PM Subject: Re: [Pharo-users] Pharo 2.0 and ODBC You're joking, right? I mean, if this is a way of helping me understand code by "commenting it", I'd simply say Thanks, but no thanks! If that's the way it's done in Smalltalk, I wonder where I have been the last 17 years. I haven't done this and I can't remember seeing this. And I've read and fixed quite some code in that time. This is probably done in a Smalltalk environment that has no decent version control system, just to avoid losing code you could probably need again. But I doubt anybody using Monticello or more advanced Smalltalk versioning solutions really needs such a dirty workaround. But I cannot prove you wrong. At least that piece of code is functionally equivalent to a comment ;-) So what you're saying is that I shouldn't worry about it. Okay, will do ;-))) Joachim Am 24.06.13 22:13, schrieb Milan Mimica:

On 24 June 2013 12:21, jtuchel <mailto:jtuchel@objektfabrik.de>wrote:

    false ifTrue:             [ self                 sqlSetEnvAttr: 200                 value: 2    "SQL_ATTR_ODBC_VERSION" ].

    what does this false ifTrue: thing mean here?

That's how you comment code in Smalltalk - becuase it doesn't support nested comments.

-- Milan Mimica http://sparklet.sf.net

Hi Friedrich, I guess what could help people understand more about what the actual differences might be is if you can exactly say under which Pharo version and on which VM your ODBC connection had been working before. Was it also on a 64 bit lInux? Even the same installation or some other 64 bit machine (I know from hard and painful experience that two Linux boxes can look very similar but still be completely different, just because a single link is missing)? So I am afraid you've now entered a stage in which you need to gradually change things (and keep track of them) and try different VMs, Images and libraries up until you find a combination that works. Or some bright soul who knows it all ;-) Joachim Am 24.06.13 11:50, schrieb Friedrich Dominicus:

"jtuchel@objektfabrik.de" <jtuchel@objektfabrik.de> writes:

...

Hi Friedrich,

I am not sure if this is relevant for your case, but I had a very similar problem with VAST and DB2 on Linux 64 bits. The funny thing is that I also hat problems with the very same call and on digging deeper found out the problem is a missing Ubuntu package. AFAIK, Pharo is also 32 bits, right? (otherwise your call wouldn't come through libdl.so.2 in /lib32/)

If so, see if you have libpam-modules:i386 installed on your box. In my case, this solved my problem.

You can find a few more details about my case here: https://groups.google.com/d/msg/va-smalltalk/tYTXU5ZqQAo/RVr5cHRiRKUJ Be sure to read the whole thread to understand why I think your problem is related.

And please let me/us know if your problem can be solved the same way. I tried it with the libpam-modules installation. I modified the LD_LIBRARY_PATH to contain the path to the libpam libraries also.

I restarted Pharo and tried to connect result: pharo VM version: 3.9-7 #1 Wed Mar 13 18:22:44 CET 2013 gcc 4.4.3 Built from: NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 With: NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Mar 13 2013 Revision: git://gitorious.org/cogvm/blessed.git Commit: 412abef33cbed05cf1d75329e451d71c0c6aa5a7 Date: 2013-03-13 17:48:50 +0100 By: Esteban Lorenzano <estebanlm@gmail.com> Jenkins build #14535 Build host: Linux linux-ubuntu-10 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux plugin path: /home/frido/Smalltalks/default/bin [default: /home/frido/Smalltalks/default/bin/]

C stack backtrace: /home/frido/Smalltalks/default/bin/pharo[0x80a0c0c] /home/frido/Smalltalks/default/bin/pharo[0x80a0f28] linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xf77d7410] /lib/ld-linux.so.2(+0x13697)[0xf77eb697] /lib/ld-linux.so.2(+0xf3de)/lib32/libdl.so.2(+0xcce)[0xf7763cce]

Smalltalk stack dump: 0xff958a10 I ODBCConnection>sqlAllocEnv 0xbb60d2dc: a(n) ODBCConnection 0xff958a30 I ODBCConnection>connect 0xbb60d2dc: a(n) ODBCConnection 0xff958a50 I ODBCConnection>open 0xbb60d2dc: a(n) ODBCConnection 0xff958a74 I [] in ODBCConnection class>dsn:user:password: 0xba3bea7c: a(n) ODBCConnection class 0xff958a90 M BlockClosure>on:do: 0xbb60d3d8: a(n) BlockClosure 0xff958abc I ODBCConnection class>dsn:user:password: 0xba3bea7c: a(n) ODBCConnection class 0xff958ae0 M UndefinedObject>? 0xb7428004: a(n) UndefinedObject 0xff958b18 I Compiler>evaluate:in:to:notifying:ifFail:logged: 0xbb589684: a(n) Compiler

Then I tried the same code on/in Windows and there the connection works. I have had this connection via ODBC running on Linux before. So I guess you are right with some libraries, but they seem not to be related to libpam.

Regards Friedrich

Am 25.06.13 07:10, schrieb Friedrich Dominicus:

"jtuchel@objektfabrik.de" <jtuchel@objektfabrik.de> writes:

...

Hi Friedrich,

I guess what could help people understand more about what the actual differences might be is if you can exactly say under which Pharo version and on which VM your ODBC connection had been working before. Was it also on a 64 bit lInux? Even the same installation or some other 64 bit machine (I know from hard and painful experience that two Linux boxes can look very similar but still be completely different, just because a single link is missing)? No it was exactly this machine. But I updated Pharo to 2.0 and it may be that I updated some libraries on this Box also. But sorry, I can not tell really. I guess nobody really keeps track on the working machine on what you install when. You need it and then you fetch it.

That's the way we all do it, right? So are you saying ODBC in Pharo 1.x still works on that very same machine? Does ldd for the old VM yield the same kind of output? If so, it should be possible to limit the search to the 2.0 VM and Image and ignore the surroundings. That would sure be of great help.

...

So I am afraid you've now entered a stage in which you need to gradually change things (and keep track of them) and try different VMs, Images and libraries up until you find a combination that works. Or some bright soul who knows it all ;-) Well yes that might be necessary. Unfortunatly I know the same code runs fine on Windows and so it probabl has to do with the used/provided odbc libraries. I was just wondering if anyone else uses this combination. But AFAIKT it seems ODBC is not "really" used with Pharo. Hmm, I have no idea to be honest. I am not even using Pharo much. I somehow mistrust ODBC on Linux per se, but that is based on experiences from around 2005, so a very uninformed opinion rather than based on (current) facts.

Joachim

Actually, I don't know how is the maintainer of ODBC. Now sure if there is one. As a comment, notice that OpenDBXDriver can also talk to ODBC backend. The thing here is that instead of doing: Pharo -> ODBC you are doing: Pharo -> openDBX -> ODBC OpenDBX author recommends to use ODBC directly or any of the other drivers when connecting when to a particular DB. But anyway, you could use OpenDBX with ODBC if you want. I didn't try myself so I cannot tell much. I know some people did it, but I think it was on Windows. Cheers, On Wed, Jun 26, 2013 at 4:06 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

On 26 Jun 2013, at 08:59, Friedrich Dominicus < frido@q-software-solutions.de> wrote:

...

Can anyone point me to the current ODBC maintainers?

I would start searching here: http://dbxtalk.smallworks.com.ar

...

Regards Friedrich -- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus

-- Mariano http://marianopeck.wordpress.com

Sven Van Caekenberghe <sven@stfx.eu> writes:

On 26 Jun 2013, at 08:59, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

...

Can anyone point me to the current ODBC maintainers?

I would start searching here: http://dbxtalk.smallworks.com.ar Sorry it seems there is some way using it. I will give it a shot

Regards

Thanks for your feedback. We would love to provide a better infrastructure. It just takes time. Stef On Jul 4, 2013, at 12:02 PM, Friedrich Dominicus <frido@q-software-solutions.de> wrote:

To everyone intersted/involved. I downloaded a new virtual machine today and the same code which has crashed the virtual machine, simply works on the new Virtual machine. The machine I'm using is: 'NBCoInterpreter NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 31 2013 NBCogit NativeBoost-CogPlugin-GuillermoPolito.19 uuid: acc98e51-2fba-4841-a965-2975997bba66 May 31 2013 git://gitorious.org/cogvm/blessed.git Commit: 0f562e0afe14e533470278943b5d65d42ea133c2 Date: 2013-05-30 16:38:08 +0200 By: Igor Stasenko <siguctua@gmail.com> Jenkins build #14595 '

So well it seems it was not my 32-bit libraries but something broken withing Pharo and/or the FFI area. I'm sorry, but I do not know the changes applied to my last used VirtualMachine

Anyway i can use the ODBC stuff from withing Pharo on my Linux box now to access an .mdb file

Regards Friedrich

-- Q-Software Solutions GmbH; Sitz: Bruchsal; Registergericht: Mannheim Registriernummer: HRB232138; Geschaeftsfuehrer: Friedrich Dominicus