date:20010425

AIX shared libraries in MLB and 1.4

2001-04-25 Thread libtool


I'm looking over the differences in how shared libraries are built
between MLB and 1.4. Some questions:
  1. Any reason for version_type=linux in 1.4 and not MLB?
  2. Should we sync up shared library names between 1.4 and MLB
 (cf soname_spec below). Shared library names in MLB are
 libfoo.so.o while in 1.4 its libfoo.so.$major.

-- 
albert chin ([EMAIL PROTECTED])

-- snip snip
Index: libtool.m4
===
RCS file: /home/cvs/libtool/libtool.m4,v
retrieving revision 1.166
diff -u -3 -p -r1.166 libtool.m4
--- libtool.m4  2001/04/24 23:40:42 1.166
+++ libtool.m4  2001/04/25 12:51:50
@@ -1832,7 +1832,6 @@ aix3*)
   ;;
 
 aix4* | aix5*)
-  version_type=linux
   if test $host_cpu = ia64; then
 # AIX 5 supports IA64
 library_names_spec='${libname}${release}.so$major 
${libname}${release}.so$versuffix $libname.so'
@@ -1854,18 +1853,20 @@ aix4* | aix5*)
   fi
   ;;
 esac
-# AIX (on Power*) has no versioning support, so currently we can not hardcode 
correct
-# soname into executable. Probably we can add versioning support to
-# collect2, so additional links can be useful in future.
+# AIX (on Power*) has no versioning support, so currently we can
+# not hardcode correct soname into executable. Probably we can
+# add versioning support to collect2, so additional links can
+# be useful in future.
 if test $aix_use_runtimelinking = yes; then
-  # If using run time linking (on AIX 4.2 or later) use libname.so instead of
-  # libname.a to let people know that these are not typical AIX shared 
libraries.
+  # If using run time linking (on AIX 4.2 or later) use libname.so
+  # instead of libname.a to let people know that these are not
+  # typical AIX shared libraries.
   library_names_spec='${libname}${release}.so$versuffix 
${libname}${release}.so$major $libname.so'
 else
   # We preserve .a as extension for shared libraries through AIX4.2
   # and later when we are not doing run time linking.
   library_names_spec='${libname}${release}.a $libname.a'
-  soname_spec='${libname}${release}.so$major'
+  soname_spec='${libname}${release}.so$major.o'
 fi
 shlibpath_var=LIBPATH
 deplibs_check_method=pass_all

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: AIX shared libraries in MLB and 1.4

2001-04-25 Thread Robert Boehne


Albert:

Yes, this should be the case that MLB and 1.4 are similar.
I'm suprised that they aren't actually, but I haven't really
kept up with the 1.4 patches.  Does this patch cause any
differences in the test suite results?  If not I'm all for it.

Robert

[EMAIL PROTECTED] wrote:
 
 I'm looking over the differences in how shared libraries are built
 between MLB and 1.4. Some questions:
   1. Any reason for version_type=linux in 1.4 and not MLB?
   2. Should we sync up shared library names between 1.4 and MLB
  (cf soname_spec below). Shared library names in MLB are
  libfoo.so.o while in 1.4 its libfoo.so.$major.
 
 --
 albert chin ([EMAIL PROTECTED])
 
 -- snip snip
 Index: libtool.m4
 ===
 RCS file: /home/cvs/libtool/libtool.m4,v
 retrieving revision 1.166
 diff -u -3 -p -r1.166 libtool.m4
 --- libtool.m4  2001/04/24 23:40:42 1.166
 +++ libtool.m4  2001/04/25 12:51:50
 @@ -1832,7 +1832,6 @@ aix3*)
;;
 
  aix4* | aix5*)
 -  version_type=linux
if test $host_cpu = ia64; then
  # AIX 5 supports IA64
  library_names_spec='${libname}${release}.so$major 
${libname}${release}.so$versuffix $libname.so'
 @@ -1854,18 +1853,20 @@ aix4* | aix5*)
fi
;;
  esac
 -# AIX (on Power*) has no versioning support, so currently we can not hardcode 
correct
 -# soname into executable. Probably we can add versioning support to
 -# collect2, so additional links can be useful in future.
 +# AIX (on Power*) has no versioning support, so currently we can
 +# not hardcode correct soname into executable. Probably we can
 +# add versioning support to collect2, so additional links can
 +# be useful in future.
  if test $aix_use_runtimelinking = yes; then
 -  # If using run time linking (on AIX 4.2 or later) use libname.so instead of
 -  # libname.a to let people know that these are not typical AIX shared 
libraries.
 +  # If using run time linking (on AIX 4.2 or later) use libname.so
 +  # instead of libname.a to let people know that these are not
 +  # typical AIX shared libraries.
library_names_spec='${libname}${release}.so$versuffix 
${libname}${release}.so$major $libname.so'
  else
# We preserve .a as extension for shared libraries through AIX4.2
# and later when we are not doing run time linking.
library_names_spec='${libname}${release}.a $libname.a'
 -  soname_spec='${libname}${release}.so$major'
 +  soname_spec='${libname}${release}.so$major.o'
  fi
  shlibpath_var=LIBPATH
  deplibs_check_method=pass_all
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool

-- 
Robert Boehne Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: AIX shared libraries in MLB and 1.4

2001-04-25 Thread libtool


On Wed, Apr 25, 2001 at 10:38:31AM -0500, [EMAIL PROTECTED] wrote:
 I've been meaning to send in a patch about this:
 
 soname_spec='${libname}${release}.so$major'
 
 is what we finally decided to go with for AIX standard linking.
 It is important to get these synched up, or we will have binary
 compatibility problems.

And do you plan to leave version_type=linux for 1.4? To keep 1.4 and
MLB the same, we need to decide on whether or not version_type=linux
and what soname_spec is. I'm fine with removing version_type=linux and
making soname_spec equivalent to what you have above (though different
from MLB but I'm assuming you know better what to do).

-- 
albert chin ([EMAIL PROTECTED])

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: AIX shared libraries in MLB and 1.4

2001-04-25 Thread mcnichol


Hi Albert,

It looks like AIX has been using 
version_type=linux
for quite some time.  So I guess we should keep using it.

Dan


 From: [EMAIL PROTECTED]
 
 On Wed, Apr 25, 2001 at 10:38:31AM -0500, [EMAIL PROTECTED] wrote:
  I've been meaning to send in a patch about this:
  
  soname_spec='${libname}${release}.so$major'
  
  is what we finally decided to go with for AIX standard linking.
  It is important to get these synched up, or we will have binary
  compatibility problems.
 
 And do you plan to leave version_type=linux for 1.4? To keep 1.4 and
 MLB the same, we need to decide on whether or not version_type=linux
 and what soname_spec is. I'm fine with removing version_type=linux and
 making soname_spec equivalent to what you have above (though different
 from MLB but I'm assuming you know better what to do).
 
 -- 
 albert chin ([EMAIL PROTECTED])
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool
 

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: AIX shared libraries in MLB and 1.4

2001-04-25 Thread mcnichol


I've been meaning to send in a patch about this:

soname_spec='${libname}${release}.so$major'

is what we finally decided to go with for AIX standard linking.
It is important to get these synched up, or we will have binary
compatibility problems.

Dan


 From [EMAIL PROTECTED] Wed Apr 25 08:13:05 2001
 
 I'm looking over the differences in how shared libraries are built
 between MLB and 1.4. Some questions:
   1. Any reason for version_type=linux in 1.4 and not MLB?
   2. Should we sync up shared library names between 1.4 and MLB
  (cf soname_spec below). Shared library names in MLB are
  libfoo.so.o while in 1.4 its libfoo.so.$major.
 
 -- 
 albert chin ([EMAIL PROTECTED])
 
 -- snip snip
 Index: libtool.m4
 ===
 RCS file: /home/cvs/libtool/libtool.m4,v
 retrieving revision 1.166
 diff -u -3 -p -r1.166 libtool.m4
 --- libtool.m42001/04/24 23:40:42 1.166
 +++ libtool.m42001/04/25 12:51:50
 @@ -1832,7 +1832,6 @@ aix3*)
;;
  
  aix4* | aix5*)
 -  version_type=linux
if test $host_cpu = ia64; then
  # AIX 5 supports IA64
  library_names_spec='${libname}${release}.so$major 
${libname}${release}.so$versuffix $libname.so'
 @@ -1854,18 +1853,20 @@ aix4* | aix5*)
fi
;;
  esac
 -# AIX (on Power*) has no versioning support, so currently we can not hardcode 
correct
 -# soname into executable. Probably we can add versioning support to
 -# collect2, so additional links can be useful in future.
 +# AIX (on Power*) has no versioning support, so currently we can
 +# not hardcode correct soname into executable. Probably we can
 +# add versioning support to collect2, so additional links can
 +# be useful in future.
  if test $aix_use_runtimelinking = yes; then
 -  # If using run time linking (on AIX 4.2 or later) use libname.so instead of
 -  # libname.a to let people know that these are not typical AIX shared 
libraries.
 +  # If using run time linking (on AIX 4.2 or later) use libname.so
 +  # instead of libname.a to let people know that these are not
 +  # typical AIX shared libraries.
library_names_spec='${libname}${release}.so$versuffix 
${libname}${release}.so$major $libname.so'
  else
# We preserve .a as extension for shared libraries through AIX4.2
# and later when we are not doing run time linking.
library_names_spec='${libname}${release}.a $libname.a'
 -  soname_spec='${libname}${release}.so$major'
 +  soname_spec='${libname}${release}.so$major.o'
  fi
  shlibpath_var=LIBPATH
  deplibs_check_method=pass_all
 
 ___
 Libtool mailing list
 [EMAIL PROTECTED]
 http://mail.gnu.org/mailman/listinfo/libtool
 

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: 1.3e (1.913) test results for hppa2.0n-hp-hpux11.00 (FAIL)

2001-04-25 Thread Russ Allbery


libtool [EMAIL PROTECTED] writes:
 On Tue, Apr 24, 2001 at 12:46:33AM -0700, Russ Allbery wrote:

 That patch fixed the hang.  The test results still aren't pretty.

 Apply the fix I posted to libtool-patches. That should bring it down to
 6 failures.

I assume that this is the one now in the current CVS source, and that does
indeed get it down to six failures.  Test results coming in a separate
message.

-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

1.4a (1.923) test results for hppa2.0n-hp-hpux11.00 (FAIL)

2001-04-25 Thread Russ Allbery



Configuring libtool 1.4a (1.923 2001/04/25 01:01:22)


checking for gcc... (cached) cc
checking whether the C compiler (cc  ) works... yes
checking whether the C compiler (cc  ) is a cross-compiler... no
checking whether we are using GNU C... (cached) no
checking whether cc accepts -g... (cached) yes
checking host system type... hppa2.0n-hp-hpux11.00
checking build system type... hppa2.0n-hp-hpux11.00
checking for non-GNU ld... (cached) /bin/ld
checking if the linker (/bin/ld) is GNU ld... (cached) no

FAIL: cdemo-make.test
FAIL: demo-make.test
FAIL: depdemo-make.test
FAIL: mdemo-make.test
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test


6 of 66 tests failed


-- 
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

1.4a (1.923) test results for i386-unknown-openbsd2.2

2001-04-25 Thread Edouard G. Parmelan



Configuring libtool 1.4a (1.923 2001/04/25 01:01:22)


checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking dependency style of gcc... gcc
checking host system type... i386-unknown-openbsd2.2
checking build system type... i386-unknown-openbsd2.2
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no

Uname: OpenBSD oin 2.2 GENERIC#10 i386
Directory: /tmp/egp/libtool-bin
Config-Option:

Wed Apr 25 09:43:46 2001 - configure
Wed Apr 25 09:44:50 2001 - make all
Wed Apr 25 09:46:16 2001 - make check
make all failed
22 of 83 tests failed
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test
FAIL: demo-exec.test
FAIL: demo-inst.test
FAIL: deplibs.test
FAIL: depdemo-exec.test
FAIL: depdemo-inst.test
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test
FAIL: demo-exec.test
FAIL: demo-exec.test
FAIL: demo-exec.test
FAIL: depdemo-exec.test
FAIL: demo-exec.test
FAIL: demo-inst.test
FAIL: hardcode.test
FAIL: build-relink.test
FAIL: depdemo-exec.test
FAIL: depdemo-inst.test
FAIL: build-relink2.test
FAIL: mdemo-exec.test
FAIL: mdemo-inst.test
Wed Apr 25 10:51:30 2001 - finish
-- 
Edouard G. Parmelan
http://egp.free.fr

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

quote.test in 1.4

2001-04-25 Thread libtool


Why is tests/quote.test hardcoded to use gcc? In MLB tests/quote.test,
we use $CC and get CC from tests/defs by:
  eval `$libtool --config | grep '^CC='`

-- 
albert chin ([EMAIL PROTECTED])

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

quote.test in 1.4 and MLB for AIX

2001-04-25 Thread libtool


In 1.4's libtool.m4 we have:
  if test $GCC = yes; then
lt_cv_prog_cc_wl='-Wl,'
lt_cv_prog_cc_static='-static'

case $host_os in
aix*)
...
  else
# PORTME Check for PIC flags for the system compiler.
case $host_os in
aix3* | aix4* | aix5*)
  # All AIX code is PIC.
  if test $host_cpu = ia64; then
# AIX 5 now supports IA64 processor
lt_cv_prog_cc_static='-Bstatic'
lt_cv_prog_cc_wl='-Wl,'
  else
lt_cv_prog_cc_static='-bnso -bI:/lib/syscalls.exp'
  fi
  ;;

Any reason we don't define lt_cv_prog_cc_wl='-Wl,' if $host_CPU !=
ia64? xlC 5.0 does support -Wl. From the xlc help text:
-Wx,y   Give the options y to the compiler program x
  where x can be one or more of the following:
p,c,b,i,a,l,I,L,m

In MLB's ltcf-c.sh we have:
  if test $with_gcc = yes; then
ac_cv_prog_cc_wl='-Wl,'
ac_cv_prog_cc_static='-static'

case $host_os in
aix*)
...
  else
# PORTME Check for PIC flags for the system compiler.
case $host_os in
aix*)
 # All AIX code is PIC.
  ac_cv_prog_cc_static=$ac_cv_prog_cc_static ${ac_cv_prog_cc_wl}-lC
  ;;

Any reason we don't define ac_cv_prog_cc_wl='-Wl,' for aix?

I think this is the reason quote.test is failing on MLB (because wl=
causing libtool to strip -Wl).

-- 
albert chin ([EMAIL PROTECTED])

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: AIX shared libraries in MLB and 1.4

2001-04-25 Thread libtool-patches


On Wed, Apr 25, 2001 at 11:08:05AM -0500, [EMAIL PROTECTED] wrote:
 It looks like AIX has been using 
 version_type=linux
 for quite some time.  So I guess we should keep using it.

Ok, patch to MLB to sync with 1.4 attached.

ChangeLog:
2001-04-25  Albert Chin-A-Young  [EMAIL PROTECTED]

* ltconfig.in: Remove `.o' from end of shared library
names in AIX (sync with 1.4 branch). Use $major number
in shared library name by setting version_type=linux.

 Dan
 
  From: [EMAIL PROTECTED]
  
  On Wed, Apr 25, 2001 at 10:38:31AM -0500, [EMAIL PROTECTED] wrote:
   I've been meaning to send in a patch about this:
   
   soname_spec='${libname}${release}.so$major'
   
   is what we finally decided to go with for AIX standard linking.
   It is important to get these synched up, or we will have binary
   compatibility problems.
  
  And do you plan to leave version_type=linux for 1.4? To keep 1.4 and
  MLB the same, we need to decide on whether or not version_type=linux
  and what soname_spec is. I'm fine with removing version_type=linux and
  making soname_spec equivalent to what you have above (though different
  from MLB but I'm assuming you know better what to do).
  
  -- 
  albert chin ([EMAIL PROTECTED])

-- 
albert chin ([EMAIL PROTECTED])

-- snip snip
Index: ltconfig.in
===
RCS file: /home/cvs/libtool/Attic/ltconfig.in,v
retrieving revision 1.246.2.58
diff -u -3 -p -r1.246.2.58 ltconfig.in
--- ltconfig.in 2001/04/24 22:20:08 1.246.2.58
+++ ltconfig.in 2001/04/25 17:04:01
@@ -984,6 +984,7 @@ aix3*)
   ;;
 
 aix4* | aix5*)
+  version_type=linux
   if test $host_cpu = ia64; then
 # AIX 5 supports IA64
 library_names_spec='${libname}${release}.so$versuffix 
${libname}${release}.so$major $libname.so'
@@ -1002,7 +1003,7 @@ aix4* | aix5*)
   # We preserve .a as extension for shared libraries though AIX4.2
   # and later when we are not doing run time linking.
   library_names_spec='${libname}${release}.a $libname.a'
-  soname_spec='${libname}${release}.so$major.o'
+  soname_spec='${libname}${release}.so$major'
 fi
 # If we're using GNU nm, then we don't want the -C option.
 # -C means demangle to AIX nm, but means don't demangle with GNU nm

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool-1.4

2001-04-25 Thread Alexandre Oliva


On Apr 24, 2001, Gary V.Vaughan [EMAIL PROTECTED] wrote:

 Since I don't want to hold up the release any longer, I am going to
 break the commit rules and remove all use of the inline keyword (and
 the AC_C_INLINE) from libltdl before I roll up the release -- unless
 someone asks me not to in the next few hours.

I've finally understood the problem, and it seems that removing all
uses of inline is probably excessive.  We just can't declare functions
with static variables as inline.  `static inline' (but not `inline
static') is ok for functions without static variables, as long as
`inline' is defined away for compilers that don't support it (which
AC_C_INLINE should take care of).

Of course, re-enabling inline is not a requirement for the release,
since we can always re-enable it later.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: 1.3e (1.913) test results for i386-unknown-netbsd1.4.1

2001-04-25 Thread Alexandre Oliva


On Apr 25, 2001, Nick Hudson [EMAIL PROTECTED] wrote:

 These fails due to a problem in ld.aout_so (see lib/10940) that has
 recently been fixed and is available in the netbsd-1-4 tagged sources.

Nick, would you mind submitting a patch to libtool that will disable
shared libraries in case the fix isn't present?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: 1.3e (1.913) test results for i386-unknown-netbsd1.4.1

2001-04-25 Thread Nick Hudson


Edouard G. Parmelan wrote:
 
 
 Configuring libtool 1.3e (1.913 2001/04/23 21:59:34)
 

 checking host system type... i386-unknown-netbsd1.4.1
 checking build system type... i386-unknown-netbsd1.4.1

 4 of 83 tests failed
 FAIL: mdemo-exec.test
 FAIL: mdemo-inst.test
 FAIL: mdemo-exec.test
 FAIL: mdemo-inst.test

These fails due to a problem in ld.aout_so (see lib/10940) that has
recently been fixed and is available in the netbsd-1-4 tagged sources.

Nick
-- 
aka [EMAIL PROTECTED], [EMAIL PROTECTED]

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

¹«·á·Î µå¸³´Ï´Ù.(50ºÐ¿¡°Ô¸¸)

2001-04-25 Thread E4 µµ¿ì¹ÌÀÔ´Ï´Ù .

Title: *»çÀÌ¹ö°ÁÂ(»ùÇÃÆ÷ÇÔ)¸¦µéÀ¸½Ã·Á¸éGVA¸¦¼³Ä¡ÇÏ¼Å¾ßÇÕ´Ï´Ù.























































°ú ¸ñ ¸í
¼ö°·á
±¸ 
ºÐ


Á¤º¸ Ã³¸® ±â´É»ç (ÇÊ±â)
25,000
Á¤º¸Ã³¸®


Á¤º¸ Ã³¸® ±â´É»ç (½Ç±â)
25,000
Á¤º¸Ã³¸®


Á¤º¸Ã³¸®»ê¾÷±â»ç (ÇÊ±âÆ¯°)
30,000
Á¤º¸Ã³¸®


Á¤º¸Ã³¸® »ê¾÷±â»ç ½Ç±âÆ¯°
30,000
Á¤º¸Ã³¸®


»ç¹«ÀÚµ¿È »ê¾÷±â»ç (ÇÊ±â)
30,000
Á¤º¸Ã³¸®


Àü»êÀÀ¿ë ±â°èÁ¦µµ ±â´É»ç (ÇÊ±â)
30,000
Á¤º¸Ã³¸®


Á¤º¸Ã³¸®±â»ç (½Ç±âÆ¯°)
30,000
Á¤º¸Ã³¸®


¿öµåÇÁ·Î¼¼¼ 1±Þ ÇÊ±â
25,000
¿öµå/PCÈ°¿ë


¿öµåÇÁ·Î¼¼¼ 2/3±Þ 
25,000
¿öµå/PCÈ°¿ë


¿öµå ÇÁ·Î¼¼¼ 2/3±Þ (½Ç±â)
25,000
¿öµå/PCÈ°¿ë


¿öµåÇÁ·Î¼¼¼ 1±Þ ½Ç±âÆ¯°
25,000
¿öµå/PCÈ°¿ë


ÄÄÇ»ÅÍ±×·¡ÇÈ½º ¿î¿ë±â´É»ç 
½Ç±â
25,000
¿öµå/PCÈ°¿ë


ÄÄÇ»ÅÍ È°¿ë´É·Â Æò°¡ (ÇÊ±â)
25,000
¿öµå/PCÈ°¿ë


°ÇÃà½Ã°ø ±â¼ú»ç (»ó)
45,000
°ÇÃà/Åä¸ñ


°ÇÃà½Ã°ø ±â¼ú»ç (ÇÏ)
45,000
°ÇÃà/Åä¸ñ


ÀÎÅÍ³Ý Á¤º¸°Ë»ö»ç 2±Þ(ÇÊ±â)
25,000
ÄÄÇ»ÅÍ/ÀÎÅÍ³Ý


IPCT(ÀÎÅÍ³Ý ½Ç¿ë´É·Â ÀÚ°ÝÀÎÁõ½ÃÇè) 
ÇÊ±â
25,000
ÄÄÇ»ÅÍ/ÀÎÅÍ³Ý


ÀÎÅÍ³Ý Á¤º¸°Ë»ö»ç 1±Þ ÇÊ±â (»ó)
20,000
ÄÄÇ»ÅÍ/ÀÎÅÍ³Ý


Á¤º¸°Ë»ö»ç 3±Þ (ÇÑ±¹´É·üÇùÈ¸) 
25,000
ÄÄÇ»ÅÍ/ÀÎÅÍ³Ý


ÀÎÅÍ³Ý Á¤º¸°Ë»ö»ç 1±Þ ÇÊ±â(ÇÏ)
20,000
ÄÄÇ»ÅÍ/ÀÎÅÍ³Ý


ÀÎÅÍ³Ý Á¤º¸°Ë»ö»ç 2±Þ
25,000
ÄÄÇ»ÅÍ/ÀÎÅÍ³Ý


(MCSE)Windows NT Server 4.0 
±âÃÊ
35,000
ÄÄÇ»ÅÍ/ÀÎÅÍ³Ý


CPIM(¹Ì 
°øÀÎ»ý»êÀç°í°ü¸®»ç)-BSCM
45,000
ÄÄÇ»ÅÍ/ÀÎÅÍ³Ý


ÀÌº¸´Ù ´õ ½¬¿ï¼ö ¾ø´Â µå¸²À§¹ö3.0
30,000
ÀÎÅÍ³Ý/WEB


³ª¸ð4.0 ½±°Ô µû¶óÇÏ±â
30,000
ÀÎÅÍ³Ý/WEB


ÃÊº¸ÀÚµµ ÀâÀ» ¼ö ÀÖ´Â ÀÚ¹Ù½ºÅ©¸³ÅÍ
30,000
ÀÎÅÍ³Ý/WEB


Auto CAD R14
30,000
±×·¡ÇÈ/µðÀÚÀÎ


½±°í Àç¹ÌÀÖ´Â Flash 4.0 
30,000
±×·¡ÇÈ/µðÀÚÀÎ


ÀÌº¸´Ù ´õ ½¬¿ï¼ö ¾ø´Â ÀÏ·¯½ºÆ®·¹ÀÌÅÍ 
9.0
25,000
±×·¡ÇÈ/µðÀÚÀÎ


3DStudio MAX
25,000
±×·¡ÇÈ/µðÀÚÀÎ


À¥ µðÀÚÀÎÀ» À§ÇÑ Æ÷ÅäÞ
25,000
±×·¡ÇÈ/µðÀÚÀÎ


EXCEL 97
20,000
PCÀÏ¹Ý/OA


Power-Point 97
20,000
PCÀÏ¹Ý/OA


µ¥ÀÌÅÍ Åë½Å Æ¯°
25,000
PCÀÏ¹Ý/OA


¹Ð·¹´Ï¾ö Excel 2000 Á¤º¹ÇÏ±â
25,000
PCÀÏ¹Ý/OA


¹Ð·¹´Ï¾ö PowerPoint 2000
25,000
PCÀÏ¹Ý/OA


C ±âÃÊ
25,000
ÇÁ·Î±×·¡¹Ö


Visual Basic (#1)
25,000
ÇÁ·Î±×·¡¹Ö


Visual Basic (#2)
25,000
ÇÁ·Î±×·¡¹Ö


C++ ¾ð¾î
25,000
ÇÁ·Î±×·¡¹Ö


½±°Ô ¹è¿ì´Â ASP
30,000
ÇÁ·Î±×·¡¹Ö


ÃÊº¸ÀÚµµ ÀâÀ» ¼ö ÀÖ´Â Visual 
C++
25,000
ÇÁ·Î±×·¡¹Ö


Direct-X¸¦ ÀÌ¿ëÇÑ °ÔÀÓÇÁ·Î±×·¥¹Ö 
(»ó)
25,000
ÇÁ·Î±×·¡¹Ö


Direct-XÀ» ÀÌ¿ëÇÑ °ÔÀÓÇÁ·Î±×·¥¹Ö 
(ÇÏ)
25,000
ÇÁ·Î±×·¡¹Ö


ÃÊº¸ÀÚµµ ÀâÀ»¼öÀÖ´Â JAVA 
35,000
ÇÁ·Î±×·¡¹Ö





































  

















___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: shared library linking on Darwin

2001-04-25 Thread Kevin Ryde


Gary V. Vaughan [EMAIL PROTECTED] writes:

 The problem is that libtool.m4 jumps through a bunch if hoops to
 find an echo that doesn't interpret backslashes, since it is quite a
 common problem, which causes libtool a lot of headaches.

Sorry I'm a bit thick, I've not been addressing the question.  When
invoked as /bin/sh or after emulate sh, zsh's echo seems clean.

Another question was the MLB, and as far as I can tell it has the same
problem whenever using zsh with backquotes.

 Does zsh have a `printf' builtin?  Maybe that will work -- it is
 what we use for ksh.

No, but it has a print which does some horrible transformations.

 Anyway, I have temporarily changed the backticks for darwin to $()
 until we have time to solve this correctly.

If it turns out to be eval that's the problem (and it'd be unwise to
trust me on that), perhaps it'd be a simplification to do a transform
command for each variable separately rather than in a for loop.  zsh
seems to leave backquote output alone when used directly.

lt_foo=`$echo $foo | sed 's/wacky/transform/'`

No doubt m4 could help with that, perhaps even the substitutions in
the here document could be generated that way too, via a diversion.

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: test if -c and -o work in 1.4

2001-04-25 Thread libtool


On Wed, Apr 25, 2001 at 04:13:13PM -0500, [EMAIL PROTECTED] wrote:
 The test to determine if a compiler supports -c and -o creates a
 non-writable directory and performs a test compile sending stderr to a
 file. If the file is non-empty, even if the object file was written
 (CWD is a non-writable directory while -o points to a file in a
 writable directory), the test fails. Is this correct?
 
 The IBM xlC compiler complains that the current directory is not
 writable (because it's using temporary files?) but still saves the
 object file to the path specified with -o. Do we want to assume
 success if the object file was created and has non-empty size?
 
 Anyway, if libtool runs and $need_locks=yes, should there be *any*
 lock files after libtool completes? If so, why don't you add:
   trap $run $rm $removelist; exit 0 0
 to:
 if test $compiler_c_o = no; then
   output_obj=`$echo X$srcfile | \
   $Xsed -e 's%^.*/%%' -e 's%\.[^.]*$%%'`.${objext}
   lockfile=$output_obj.lock
   removelist=$removelist $output_obj $lockfile
   trap $run $rm $removelist; exit 1 1 2 15
 in ltmain.in?

Ok, I think I found the problem. In ltmain.in from 1.4 we have:

baseobj=`$echo X$obj | $Xsed -e s%.*/%%`
libobj=`$echo X$baseobj | $Xsed -e $o2lo`
# Now arrange that obj and lo_libobj become the same file
$show (cd $xdir  $LN_S $baseobj $libobj)
if $run eval '(cd $xdir  $LN_S $baseobj $libobj)'; then
  exit 0
else

Shouldn't it be:

baseobj=`$echo X$obj | $Xsed -e s%.*/%%`
libobj=`$echo X$baseobj | $Xsed -e $o2lo`
# Now arrange that obj and lo_libobj become the same file
$show (cd $xdir  $LN_S $baseobj $libobj)
if $run eval '(cd $xdir  $LN_S $baseobj $libobj)'; then
  # Unlock the critical section if it was locked
  if test $need_locks != no; then
$run $rm $lockfile
  fi
  exit 0
else

This is the only non-zero exit before '$run $rm $lockfile' later on.

-- 
albert chin ([EMAIL PROTECTED])

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: libtool-1.4

2001-04-25 Thread Gary V . Vaughan


On Wednesday 25 April 2001  8:33 pm, Alexandre Oliva wrote:
 On Apr 24, 2001, Gary V.Vaughan [EMAIL PROTECTED] wrote:
  Since I don't want to hold up the release any longer, I am going to
  break the commit rules and remove all use of the inline keyword (and
  the AC_C_INLINE) from libltdl before I roll up the release -- unless
  someone asks me not to in the next few hours.

 I've finally understood the problem, and it seems that removing all
 uses of inline is probably excessive.  We just can't declare functions
 with static variables as inline.  `static inline' (but not `inline
 static') is ok for functions without static variables, as long as
 `inline' is defined away for compilers that don't support it (which
 AC_C_INLINE should take care of).

 Of course, re-enabling inline is not a requirement for the release,
 since we can always re-enable it later.

I have applied and ported so many patches in the last week that I couldn't 
face looking through each of the inline functions to determine which ones 
accessed static variables (it is the access rather than the declaration that 
causes problems if I understood correctly) when a quick keyboard macro would 
do the job.  Please add sorting this out properly to the TODO list so that we 
don't forget to do that after MLB has gone.

My plan is now to wait for the release to arrive on ftp.gnu.org; make the 
release announcements; take a couple of days off (hopefully the first phase 
of MLB merge will have happened by then); sort out the ltconfig- libtool.m4 
problem for the final phase of the merge; and then to apply any outstanding 
patches and/or TODO items that have built up in the interim and release 1.4.1.

I guess we will be close to a scheduled monthly alpha release from HEAD at 
that point, so we can put 1.4b out there near the end of May.

Cheers,
Gary.
-- 
  ___  _   ___   __  _ mailto: [EMAIL PROTECTED]
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___   [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/  /___/  gpg public key:
http://www.oranda.demon.co.uk   http://www.oranda.demon.co.uk/key.asc

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

ld.so.1 can't find symbol.

2001-04-25 Thread Christopher Lintz




Can someone offer direction to this strange 
problem. I have built a4 line function and built it into a shared 
library using libtool. I call thelibrary with dlopen() (which is 
succesful), but when I call dlsym() it can't find the symbol for the 
function. However, If i go into the gdb debugger and display the functions 
(info functions) in the symbol table, my function is there!!! I can even 
call the function in gdb (call foo(3) ). 

I am on Solaris 2.6 and installed the latest linker 
patch (107733-09) that did not help a thing. Does anyone know what could 
possibly be happening?? 

Here is my libtool commands (which work 
fine):
libtool gcc -g -O -c gcc001.cpplibtool gcc -g -O -o libgcc001.la 
gcc001.lo -rpath /home/cjl/lang/c++/sharedLibraries/.libs -lmlibtool gcc 
-module -o libgcc001.la gcc001.lo -rpath 
/home/cjl/lang/c++/sharedLibraries/.libs -lmlibtool gcc -g -export-dynamic 
-ldl -o dlopen dlopen.cpp
Here is my shared object code 
(gcc001.cpp):
int myTestFunction(int x){ 
x = x*2; return x;}
Here is my code that does the dlopen() and 
dlsym():

#include stdio.h#include dlfcn.h#include 
stdio.hint main(){ 
 void *handle; int 
(*fptr)(int); char* error = 0; handle = 
dlopen("/home/cjl/lang/c++/sharedLibraries/.libs/libgcc001.so", RTLD_NOW | 
RTLD_WORLD ); if(!handle) 
{ fputs( dlerror(), stderr); 
 exit( -1 ); 
} fptr = (int (*) (int) ) dlsym(handle, 
"myTestFunction"); char* error_msg = dlerror(); 
if (error_msg) { 
fprintf(stderr, "Error locating mytestFunction %s\n", error_msg 
); 
dlclose(handle); exit(-1); 
} printf("%d\n",(*fptr)(8) );  
dlclose(handle); return 0;}

Re: static/shared libraries on AIX

2001-04-25 Thread libtool


On Tue, Apr 17, 2001 at 02:51:08AM +0100, Gary V. Vaughan wrote:
  AIX by default wants it's shared libraries called libname.a.
  So libltdl.a is created (as a symlink to libltdl.so.3.0.0).
  The Makefile then wants to create a non-shared library also called
  libltdl.a. This predictably fails as follows:
  ar cru .libs/libltdl.a  ltdl.o
  ar: 0707-108 File .libs/libltdl.a is not an archive file.
 
 AIX is fast catching Ultrix in my league table of `most gratuitously 
 different Unix'...
 
  My changes get around this problem in two ways:
 
  - When building libtool with run-time-linking enabled, we no longer need
to name our shared libraries libname.a.  libname.so is used instead,
so the non-shared libltdl.a can be created without any collision.
 
  - When building libtool without run-time-linking, my changes do still
  create a libname.a.  However, it is an actual archive containing the
  shared object (just like the quirky way the rest of AIX does it).
What you end up with is a libltdl.a that contains both the shared and the
non-shared object.  This is not really what was intended, and would
  likely cause problems if you ever really needed to use the non-shared
  object, but for the most part it seems to work.  The only other thing I can
  think to do is not bulid the non-shared object in this case.

Can we decide to:
  1. On AIX systems that support run-time-linking, make it the
 *default* so libname.a is static and libname.so is
 shared. With this, -brtl would be inserted automatically
 into the compile/link phases.
  2. On AIX systems that do not support run-time-linking, support
 only shared libraries (so, libname.a is shared and there is
 no libname.so).

I'm trying to fix the remaining 'make check' failures on AIX and
knowing what to do about shared/static would certainly help. While the
above doesn't expose the full robustness of the AIX linker, methinks
it good enough.

-- 
albert chin ([EMAIL PROTECTED])

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

Re: Making hardcode.test more robust [patch against HEAD]

2001-04-25 Thread libtool


On Tue, Apr 24, 2001 at 02:47:38AM -0300, Alexandre Oliva wrote:
 On Apr 22, 2001, [EMAIL PROTECTED] wrote:
  BTW, another possible solution is to compile with CFLAGS=-s. Compiling
  without CFLAGS=-g solves the problem on Solaris and with CFLAGS=-s
  solves the problem on IRIX 6.x.
 
 I'm not sure how portable -s is.  Hmm...  Any takers?

How about running strip on the binary after creating it?

  Good point about host != build. How would I even begin to solve that?
 
 Only do the improved test when host = build.  Which amounts to falling
 back to the original version when cross compiling.  And then, I wonder
 whether we really want potentially different results for the same host
 platform...

I'll see about adding a strip after creating the binary. That might be
more portable, though I still like the objdump approach. How about a
warning if host != build and the improved test case exists?

-- 
albert chin ([EMAIL PROTECTED])

___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool

AIX shared libraries in MLB and 1.4

Re: AIX shared libraries in MLB and 1.4

Re: AIX shared libraries in MLB and 1.4

Re: AIX shared libraries in MLB and 1.4

Re: AIX shared libraries in MLB and 1.4

Re: 1.3e (1.913) test results for hppa2.0n-hp-hpux11.00 (FAIL)

1.4a (1.923) test results for hppa2.0n-hp-hpux11.00 (FAIL)

1.4a (1.923) test results for i386-unknown-openbsd2.2

quote.test in 1.4

quote.test in 1.4 and MLB for AIX

Re: AIX shared libraries in MLB and 1.4

Re: libtool-1.4

Re: 1.3e (1.913) test results for i386-unknown-netbsd1.4.1

Re: 1.3e (1.913) test results for i386-unknown-netbsd1.4.1

¹«·á·Î µå¸³´Ï´Ù.(50ºÐ¿¡°Ô¸¸)

Re: shared library linking on Darwin

Re: test if -c and -o work in 1.4

Re: libtool-1.4

ld.so.1 can't find symbol.

Re: static/shared libraries on AIX

Re: Making hardcode.test more robust [patch against HEAD]

21 matches

Site Navigation

Mail list logo

Footer information