Search Results

Search found 15833 results on 634 pages for 'member objects'.

Page 1/634 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Oracle Coherence, Split-Brain and Recovery Protocols In Detail

    - by Ricardo Ferreira
    This article provides a high level conceptual overview of Split-Brain scenarios in distributed systems. It will focus on a specific example of cluster communication failure and recovery in Oracle Coherence. This includes a discussion on the witness protocol (used to remove failed cluster members) and the panic protocol (used to resolve Split-Brain scenarios). Note that the removal of cluster members does not necessarily indicate a Split-Brain condition. Oracle Coherence does not (and cannot) detect a Split-Brain as it occurs, the condition is only detected when cluster members that previously lost contact with each other regain contact. Cluster Topology and Configuration In order to create an good didactic for the article, let's assume a cluster topology and configuration. In this example we have a six member cluster, consisting of one JVM on each physical machine. The member IDs are as follows: Member ID  IP Address  1  10.149.155.76  2  10.149.155.77  3  10.149.155.236  4  10.149.155.75  5  10.149.155.79  6  10.149.155.78 Members 1, 2, and 3 are connected to a switch, and members 4, 5, and 6 are connected to a second switch. There is a link between the two switches, which provides network connectivity between all of the machines. Member 1 is the first member to join this cluster, thus making it the senior member. Member 6 is the last member to join this cluster. Here is a log snippet from Member 6 showing the complete member set: 2010-02-26 15:27:57.390/3.062 Oracle Coherence GE 3.5.3/465p2 <Info> (thread=main, member=6): Started DefaultCacheServer... SafeCluster: Name=cluster:0xDDEB Group{Address=224.3.5.3, Port=35465, TTL=4} MasterMemberSet ( ThisMember=Member(Id=6, Timestamp=2010-02-26 15:27:58.635, Address=10.149.155.78:8088, MachineId=1102, Location=process:228, Role=CoherenceServer) OldestMember=Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) ActualMemberSet=MemberSet(Size=6, BitSetCount=2 Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) Member(Id=2, Timestamp=2010-02-26 15:27:17.847, Address=10.149.155.77:8088, MachineId=1101, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:296, Role=CoherenceServer) Member(Id=3, Timestamp=2010-02-26 15:27:24.892, Address=10.149.155.236:8088, MachineId=1260, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:32459, Role=CoherenceServer) Member(Id=4, Timestamp=2010-02-26 15:27:39.574, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer) Member(Id=5, Timestamp=2010-02-26 15:27:49.095, Address=10.149.155.79:8088, MachineId=1103, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:3229, Role=CoherenceServer) Member(Id=6, Timestamp=2010-02-26 15:27:58.635, Address=10.149.155.78:8088, MachineId=1102, Location=process:228, Role=CoherenceServer) ) RecycleMillis=120000 RecycleSet=MemberSet(Size=0, BitSetCount=0 ) ) At approximately 15:30, the connection between the two switches is severed: Thirty seconds later (the default packet timeout in development mode) the logs indicate communication failures across the cluster. In this example, the communication failure was caused by a network failure. In a production setting, this type of communication failure can have many root causes, including (but not limited to) network failures, excessive GC, high CPU utilization, swapping/virtual memory, and exceeding maximum network bandwidth. In addition, this type of failure is not necessarily indicative of a split brain. Any communication failure will be logged in this fashion. Member 2 logs a communication failure with Member 5: 2010-02-26 15:30:32.638/196.928 Oracle Coherence GE 3.5.3/465p2 <Warning> (thread=PacketPublisher, member=2): Timeout while delivering a packet; requesting the departure confirmation for Member(Id=5, Timestamp=2010-02-26 15:27:49.095, Address=10.149.155.79:8088, MachineId=1103, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:3229, Role=CoherenceServer) by MemberSet(Size=2, BitSetCount=2 Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) Member(Id=4, Timestamp=2010-02-26 15:27:39.574, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer) ) The Coherence clustering protocol (TCMP) is a reliable transport mechanism built on UDP. In order for the protocol to be reliable, it requires an acknowledgement (ACK) for each packet delivered. If a packet fails to be acknowledged within the configured timeout period, the Coherence cluster member will log a packet timeout (as seen in the log message above). When this occurs, the cluster member will consult with other members to determine who is at fault for the communication failure. If the witness members agree that the suspect member is at fault, the suspect is removed from the cluster. If the witnesses unanimously disagree, the accuser is removed. This process is known as the witness protocol. Since Member 2 cannot communicate with Member 5, it selects two witnesses (Members 1 and 4) to determine if the communication issue is with Member 5 or with itself (Member 2). However, Member 4 is on the switch that is no longer accessible by Members 1, 2 and 3; thus a packet timeout for member 4 is recorded as well: 2010-02-26 15:30:35.648/199.938 Oracle Coherence GE 3.5.3/465p2 <Warning> (thread=PacketPublisher, member=2): Timeout while delivering a packet; requesting the departure confirmation for Member(Id=4, Timestamp=2010-02-26 15:27:39.574, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer) by MemberSet(Size=2, BitSetCount=2 Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) Member(Id=6, Timestamp=2010-02-26 15:27:58.635, Address=10.149.155.78:8088, MachineId=1102, Location=process:228, Role=CoherenceServer) ) Member 1 has the ability to confirm the departure of member 4, however Member 6 cannot as it is also inaccessible. At the same time, Member 3 sends a request to remove Member 6, which is followed by a report from Member 3 indicating that Member 6 has departed the cluster: 2010-02-26 15:30:35.706/199.996 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=2): MemberLeft request for Member 6 received from Member(Id=3, Timestamp=2010-02-26 15:27:24.892, Address=10.149.155.236:8088, MachineId=1260, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:32459, Role=CoherenceServer) 2010-02-26 15:30:35.709/199.999 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=2): MemberLeft notification for Member 6 received from Member(Id=3, Timestamp=2010-02-26 15:27:24.892, Address=10.149.155.236:8088, MachineId=1260, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:32459, Role=CoherenceServer) The log for Member 3 determines how Member 6 departed the cluster: 2010-02-26 15:30:35.161/191.694 Oracle Coherence GE 3.5.3/465p2 <Warning> (thread=PacketPublisher, member=3): Timeout while delivering a packet; requesting the departure confirmation for Member(Id=6, Timestamp=2010-02-26 15:27:58.635, Address=10.149.155.78:8088, MachineId=1102, Location=process:228, Role=CoherenceServer) by MemberSet(Size=2, BitSetCount=2 Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) Member(Id=2, Timestamp=2010-02-26 15:27:17.847, Address=10.149.155.77:8088, MachineId=1101, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:296, Role=CoherenceServer) ) 2010-02-26 15:30:35.165/191.698 Oracle Coherence GE 3.5.3/465p2 <Info> (thread=Cluster, member=3): Member departure confirmed by MemberSet(Size=2, BitSetCount=2 Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) Member(Id=2, Timestamp=2010-02-26 15:27:17.847, Address=10.149.155.77:8088, MachineId=1101, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:296, Role=CoherenceServer) ); removing Member(Id=6, Timestamp=2010-02-26 15:27:58.635, Address=10.149.155.78:8088, MachineId=1102, Location=process:228, Role=CoherenceServer) In this case, Member 3 happened to select two witnesses that it still had connectivity with (Members 1 and 2) thus resulting in a simple decision to remove Member 6. Given the departure of Member 6, Member 2 is left with a single witness to confirm the departure of Member 4: 2010-02-26 15:30:35.713/200.003 Oracle Coherence GE 3.5.3/465p2 <Info> (thread=Cluster, member=2): Member departure confirmed by MemberSet(Size=1, BitSetCount=2 Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) ); removing Member(Id=4, Timestamp=2010-02-26 15:27:39.574, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer) In the meantime, Member 4 logs a missing heartbeat from the senior member. This message is also logged on Members 5 and 6. 2010-02-26 15:30:07.906/150.453 Oracle Coherence GE 3.5.3/465p2 <Info> (thread=PacketListenerN, member=4): Scheduled senior member heartbeat is overdue; rejoining multicast group. Next, Member 4 logs a TcpRing failure with Member 2, thus resulting in the termination of Member 2: 2010-02-26 15:30:21.421/163.968 Oracle Coherence GE 3.5.3/465p2 <D4> (thread=Cluster, member=4): TcpRing: Number of socket exceptions exceeded maximum; last was "java.net.SocketTimeoutException: connect timed out"; removing the member: 2 For quick process termination detection, Oracle Coherence utilizes a feature called TcpRing which is a sparse collection of TCP/IP-based connections between different members in the cluster. Each member in the cluster is connected to at least one other member, which (if at all possible) is running on a different physical box. This connection is not used for any data transfer, only heartbeat communications are sent once a second per each link. If a certain number of exceptions are thrown while trying to re-establish a connection, the member throwing the exceptions is removed from the cluster. Member 5 logs a packet timeout with Member 3 and cites witnesses Members 4 and 6: 2010-02-26 15:30:29.791/165.037 Oracle Coherence GE 3.5.3/465p2 <Warning> (thread=PacketPublisher, member=5): Timeout while delivering a packet; requesting the departure confirmation for Member(Id=3, Timestamp=2010-02-26 15:27:24.892, Address=10.149.155.236:8088, MachineId=1260, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:32459, Role=CoherenceServer) by MemberSet(Size=2, BitSetCount=2 Member(Id=4, Timestamp=2010-02-26 15:27:39.574, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer) Member(Id=6, Timestamp=2010-02-26 15:27:58.635, Address=10.149.155.78:8088, MachineId=1102, Location=process:228, Role=CoherenceServer) ) 2010-02-26 15:30:29.798/165.044 Oracle Coherence GE 3.5.3/465p2 <Info> (thread=Cluster, member=5): Member departure confirmed by MemberSet(Size=2, BitSetCount=2 Member(Id=4, Timestamp=2010-02-26 15:27:39.574, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer) Member(Id=6, Timestamp=2010-02-26 15:27:58.635, Address=10.149.155.78:8088, MachineId=1102, Location=process:228, Role=CoherenceServer) ); removing Member(Id=3, Timestamp=2010-02-26 15:27:24.892, Address=10.149.155.236:8088, MachineId=1260, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:32459, Role=CoherenceServer) Eventually we are left with two distinct clusters consisting of Members 1, 2, 3 and Members 4, 5, 6, respectively. In the latter cluster, Member 4 is promoted to senior member. The connection between the two switches is restored at 15:33. Upon the restoration of the connection, the cluster members immediately receive cluster heartbeats from the two senior members. In the case of Members 1, 2, and 3, the following is logged: 2010-02-26 15:33:14.970/369.066 Oracle Coherence GE 3.5.3/465p2 <Warning> (thread=Cluster, member=1): The member formerly known as Member(Id=4, Timestamp=2010-02-26 15:30:35.341, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer) has been forcefully evicted from the cluster, but continues to emit a cluster heartbeat; henceforth, the member will be shunned and its messages will be ignored. Likewise for Members 4, 5, and 6: 2010-02-26 15:33:14.343/336.890 Oracle Coherence GE 3.5.3/465p2 <Warning> (thread=Cluster, member=4): The member formerly known as Member(Id=1, Timestamp=2010-02-26 15:30:31.64, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) has been forcefully evicted from the cluster, but continues to emit a cluster heartbeat; henceforth, the member will be shunned and its messages will be ignored. This message indicates that a senior heartbeat is being received from members that were previously removed from the cluster, in other words, something that should not be possible. For this reason, the recipients of these messages will initially ignore them. After several iterations of these messages, the existence of multiple clusters is acknowledged, thus triggering the panic protocol to reconcile this situation. When the presence of more than one cluster (i.e. Split-Brain) is detected by a Coherence member, the panic protocol is invoked in order to resolve the conflicting clusters and consolidate into a single cluster. The protocol consists of the removal of smaller clusters until there is one cluster remaining. In the case of equal size clusters, the one with the older Senior Member will survive. Member 1, being the oldest member, initiates the protocol: 2010-02-26 15:33:45.970/400.066 Oracle Coherence GE 3.5.3/465p2 <Warning> (thread=Cluster, member=1): An existence of a cluster island with senior Member(Id=4, Timestamp=2010-02-26 15:27:39.574, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer) containing 3 nodes have been detected. Since this Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) is the senior of an older cluster island, the panic protocol is being activated to stop the other island's senior and all junior nodes that belong to it. Member 3 receives the panic: 2010-02-26 15:33:45.803/382.336 Oracle Coherence GE 3.5.3/465p2 <Error> (thread=Cluster, member=3): Received panic from senior Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer) caused by Member(Id=4, Timestamp=2010-02-26 15:27:39.574, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer) Member 4, the senior member of the younger cluster, receives the kill message from Member 3: 2010-02-26 15:33:44.921/367.468 Oracle Coherence GE 3.5.3/465p2 <Error> (thread=Cluster, member=4): Received a Kill message from a valid Member(Id=3, Timestamp=2010-02-26 15:27:24.892, Address=10.149.155.236:8088, MachineId=1260, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:32459, Role=CoherenceServer); stopping cluster service. In turn, Member 4 requests the departure of its junior members 5 and 6: 2010-02-26 15:33:44.921/367.468 Oracle Coherence GE 3.5.3/465p2 <Error> (thread=Cluster, member=4): Received a Kill message from a valid Member(Id=3, Timestamp=2010-02-26 15:27:24.892, Address=10.149.155.236:8088, MachineId=1260, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:32459, Role=CoherenceServer); stopping cluster service. 2010-02-26 15:33:43.343/349.015 Oracle Coherence GE 3.5.3/465p2 <Error> (thread=Cluster, member=6): Received a Kill message from a valid Member(Id=4, Timestamp=2010-02-26 15:27:39.574, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer); stopping cluster service. Once Members 4, 5, and 6 restart, they rejoin the original cluster with senior member 1. The log below is from Member 4. Note that it receives a different member id when it rejoins the cluster. 2010-02-26 15:33:44.921/367.468 Oracle Coherence GE 3.5.3/465p2 <Error> (thread=Cluster, member=4): Received a Kill message from a valid Member(Id=3, Timestamp=2010-02-26 15:27:24.892, Address=10.149.155.236:8088, MachineId=1260, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:32459, Role=CoherenceServer); stopping cluster service. 2010-02-26 15:33:46.921/369.468 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=4): Service Cluster left the cluster 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Invocation:InvocationService, member=4): Service InvocationService left the cluster 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=OptimisticCache, member=4): Service OptimisticCache left the cluster 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=ReplicatedCache, member=4): Service ReplicatedCache left the cluster 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=DistributedCache, member=4): Service DistributedCache left the cluster 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Invocation:Management, member=4): Service Management left the cluster 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=4): Member 6 left service Management with senior member 5 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=4): Member 6 left service DistributedCache with senior member 5 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=4): Member 6 left service ReplicatedCache with senior member 5 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=4): Member 6 left service OptimisticCache with senior member 5 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=4): Member 6 left service InvocationService with senior member 5 2010-02-26 15:33:47.046/369.593 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=4): Member(Id=6, Timestamp=2010-02-26 15:33:47.046, Address=10.149.155.78:8088, MachineId=1102, Location=process:228, Role=CoherenceServer) left Cluster with senior member 4 2010-02-26 15:33:49.218/371.765 Oracle Coherence GE 3.5.3/465p2 <Info> (thread=main, member=n/a): Restarting cluster 2010-02-26 15:33:49.421/371.968 Oracle Coherence GE 3.5.3/465p2 <D5> (thread=Cluster, member=n/a): Service Cluster joined the cluster with senior service member n/a 2010-02-26 15:33:49.625/372.172 Oracle Coherence GE 3.5.3/465p2 <Info> (thread=Cluster, member=n/a): This Member(Id=5, Timestamp=2010-02-26 15:33:50.499, Address=10.149.155.75:8088, MachineId=1099, Location=process:800, Role=CoherenceServer, Edition=Grid Edition, Mode=Development, CpuCount=2, SocketCount=1) joined cluster "cluster:0xDDEB" with senior Member(Id=1, Timestamp=2010-02-26 15:27:06.931, Address=10.149.155.76:8088, MachineId=1100, Location=site:usdhcp.oraclecorp.com,machine:dhcp-burlington6-4fl-east-10-149,process:511, Role=CoherenceServer, Edition=Grid Edition, Mode=Development, CpuCount=2, SocketCount=2) Cool isn't it?

    Read the article

  • MAMP + Python MySQLDB - trouble installing

    - by Frederico
    I'm currently running the latest version of MAMP on my Snow Leopard OSX, and I'm trying to install MySQLDB. Downloaded: MySQL-python-1.2.3c1 I went into the setup_posix.py and adjusted the location of the mysql_config to the one in MAMP: mysql_config.path = "/Applications/MAMP/Library/bin/mysql_config" When trying to build I get the error below. Could anyone give me a hand please: creating build/temp.macosx-10.6-universal-2.6 gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch i386 -arch ppc -arch x86_64 -pipe -Dversion_info=(1,2,3,'gamma',1) -D_version_=1.2.3c1 -I/Applications/MAMP/Library/include/mysql -I/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -c _mysql.c -o build/temp.macosx-10.6-universal-2.6/_mysql.o -fno-omit-frame-pointer -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL _mysql.c:36:23: error: my_config.h: No such file or directory _mysql.c:38:19: error: mysql.h: No such file or directory _mysql.c:39:26: error: mysqld_error.h: No such file or directory _mysql.c:40:20: error: errmsg.h: No such file or directory _mysql.c:76: error: expected specifier-qualifier-list before ‘MYSQL’ _mysql.c:90: error: expected specifier-qualifier-list before ‘MYSQL_RES’ _mysql.c: In function ‘_mysql_Exception’: _mysql.c:120: warning: implicit declaration of function ‘mysql_errno’ _mysql.c:120: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:123: error: ‘CR_MAX_ERROR’ undeclared (first use in this function) _mysql.c:123: error: (Each undeclared identifier is reported only once _mysql.c:123: error: for each function it appears in.) _mysql.c:131: error: ‘CR_COMMANDS_OUT_OF_SYNC’ undeclared (first use in this function) _mysql.c:132: error: ‘ER_DB_CREATE_EXISTS’ undeclared (first use in this function) _mysql.c:133: error: ‘ER_SYNTAX_ERROR’ undeclared (first use in this function) _mysql.c:134: error: ‘ER_PARSE_ERROR’ undeclared (first use in this function) _mysql.c:135: error: ‘ER_NO_SUCH_TABLE’ undeclared (first use in this function) _mysql.c:136: error: ‘ER_WRONG_DB_NAME’ undeclared (first use in this function) _mysql.c:137: error: ‘ER_WRONG_TABLE_NAME’ undeclared (first use in this function) _mysql.c:138: error: ‘ER_FIELD_SPECIFIED_TWICE’ undeclared (first use in this function) _mysql.c:139: error: ‘ER_INVALID_GROUP_FUNC_USE’ undeclared (first use in this function) _mysql.c:140: error: ‘ER_UNSUPPORTED_EXTENSION’ undeclared (first use in this function) _mysql.c:141: error: ‘ER_TABLE_MUST_HAVE_COLUMNS’ undeclared (first use in this function) _mysql.c:170: error: ‘ER_DUP_ENTRY’ undeclared (first use in this function) _mysql.c:213: warning: implicit declaration of function ‘mysql_error’ _mysql.c:213: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:213: warning: passing argument 1 of ‘PyString_FromString’ makes pointer from integer without a cast _mysql.c: In function ‘_mysql_server_init’: _mysql.c:308: warning: label ‘finish’ defined but not used _mysql.c:234: warning: unused variable ‘item’ _mysql.c:233: warning: unused variable ‘groupc’ _mysql.c:233: warning: unused variable ‘i’ _mysql.c:233: warning: unused variable ‘cmd_argc’ _mysql.c:232: warning: unused variable ‘s’ _mysql.c: In function ‘_mysql_ResultObject_Initialize’: _mysql.c:363: error: ‘MYSQL_RES’ undeclared (first use in this function) _mysql.c:363: error: ‘result’ undeclared (first use in this function) _mysql.c:368: error: ‘MYSQL_FIELD’ undeclared (first use in this function) _mysql.c:368: error: ‘fields’ undeclared (first use in this function) _mysql.c:377: error: ‘_mysql_ResultObject’ has no member named ‘use’ _mysql.c:380: warning: implicit declaration of function ‘mysql_use_result’ _mysql.c:380: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:382: warning: implicit declaration of function ‘mysql_store_result’ _mysql.c:382: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:383: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:386: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:389: warning: implicit declaration of function ‘mysql_num_fields’ _mysql.c:390: error: ‘_mysql_ResultObject’ has no member named ‘nfields’ _mysql.c:391: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:392: warning: implicit declaration of function ‘mysql_fetch_fields’ _mysql.c:438: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c: In function ‘_mysql_ResultObject_traverse’: _mysql.c:450: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:451: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c: In function ‘_mysql_ResultObject_clear’: _mysql.c:462: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:462: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:462: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:462: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:463: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c: In function ‘_mysql_ConnectionObject_Initialize’: _mysql.c:475: error: ‘MYSQL’ undeclared (first use in this function) _mysql.c:475: error: ‘conn’ undeclared (first use in this function) _mysql.c:500: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:501: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:525: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:547: warning: implicit declaration of function ‘mysql_init’ _mysql.c:547: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:550: warning: implicit declaration of function ‘mysql_options’ _mysql.c:550: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:550: error: ‘MYSQL_OPT_CONNECT_TIMEOUT’ undeclared (first use in this function) _mysql.c:554: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:554: error: ‘MYSQL_OPT_COMPRESS’ undeclared (first use in this function) _mysql.c:555: error: ‘CLIENT_COMPRESS’ undeclared (first use in this function) _mysql.c:558: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:558: error: ‘MYSQL_OPT_NAMED_PIPE’ undeclared (first use in this function) _mysql.c:560: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:560: error: ‘MYSQL_INIT_COMMAND’ undeclared (first use in this function) _mysql.c:562: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:562: error: ‘MYSQL_READ_DEFAULT_FILE’ undeclared (first use in this function) _mysql.c:564: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:564: error: ‘MYSQL_READ_DEFAULT_GROUP’ undeclared (first use in this function) _mysql.c:567: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:567: error: ‘MYSQL_OPT_LOCAL_INFILE’ undeclared (first use in this function) _mysql.c:575: warning: implicit declaration of function ‘mysql_real_connect’ _mysql.c:575: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:590: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c: In function ‘_mysql_ConnectionObject_traverse’: _mysql.c:671: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:672: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c: In function ‘_mysql_ConnectionObject_clear’: _mysql.c:680: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:680: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:680: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:680: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:681: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c: In function ‘_mysql_ConnectionObject_close’: _mysql.c:696: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:698: warning: implicit declaration of function ‘mysql_close’ _mysql.c:698: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:700: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c: In function ‘_mysql_ConnectionObject_affected_rows’: _mysql.c:722: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:723: warning: implicit declaration of function ‘mysql_affected_rows’ _mysql.c:723: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_debug’: _mysql.c:739: warning: implicit declaration of function ‘mysql_debug’ _mysql.c: In function ‘_mysql_ConnectionObject_dump_debug_info’: _mysql.c:757: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:759: warning: implicit declaration of function ‘mysql_dump_debug_info’ _mysql.c:759: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_autocommit’: _mysql.c:783: warning: implicit declaration of function ‘mysql_query’ _mysql.c:783: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_commit’: _mysql.c:806: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_rollback’: _mysql.c:828: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_errno’: _mysql.c:940: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:941: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_error’: _mysql.c:956: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:957: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:957: warning: passing argument 1 of ‘PyString_FromString’ makes pointer from integer without a cast _mysql.c: In function ‘_mysql_escape_string’: _mysql.c:981: warning: implicit declaration of function ‘mysql_escape_string’ _mysql.c: In function ‘_mysql_escape’: _mysql.c:1088: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c: In function ‘_mysql_ResultObject_describe’: _mysql.c:1168: error: ‘MYSQL_FIELD’ undeclared (first use in this function) _mysql.c:1168: error: ‘fields’ undeclared (first use in this function) _mysql.c:1171: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1172: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1173: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1184: warning: implicit declaration of function ‘IS_NOT_NULL’ _mysql.c: In function ‘_mysql_ResultObject_field_flags’: _mysql.c:1204: error: ‘MYSQL_FIELD’ undeclared (first use in this function) _mysql.c:1204: error: ‘fields’ undeclared (first use in this function) _mysql.c:1207: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1208: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1209: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: At top level: _mysql.c:1250: error: expected declaration specifiers or ‘...’ before ‘MYSQL_ROW’ _mysql.c: In function ‘_mysql_row_to_tuple’: _mysql.c:1256: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1258: warning: implicit declaration of function ‘mysql_fetch_lengths’ _mysql.c:1258: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1258: warning: assignment makes pointer from integer without a cast _mysql.c:1261: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:1262: error: ‘row’ undeclared (first use in this function) _mysql.c: At top level: _mysql.c:1275: error: expected declaration specifiers or ‘...’ before ‘MYSQL_ROW’ _mysql.c: In function ‘_mysql_row_to_dict’: _mysql.c:1280: error: ‘MYSQL_FIELD’ undeclared (first use in this function) _mysql.c:1280: error: ‘fields’ undeclared (first use in this function) _mysql.c:1282: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1284: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1284: warning: assignment makes pointer from integer without a cast _mysql.c:1285: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1288: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:1289: error: ‘row’ undeclared (first use in this function) _mysql.c: At top level: _mysql.c:1314: error: expected declaration specifiers or ‘...’ before ‘MYSQL_ROW’ _mysql.c: In function ‘_mysql_row_to_dict_old’: _mysql.c:1319: error: ‘MYSQL_FIELD’ undeclared (first use in this function) _mysql.c:1319: error: ‘fields’ undeclared (first use in this function) _mysql.c:1321: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1323: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1323: warning: assignment makes pointer from integer without a cast _mysql.c:1324: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1327: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:1328: error: ‘row’ undeclared (first use in this function) _mysql.c: At top level: _mysql.c:1350: error: expected declaration specifiers or ‘...’ before ‘MYSQL_ROW’ _mysql.c: In function ‘mysql_fetch_row’: _mysql.c:1361: error: ‘MYSQL_ROW’ undeclared (first use in this function) _mysql.c:1361: error: expected ‘;’ before ‘row’ _mysql.c:1365: error: ‘_mysql_ResultObject’ has no member named ‘use’ _mysql.c:1366: error: ‘row’ undeclared (first use in this function) _mysql.c:1366: warning: implicit declaration of function ‘mysql_fetch_row’ _mysql.c:1366: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1369: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:1372: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:1380: error: too many arguments to function ‘convert_row’ _mysql.c: In function ‘_mysql_ResultObject_fetch_row’: _mysql.c:1404: error: expected declaration specifiers or ‘...’ before ‘MYSQL_ROW’ _mysql.c:1419: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1431: error: ‘_mysql_ResultObject’ has no member named ‘use’ _mysql.c:1445: warning: implicit declaration of function ‘mysql_num_rows’ _mysql.c:1445: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: In function ‘_mysql_ConnectionObject_character_set_name’: _mysql.c:1512: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c: In function ‘_mysql_get_client_info’: _mysql.c:1603: warning: implicit declaration of function ‘mysql_get_client_info’ _mysql.c:1603: warning: passing argument 1 of ‘PyString_FromString’ makes pointer from integer without a cast _mysql.c: In function ‘_mysql_ConnectionObject_get_host_info’: _mysql.c:1617: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1618: warning: implicit declaration of function ‘mysql_get_host_info’ _mysql.c:1618: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:1618: warning: passing argument 1 of ‘PyString_FromString’ makes pointer from integer without a cast _mysql.c: In function ‘_mysql_ConnectionObject_get_proto_info’: _mysql.c:1632: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1633: warning: implicit declaration of function ‘mysql_get_proto_info’ _mysql.c:1633: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_get_server_info’: _mysql.c:1647: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1648: warning: implicit declaration of function ‘mysql_get_server_info’ _mysql.c:1648: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:1648: warning: passing argument 1 of ‘PyString_FromString’ makes pointer from integer without a cast _mysql.c: In function ‘_mysql_ConnectionObject_info’: _mysql.c:1664: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1665: warning: implicit declaration of function ‘mysql_info’ _mysql.c:1665: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:1665: warning: assignment makes pointer from integer without a cast _mysql.c: In function ‘_mysql_ConnectionObject_insert_id’: _mysql.c:1697: error: ‘my_ulonglong’ undeclared (first use in this function) _mysql.c:1697: error: expected ‘;’ before ‘r’ _mysql.c:1699: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1701: error: ‘r’ undeclared (first use in this function) _mysql.c:1701: warning: implicit declaration of function ‘mysql_insert_id’ _mysql.c:1701: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_kill’: _mysql.c:1718: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1720: warning: implicit declaration of function ‘mysql_kill’ _mysql.c:1720: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_field_count’: _mysql.c:1739: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1741: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ResultObject_num_fields’: _mysql.c:1756: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1757: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: In function ‘_mysql_ResultObject_num_rows’: _mysql.c:1772: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1773: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: In function ‘_mysql_ConnectionObject_ping’: _mysql.c:1802: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1803: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:1805: warning: implicit declaration of function ‘mysql_ping’ _mysql.c:1805: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_query’: _mysql.c:1826: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1828: warning: implicit declaration of function ‘mysql_real_query’ _mysql.c:1828: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_select_db’: _mysql.c:1856: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1858: warning: implicit declaration of function ‘mysql_select_db’ _mysql.c:1858: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_shutdown’: _mysql.c:1877: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1879: warning: implicit declaration of function ‘mysql_shutdown’ _mysql.c:1879: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_stat’: _mysql.c:1904: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1906: warning: implicit declaration of function ‘mysql_stat’ _mysql.c:1906: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:1906: warning: assignment makes pointer from integer without a cast _mysql.c: In function ‘_mysql_ConnectionObject_store_result’: _mysql.c:1927: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1928: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:1937: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: In function ‘_mysql_ConnectionObject_thread_id’: _mysql.c:1966: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1968: warning: implicit declaration of function ‘mysql_thread_id’ _mysql.c:1968: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ConnectionObject_use_result’: _mysql.c:1988: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:1989: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:1998: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: In function ‘_mysql_ConnectionObject_dealloc’: _mysql.c:2016: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c: In function ‘_mysql_ConnectionObject_repr’: _mysql.c:2028: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:2029: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c: In function ‘_mysql_ResultObject_data_seek’: _mysql.c:2047: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:2048: warning: implicit declaration of function ‘mysql_data_seek’ _mysql.c:2048: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: In function ‘_mysql_ResultObject_row_seek’: _mysql.c:2061: error: ‘MYSQL_ROW_OFFSET’ undeclared (first use in this function) _mysql.c:2061: error: expected ‘;’ before ‘r’ _mysql.c:2063: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:2064: error: ‘_mysql_ResultObject’ has no member named ‘use’ _mysql.c:2069: error: ‘r’ undeclared (first use in this function) _mysql.c:2069: warning: implicit declaration of function ‘mysql_row_tell’ _mysql.c:2069: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:2070: warning: implicit declaration of function ‘mysql_row_seek’ _mysql.c:2070: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: In function ‘_mysql_ResultObject_row_tell’: _mysql.c:2082: error: ‘MYSQL_ROW_OFFSET’ undeclared (first use in this function) _mysql.c:2082: error: expected ‘;’ before ‘r’ _mysql.c:2084: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:2085: error: ‘_mysql_ResultObject’ has no member named ‘use’ _mysql.c:2090: error: ‘r’ undeclared (first use in this function) _mysql.c:2090: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:2091: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: In function ‘_mysql_ResultObject_dealloc’: _mysql.c:2099: warning: implicit declaration of function ‘mysql_free_result’ _mysql.c:2099: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c: At top level: _mysql.c:2330: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:2337: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:2344: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:2351: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:2358: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:2421: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:2421: error: initializer element is not constant _mysql.c:2421: error: (near initialization for ‘_mysql_ResultObject_memberlist[0].offset’) _mysql.c: In function ‘_mysql_ConnectionObject_getattr’: _mysql.c:2443: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:36:23: error: my_config.h: No such file or directory _mysql.c:38:19: error: mysql.h: No such file or directory _mysql.c:39:26: error: mysqld_error.h: No such file or directory _mysql.c:40:20: error: errmsg.h: No such file or directory _mysql.c:76: error: expected specifier-qualifier-list before ‘MYSQL’ _mysql.c:90: error: expected specifier-qualifier-list before ‘MYSQL_RES’ _mysql.c: In function ‘_mysql_Exception’: _mysql.c:120: warning: implicit declaration of function ‘mysql_errno’ _mysql.c:120: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:123: error: ‘CR_MAX_ERROR’ undeclared (first use in this function) _mysql.c:123: error: (Each undeclared identifier is reported only once _mysql.c:123: error: for each function it appears in.) _mysql.c:131: error: ‘CR_COMMANDS_OUT_OF_SYNC’ undeclared (first use in this function) _mysql.c:132: error: ‘ER_DB_CREATE_EXISTS’ undeclared (first use in this function) _mysql.c:133: error: ‘ER_SYNTAX_ERROR’ undeclared (first use in this function) _mysql.c:134: error: ‘ER_PARSE_ERROR’ undeclared (first use in this function) _mysql.c:135: error: ‘ER_NO_SUCH_TABLE’ undeclared (first use in this function) _mysql.c:136: error: ‘ER_WRONG_DB_NAME’ undeclared (first use in this function) _mysql.c:137: error: ‘ER_WRONG_TABLE_NAME’ undeclared (first use in this function) _mysql.c:138: error: ‘ER_FIELD_SPECIFIED_TWICE’ undeclared (first use in this function) _mysql.c:139: error: ‘ER_INVALID_GROUP_FUNC_USE’ undeclared (first use in this function) _mysql.c:140: error: ‘ER_UNSUPPORTED_EXTENSION’ undeclared (first use in this function) _mysql.c:141: error: ‘ER_TABLE_MUST_HAVE_COLUMNS’ undeclared (first use in this function) _mysql.c:170: error: ‘ER_DUP_ENTRY’ undeclared (first use in this function) _mysql.c:213: warning: implicit declaration of function ‘mysql_error’ _mysql.c:213: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:213: warning: passing argument 1 of ‘PyString_FromString’ makes pointer from integer without a cast _mysql.c: In function ‘_mysql_server_init’: _mysql.c:308: warning: label ‘finish’ defined but not used _mysql.c:234: warning: unused variable ‘item’ _mysql.c:233: warning: unused variable ‘groupc’ _mysql.c:233: warning: unused variable ‘i’ _mysql.c:233: warning: unused variable ‘cmd_argc’ _mysql.c:232: warning: unused variable ‘s’ _mysql.c: In function ‘_mysql_ResultObject_Initialize’: _mysql.c:363: error: ‘MYSQL_RES’ undeclared (first use in this function) _mysql.c:363: error: ‘result’ undeclared (first use in this function) _mysql.c:368: error: ‘MYSQL_FIELD’ undeclared (first use in this function) _mysql.c:368: error: ‘fields’ undeclared (first use in this function) _mysql.c:377: error: ‘_mysql_ResultObject’ has no member named ‘use’ _mysql.c:380: warning: implicit declaration of function ‘mysql_use_result’ _mysql.c:380: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:382: warning: implicit declaration of function ‘mysql_store_result’ _mysql.c:382: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:383: error: ‘_mysql_ResultObject’ has no member named ‘result’ _mysql.c:386: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:389: warning: implicit declaration of function ‘mysql_num_fields’ _mysql.c:390: error: ‘_mysql_ResultObject’ has no member named ‘nfields’ _mysql.c:391: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:392: warning: implicit declaration of function ‘mysql_fetch_fields’ _mysql.c:438: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c: In function ‘_mysql_ResultObject_traverse’: _mysql.c:450: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:451: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c: In function ‘_mysql_ResultObject_clear’: _mysql.c:462: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:462: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:462: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:462: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c:463: error: ‘_mysql_ResultObject’ has no member named ‘converter’ _mysql.c: In function ‘_mysql_ConnectionObject_Initialize’: _mysql.c:475: error: ‘MYSQL’ undeclared (first use in this function) _mysql.c:475: error: ‘conn’ undeclared (first use in this function) _mysql.c:500: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:501: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c:525: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:547: warning: implicit declaration of function ‘mysql_init’ _mysql.c:547: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:550: warning: implicit declaration of function ‘mysql_options’ _mysql.c:550: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:550: error: ‘MYSQL_OPT_CONNECT_TIMEOUT’ undeclared (first use in this function) _mysql.c:554: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:554: error: ‘MYSQL_OPT_COMPRESS’ undeclared (first use in this function) _mysql.c:555: error: ‘CLIENT_COMPRESS’ undeclared (first use in this function) _mysql.c:558: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:558: error: ‘MYSQL_OPT_NAMED_PIPE’ undeclared (first use in this function) _mysql.c:560: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:560: error: ‘MYSQL_INIT_COMMAND’ undeclared (first use in this function) _mysql.c:562: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:562: error: ‘MYSQL_READ_DEFAULT_FILE’ undeclared (first use in this function) _mysql.c:564: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:564: error: ‘MYSQL_READ_DEFAULT_GROUP’ undeclared (first use in this function) _mysql.c:567: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:567: error: ‘MYSQL_OPT_LOCAL_INFILE’ undeclared (first use in this function) _mysql.c:575: warning: implicit declaration of function ‘mysql_real_connect’ _mysql.c:575: error: ‘_mysql_ConnectionObject’ has no member named ‘connection’ _mysql.c:590: error: ‘_mysql_ConnectionObject’ has no member named ‘open’ _mysql.c: In function ‘_mysql_ConnectionObject_traverse’: _mysql.c:671: error: ‘_mysql_ConnectionObject’ has no member named ‘converter’ _mysql.c:

    Read the article

  • Building Awesome WM

    - by Dragan Chupacabrovic
    Hello, I am following these steps in order to build Awesome window manager on 10.04 I am building 3.4 while the tutorial is for 3.1 I installed all of the specified dependencies including cairo. After running cd awesome-3.4 && make I get the following missing dependencies error: Running cmake… -- cat - /bin/cat -- ln - /bin/ln -- grep - /bin/grep -- git - /usr/bin/git -- hostname - /bin/hostname -- gperf - /usr/bin/gperf -- asciidoc - /usr/bin/asciidoc -- xmlto - /usr/bin/xmlto -- gzip - /bin/gzip -- lua - /usr/bin/lua -- luadoc - /usr/bin/luadoc -- convert - /usr/bin/convert -- checking for modules 'glib-2.0;cairo;x11;pango=1.19.3;pangocairo=1.19.3;xcb-randr;xcb-xtest;xcb-xinerama;xcb-shape;xcb-event=0.3.6;xcb-aux=0.3.0;xcb-atom=0.3.0;xcb-keysyms=0.3.4;xcb-icccm=0.3.6;xcb-image=0.3.0;xcb-property=0.3.0;cairo-xcb;libstartup-notification-1.0=0.10;xproto=7.0.15;imlib2;libxdg-basedir=1.0.0' -- package 'xcb-xtest' not found -- package 'xcb-property=0.3.0' not found -- package 'libstartup-notification-1.0=0.10' not found -- package 'libxdg-basedir=1.0.0' not found CMake Error at /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:259 (message): A required package was not found Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindPkgConfig.cmake:311 (_pkg_check_modules_internal) awesomeConfig.cmake:133 (pkg_check_modules) CMakeLists.txt:15 (include) CMake Error at awesomeConfig.cmake:157 (message): Call Stack (most recent call first): CMakeLists.txt:15 (include) -- Configuring incomplete, errors occurred! make: * [cmake] Error 1 I ran sudo apt-get install libxcb-xtest0 libxcb-property1 libxdg-basedir1 libstartup-notification0 but the problem is still there. It is probably because apt-get uses different names for these libraries. Please advise EDIT following enzotib's suggestion, I ran: sudo apt-get install libxcb-xtest0-dev libxcb-property1-dev libxdg-basedir-dev libstartup-notification0-dev and now it looks like I'm missing a library: awesome-3.4$ make Running cmake… -- cat - /bin/cat -- ln - /bin/ln -- grep - /bin/grep -- git - /usr/bin/git -- hostname - /bin/hostname -- gperf - /usr/bin/gperf -- asciidoc - /usr/bin/asciidoc -- xmlto - /usr/bin/xmlto -- gzip - /bin/gzip -- lua - /usr/bin/lua -- luadoc - /usr/bin/luadoc -- convert - /usr/bin/convert -- Configuring lib/naughty.lua -- Configuring lib/awful/tooltip.lua -- Configuring lib/awful/init.lua -- Configuring lib/awful/titlebar.lua -- Configuring lib/awful/key.lua -- Configuring lib/awful/mouse/init.lua -- Configuring lib/awful/mouse/finder.lua -- Configuring lib/awful/autofocus.lua -- Configuring lib/awful/screen.lua -- Configuring lib/awful/rules.lua -- Configuring lib/awful/widget/init.lua -- Configuring lib/awful/widget/taglist.lua -- Configuring lib/awful/widget/graph.lua -- Configuring lib/awful/widget/tasklist.lua -- Configuring lib/awful/widget/common.lua -- Configuring lib/awful/widget/prompt.lua -- Configuring lib/awful/widget/launcher.lua -- Configuring lib/awful/widget/button.lua -- Configuring lib/awful/widget/layoutbox.lua -- Configuring lib/awful/widget/layout/init.lua -- Configuring lib/awful/widget/layout/vertical.lua -- Configuring lib/awful/widget/layout/horizontal.lua -- Configuring lib/awful/widget/layout/default.lua -- Configuring lib/awful/widget/progressbar.lua -- Configuring lib/awful/widget/textclock.lua -- Configuring lib/awful/dbus.lua -- Configuring lib/awful/remote.lua -- Configuring lib/awful/client.lua -- Configuring lib/awful/prompt.lua -- Configuring lib/awful/completion.lua -- Configuring lib/awful/tag.lua -- Configuring lib/awful/util.lua -- Configuring lib/awful/button.lua -- Configuring lib/awful/menu.lua -- Configuring lib/awful/hooks.lua -- Configuring lib/awful/wibox.lua -- Configuring lib/awful/layout/init.lua -- Configuring lib/awful/layout/suit/init.lua -- Configuring lib/awful/layout/suit/floating.lua -- Configuring lib/awful/layout/suit/fair.lua -- Configuring lib/awful/layout/suit/spiral.lua -- Configuring lib/awful/layout/suit/magnifier.lua -- Configuring lib/awful/layout/suit/tile.lua -- Configuring lib/awful/layout/suit/max.lua -- Configuring lib/awful/placement.lua -- Configuring lib/awful/startup_notification.lua -- Configuring lib/beautiful.lua -- Configuring themes/zenburn//theme.lua -- Configuring themes/default//theme.lua -- Configuring themes/sky//theme.lua -- Configuring config.h -- Configuring awesomerc.lua -- Configuring awesome-version-internal.h -- Configuring awesome.doxygen -- Configuring done -- Generating done -- Build files have been written to: /home/druden/util/awesome-3.4/.build-vedroid-i486-linux-gnu-4.4.3 Running make Makefile… Building… [ 4%] Built target generated_sources [ 5%] Building C object CMakeFiles/awesome.dir/awesome.c.o In file included from /home/druden/util/awesome-3.4/spawn.h:25, from /home/druden/util/awesome-3.4/awesome.c:33: /home/druden/util/awesome-3.4/globalconf.h:57: error: expected specifier-qualifier-list before ‘xcb_event_handlers_t’ In file included from /home/druden/util/awesome-3.4/awesome.c:34: /home/druden/util/awesome-3.4/client.h: In function ‘client_stack’: /home/druden/util/awesome-3.4/client.h:212: error: ‘awesome_t’ has no member named ‘client_need_stack_refresh’ /home/druden/util/awesome-3.4/client.h: In function ‘client_raise’: /home/druden/util/awesome-3.4/client.h:227: error: ‘awesome_t’ has no member named ‘stack’ In file included from /home/druden/util/awesome-3.4/awesome.c:42: /home/druden/util/awesome-3.4/titlebar.h: In function ‘titlebar_update_geometry’: /home/druden/util/awesome-3.4/titlebar.h:150: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/titlebar.h:151: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/titlebar.h:152: error: ‘awesome_t’ has no member named ‘L’ In file included from /home/druden/util/awesome-3.4/awesome.c:47: /home/druden/util/awesome-3.4/common/xutil.h: In function ‘xutil_get_text_property_from_reply’: /home/druden/util/awesome-3.4/common/xutil.h:39: warning: ‘STRING’ is deprecated (declared at /usr/local/include/xcb/xcb_atom.h:83) /home/druden/util/awesome-3.4/common/xutil.h: At top level: /home/druden/util/awesome-3.4/common/xutil.h:60: error: expected ‘)’ before ‘*’ token /home/druden/util/awesome-3.4/awesome.c: In function ‘awesome_atexit’: /home/druden/util/awesome-3.4/awesome.c:65: error: ‘awesome_t’ has no member named ‘hooks’ /home/druden/util/awesome-3.4/awesome.c:66: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/awesome.c:66: error: ‘awesome_t’ has no member named ‘hooks’ /home/druden/util/awesome-3.4/awesome.c:68: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/awesome.c:73: error: ‘awesome_t’ has no member named ‘embedded’ /home/druden/util/awesome-3.4/awesome.c:76: error: ‘awesome_t’ has no member named ‘embedded’ /home/druden/util/awesome-3.4/awesome.c:77: error: ‘awesome_t’ has no member named ‘embedded’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: warning: type defaults to ‘int’ in declaration of ‘c’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:91: error: invalid type argument of ‘unary *’ (have ‘int’) /home/druden/util/awesome-3.4/awesome.c:92: error: invalid type argument of ‘unary *’ (have ‘int’) /home/druden/util/awesome-3.4/awesome.c:96: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/awesome.c: In function ‘a_xcb_check_cb’: /home/druden/util/awesome-3.4/awesome.c:223: warning: implicit declaration of function ‘xcb_event_handle’ /home/druden/util/awesome-3.4/awesome.c:223: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:230: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c: In function ‘awesome_restart’: /home/druden/util/awesome-3.4/awesome.c:277: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c: In function ‘xerror’: /home/druden/util/awesome-3.4/awesome.c:305: error: ‘XCB_EVENT_ERROR_BAD_WINDOW’ undeclared (first use in this function) /home/druden/util/awesome-3.4/awesome.c:305: error: (Each undeclared identifier is reported only once /home/druden/util/awesome-3.4/awesome.c:305: error: for each function it appears in.) /home/druden/util/awesome-3.4/awesome.c:306: error: ‘XCB_EVENT_ERROR_BAD_MATCH’ undeclared (first use in this function) /home/druden/util/awesome-3.4/awesome.c:308: error: ‘XCB_EVENT_ERROR_BAD_VALUE’ undeclared (first use in this function) /home/druden/util/awesome-3.4/awesome.c: In function ‘main’: /home/druden/util/awesome-3.4/awesome.c:369: error: ‘awesome_t’ has no member named ‘keygrabber’ /home/druden/util/awesome-3.4/awesome.c:370: error: ‘awesome_t’ has no member named ‘mousegrabber’ /home/druden/util/awesome-3.4/awesome.c:376: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:377: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:381: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:382: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:424: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:431: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:432: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:433: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:434: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:435: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:436: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:443: error: ‘awesome_t’ has no member named ‘default_screen’ /home/druden/util/awesome-3.4/awesome.c:450: error: ‘awesome_t’ has no member named ‘have_xtest’ /home/druden/util/awesome-3.4/awesome.c:462: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:464: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:465: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:467: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:468: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:471: warning: implicit declaration of function ‘xcb_event_handlers_init’ /home/druden/util/awesome-3.4/awesome.c:471: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:472: warning: implicit declaration of function ‘xutil_error_handler_catch_all_set’ /home/druden/util/awesome-3.4/awesome.c:472: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:490: warning: implicit declaration of function ‘xcb_event_poll_for_event_loop’ /home/druden/util/awesome-3.4/awesome.c:490: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:493: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:496: error: ‘awesome_t’ has no member named ‘keysyms’ /home/druden/util/awesome-3.4/awesome.c:507: error: ‘awesome_t’ has no member named ‘colors’ /home/druden/util/awesome-3.4/awesome.c:510: error: ‘awesome_t’ has no member named ‘colors’ /home/druden/util/awesome-3.4/awesome.c:513: error: ‘awesome_t’ has no member named ‘font’ /home/druden/util/awesome-3.4/awesome.c:519: error: ‘awesome_t’ has no member named ‘keysyms’ /home/druden/util/awesome-3.4/awesome.c:519: error: ‘awesome_t’ has no member named ‘numlockmask’ /home/druden/util/awesome-3.4/awesome.c:520: error: ‘awesome_t’ has no member named ‘shiftlockmask’ /home/druden/util/awesome-3.4/awesome.c:520: error: ‘awesome_t’ has no member named ‘capslockmask’ /home/druden/util/awesome-3.4/awesome.c:521: error: ‘awesome_t’ has no member named ‘modeswitchmask’ /home/druden/util/awesome-3.4/awesome.c:563: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:572: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:575: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:576: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:577: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:578: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:579: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:580: error: ‘awesome_t’ has no member named ‘loop’ make[3]: * [CMakeFiles/awesome.dir/awesome.c.o] Error 1 make[2]: [CMakeFiles/awesome.dir/all] Error 2 make[1]: [all] Error 2 make: * [cmake-build] Error 2

    Read the article

  • Ancillary Objects: Separate Debug ELF Files For Solaris

    - by Ali Bahrami
    We introduced a new object ELF object type in Solaris 11 Update 1 called the Ancillary Object. This posting describes them, using material originally written during their development, the PSARC arc case, and the Solaris Linker and Libraries Manual. ELF objects contain allocable sections, which are mapped into memory at runtime, and non-allocable sections, which are present in the file for use by debuggers and observability tools, but which are not mapped or used at runtime. Typically, all of these sections exist within a single object file. Ancillary objects allow them to instead go into a separate file. There are different reasons given for wanting such a feature. One can debate whether the added complexity is worth the benefit, and in most cases it is not. However, one important case stands out — customers with very large 32-bit objects who are not ready or able to make the transition to 64-bits. We have customers who build extremely large 32-bit objects. Historically, the debug sections in these objects have used the stabs format, which is limited, but relatively compact. In recent years, the industry has transitioned to the powerful but verbose DWARF standard. In some cases, the size of these debug sections is large enough to push the total object file size past the fundamental 4GB limit for 32-bit ELF object files. The best, and ultimately only, solution to overly large objects is to transition to 64-bits. However, consider environments where: Hundreds of users may be executing the code on large shared systems. (32-bits use less memory and bus bandwidth, and on sparc runs just as fast as 64-bit code otherwise). Complex finely tuned code, where the original authors may no longer be available. Critical production code, that was expensive to qualify and bring online, and which is otherwise serving its intended purpose without issue. Users in these risk adverse and/or high scale categories have good reasons to push 32-bits objects to the limit before moving on. Ancillary objects offer these users a longer runway. Design The design of ancillary objects is intended to be simple, both to help human understanding when examining elfdump output, and to lower the bar for debuggers such as dbx to support them. The primary and ancillary objects have the same set of section headers, with the same names, in the same order (i.e. each section has the same index in both files). A single added section of type SHT_SUNW_ANCILLARY is added to both objects, containing information that allows a debugger to identify and validate both files relative to each other. Given one of these files, the ancillary section allows you to identify the other. Allocable sections go in the primary object, and non-allocable ones go into the ancillary object. A small set of non-allocable objects, notably the symbol table, are copied into both objects. As noted above, most sections are only written to one of the two objects, but both objects have the same section header array. The section header in the file that does not contain the section data is tagged with the SHF_SUNW_ABSENT section header flag to indicate its placeholder status. Compiler writers and others who produce objects can set the SUNW_SHF_PRIMARY section header flag to mark non-allocable sections that should go to the primary object rather than the ancillary. If you don't request an ancillary object, the Solaris ELF format is unchanged. Users who don't use ancillary objects do not pay for the feature. This is important, because they exist to serve a small subset of our users, and must not complicate the common case. If you do request an ancillary object, the runtime behavior of the primary object will be the same as that of a normal object. There is no added runtime cost. The primary and ancillary object together represent a logical single object. This is facilitated by the use of a single set of section headers. One can easily imagine a tool that can merge a primary and ancillary object into a single file, or the reverse. (Note that although this is an interesting intellectual exercise, we don't actually supply such a tool because there's little practical benefit above and beyond using ld to create the files). Among the benefits of this approach are: There is no need for per-file symbol tables to reflect the contents of each file. The same symbol table that would be produced for a standard object can be used. The section contents are identical in either case — there is no need to alter data to accommodate multiple files. It is very easy for a debugger to adapt to these new files, and the processing involved can be encapsulated in input/output routines. Most of the existing debugger implementation applies without modification. The limit of a 4GB 32-bit output object is now raised to 4GB of code, and 4GB of debug data. There is also the future possibility (not currently supported) to support multiple ancillary objects, each of which could contain up to 4GB of additional debug data. It must be noted however that the 32-bit DWARF debug format is itself inherently 32-bit limited, as it uses 32-bit offsets between debug sections, so the ability to employ multiple ancillary object files may not turn out to be useful. Using Ancillary Objects (From the Solaris Linker and Libraries Guide) By default, objects contain both allocable and non-allocable sections. Allocable sections are the sections that contain executable code and the data needed by that code at runtime. Non-allocable sections contain supplemental information that is not required to execute an object at runtime. These sections support the operation of debuggers and other observability tools. The non-allocable sections in an object are not loaded into memory at runtime by the operating system, and so, they have no impact on memory use or other aspects of runtime performance no matter their size. For convenience, both allocable and non-allocable sections are normally maintained in the same file. However, there are situations in which it can be useful to separate these sections. To reduce the size of objects in order to improve the speed at which they can be copied across wide area networks. To support fine grained debugging of highly optimized code requires considerable debug data. In modern systems, the debugging data can easily be larger than the code it describes. The size of a 32-bit object is limited to 4 Gbytes. In very large 32-bit objects, the debug data can cause this limit to be exceeded and prevent the creation of the object. To limit the exposure of internal implementation details. Traditionally, objects have been stripped of non-allocable sections in order to address these issues. Stripping is effective, but destroys data that might be needed later. The Solaris link-editor can instead write non-allocable sections to an ancillary object. This feature is enabled with the -z ancillary command line option. $ ld ... -z ancillary[=outfile] ...By default, the ancillary file is given the same name as the primary output object, with a .anc file extension. However, a different name can be provided by providing an outfile value to the -z ancillary option. When -z ancillary is specified, the link-editor performs the following actions. All allocable sections are written to the primary object. In addition, all non-allocable sections containing one or more input sections that have the SHF_SUNW_PRIMARY section header flag set are written to the primary object. All remaining non-allocable sections are written to the ancillary object. The following non-allocable sections are written to both the primary object and ancillary object. .shstrtab The section name string table. .symtab The full non-dynamic symbol table. .symtab_shndx The symbol table extended index section associated with .symtab. .strtab The non-dynamic string table associated with .symtab. .SUNW_ancillary Contains the information required to identify the primary and ancillary objects, and to identify the object being examined. The primary object and all ancillary objects contain the same array of sections headers. Each section has the same section index in every file. Although the primary and ancillary objects all define the same section headers, the data for most sections will be written to a single file as described above. If the data for a section is not present in a given file, the SHF_SUNW_ABSENT section header flag is set, and the sh_size field is 0. This organization makes it possible to acquire a full list of section headers, a complete symbol table, and a complete list of the primary and ancillary objects from either of the primary or ancillary objects. The following example illustrates the underlying implementation of ancillary objects. An ancillary object is created by adding the -z ancillary command line option to an otherwise normal compilation. The file utility shows that the result is an executable named a.out, and an associated ancillary object named a.out.anc. $ cat hello.c #include <stdio.h> int main(int argc, char **argv) { (void) printf("hello, world\n"); return (0); } $ cc -g -zancillary hello.c $ file a.out a.out.anc a.out: ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped, ancillary object a.out.anc a.out.anc: ELF 32-bit LSB ancillary 80386 Version 1, primary object a.out $ ./a.out hello worldThe resulting primary object is an ordinary executable that can be executed in the usual manner. It is no different at runtime than an executable built without the use of ancillary objects, and then stripped of non-allocable content using the strip or mcs commands. As previously described, the primary object and ancillary objects contain the same section headers. To see how this works, it is helpful to use the elfdump utility to display these section headers and compare them. The following table shows the section header information for a selection of headers from the previous link-edit example. Index Section Name Type Primary Flags Ancillary Flags Primary Size Ancillary Size 13 .text PROGBITS ALLOC EXECINSTR ALLOC EXECINSTR SUNW_ABSENT 0x131 0 20 .data PROGBITS WRITE ALLOC WRITE ALLOC SUNW_ABSENT 0x4c 0 21 .symtab SYMTAB 0 0 0x450 0x450 22 .strtab STRTAB STRINGS STRINGS 0x1ad 0x1ad 24 .debug_info PROGBITS SUNW_ABSENT 0 0 0x1a7 28 .shstrtab STRTAB STRINGS STRINGS 0x118 0x118 29 .SUNW_ancillary SUNW_ancillary 0 0 0x30 0x30 The data for most sections is only present in one of the two files, and absent from the other file. The SHF_SUNW_ABSENT section header flag is set when the data is absent. The data for allocable sections needed at runtime are found in the primary object. The data for non-allocable sections used for debugging but not needed at runtime are placed in the ancillary file. A small set of non-allocable sections are fully present in both files. These are the .SUNW_ancillary section used to relate the primary and ancillary objects together, the section name string table .shstrtab, as well as the symbol table.symtab, and its associated string table .strtab. It is possible to strip the symbol table from the primary object. A debugger that encounters an object without a symbol table can use the .SUNW_ancillary section to locate the ancillary object, and access the symbol contained within. The primary object, and all associated ancillary objects, contain a .SUNW_ancillary section that allows all the objects to be identified and related together. $ elfdump -T SUNW_ancillary a.out a.out.anc a.out: Ancillary Section: .SUNW_ancillary index tag value [0] ANC_SUNW_CHECKSUM 0x8724 [1] ANC_SUNW_MEMBER 0x1 a.out [2] ANC_SUNW_CHECKSUM 0x8724 [3] ANC_SUNW_MEMBER 0x1a3 a.out.anc [4] ANC_SUNW_CHECKSUM 0xfbe2 [5] ANC_SUNW_NULL 0 a.out.anc: Ancillary Section: .SUNW_ancillary index tag value [0] ANC_SUNW_CHECKSUM 0xfbe2 [1] ANC_SUNW_MEMBER 0x1 a.out [2] ANC_SUNW_CHECKSUM 0x8724 [3] ANC_SUNW_MEMBER 0x1a3 a.out.anc [4] ANC_SUNW_CHECKSUM 0xfbe2 [5] ANC_SUNW_NULL 0 The ancillary sections for both objects contain the same number of elements, and are identical except for the first element. Each object, starting with the primary object, is introduced with a MEMBER element that gives the file name, followed by a CHECKSUM that identifies the object. In this example, the primary object is a.out, and has a checksum of 0x8724. The ancillary object is a.out.anc, and has a checksum of 0xfbe2. The first element in a .SUNW_ancillary section, preceding the MEMBER element for the primary object, is always a CHECKSUM element, containing the checksum for the file being examined. The presence of a .SUNW_ancillary section in an object indicates that the object has associated ancillary objects. The names of the primary and all associated ancillary objects can be obtained from the ancillary section from any one of the files. It is possible to determine which file is being examined from the larger set of files by comparing the first checksum value to the checksum of each member that follows. Debugger Access and Use of Ancillary Objects Debuggers and other observability tools must merge the information found in the primary and ancillary object files in order to build a complete view of the object. This is equivalent to processing the information from a single file. This merging is simplified by the primary object and ancillary objects containing the same section headers, and a single symbol table. The following steps can be used by a debugger to assemble the information contained in these files. Starting with the primary object, or any of the ancillary objects, locate the .SUNW_ancillary section. The presence of this section identifies the object as part of an ancillary group, contains information that can be used to obtain a complete list of the files and determine which of those files is the one currently being examined. Create a section header array in memory, using the section header array from the object being examined as an initial template. Open and read each file identified by the .SUNW_ancillary section in turn. For each file, fill in the in-memory section header array with the information for each section that does not have the SHF_SUNW_ABSENT flag set. The result will be a complete in-memory copy of the section headers with pointers to the data for all sections. Once this information has been acquired, the debugger can proceed as it would in the single file case, to access and control the running program. Note - The ELF definition of ancillary objects provides for a single primary object, and an arbitrary number of ancillary objects. At this time, the Oracle Solaris link-editor only produces a single ancillary object containing all non-allocable sections. This may change in the future. Debuggers and other observability tools should be written to handle the general case of multiple ancillary objects. ELF Implementation Details (From the Solaris Linker and Libraries Guide) To implement ancillary objects, it was necessary to extend the ELF format to add a new object type (ET_SUNW_ANCILLARY), a new section type (SHT_SUNW_ANCILLARY), and 2 new section header flags (SHF_SUNW_ABSENT, SHF_SUNW_PRIMARY). In this section, I will detail these changes, in the form of diffs to the Solaris Linker and Libraries manual. Part IV ELF Application Binary Interface Chapter 13: Object File Format Object File Format Edit Note: This existing section at the beginning of the chapter describes the ELF header. There's a table of object file types, which now includes the new ET_SUNW_ANCILLARY type. e_type Identifies the object file type, as listed in the following table. NameValueMeaning ET_NONE0No file type ET_REL1Relocatable file ET_EXEC2Executable file ET_DYN3Shared object file ET_CORE4Core file ET_LOSUNW0xfefeStart operating system specific range ET_SUNW_ANCILLARY0xfefeAncillary object file ET_HISUNW0xfefdEnd operating system specific range ET_LOPROC0xff00Start processor-specific range ET_HIPROC0xffffEnd processor-specific range Sections Edit Note: This overview section defines the section header structure, and provides a high level description of known sections. It was updated to define the new SHF_SUNW_ABSENT and SHF_SUNW_PRIMARY flags and the new SHT_SUNW_ANCILLARY section. ... sh_type Categorizes the section's contents and semantics. Section types and their descriptions are listed in Table 13-5. sh_flags Sections support 1-bit flags that describe miscellaneous attributes. Flag definitions are listed in Table 13-8. ... Table 13-5 ELF Section Types, sh_type NameValue . . . SHT_LOSUNW0x6fffffee SHT_SUNW_ancillary0x6fffffee . . . ... SHT_LOSUNW - SHT_HISUNW Values in this inclusive range are reserved for Oracle Solaris OS semantics. SHT_SUNW_ANCILLARY Present when a given object is part of a group of ancillary objects. Contains information required to identify all the files that make up the group. See Ancillary Section. ... Table 13-8 ELF Section Attribute Flags NameValue . . . SHF_MASKOS0x0ff00000 SHF_SUNW_NODISCARD0x00100000 SHF_SUNW_ABSENT0x00200000 SHF_SUNW_PRIMARY0x00400000 SHF_MASKPROC0xf0000000 . . . ... SHF_SUNW_ABSENT Indicates that the data for this section is not present in this file. When ancillary objects are created, the primary object and any ancillary objects, will all have the same section header array, to facilitate merging them to form a complete view of the object, and to allow them to use the same symbol tables. Each file contains a subset of the section data. The data for allocable sections is written to the primary object while the data for non-allocable sections is written to an ancillary file. The SHF_SUNW_ABSENT flag is used to indicate that the data for the section is not present in the object being examined. When the SHF_SUNW_ABSENT flag is set, the sh_size field of the section header must be 0. An application encountering an SHF_SUNW_ABSENT section can choose to ignore the section, or to search for the section data within one of the related ancillary files. SHF_SUNW_PRIMARY The default behavior when ancillary objects are created is to write all allocable sections to the primary object and all non-allocable sections to the ancillary objects. The SHF_SUNW_PRIMARY flag overrides this behavior. Any output section containing one more input section with the SHF_SUNW_PRIMARY flag set is written to the primary object without regard for its allocable status. ... Two members in the section header, sh_link, and sh_info, hold special information, depending on section type. Table 13-9 ELF sh_link and sh_info Interpretation sh_typesh_linksh_info . . . SHT_SUNW_ANCILLARY The section header index of the associated string table. 0 . . . Special Sections Edit Note: This section describes the sections used in Solaris ELF objects, using the types defined in the previous description of section types. It was updated to define the new .SUNW_ancillary (SHT_SUNW_ANCILLARY) section. Various sections hold program and control information. Sections in the following table are used by the system and have the indicated types and attributes. Table 13-10 ELF Special Sections NameTypeAttribute . . . .SUNW_ancillarySHT_SUNW_ancillaryNone . . . ... .SUNW_ancillary Present when a given object is part of a group of ancillary objects. Contains information required to identify all the files that make up the group. See Ancillary Section for details. ... Ancillary Section Edit Note: This new section provides the format reference describing the layout of a .SUNW_ancillary section and the meaning of the various tags. Note that these sections use the same tag/value concept used for dynamic and capabilities sections, and will be familiar to anyone used to working with ELF. In addition to the primary output object, the Solaris link-editor can produce one or more ancillary objects. Ancillary objects contain non-allocable sections that would normally be written to the primary object. When ancillary objects are produced, the primary object and all of the associated ancillary objects contain a SHT_SUNW_ancillary section, containing information that identifies these related objects. Given any one object from such a group, the ancillary section provides the information needed to identify and interpret the others. This section contains an array of the following structures. See sys/elf.h. typedef struct { Elf32_Word a_tag; union { Elf32_Word a_val; Elf32_Addr a_ptr; } a_un; } Elf32_Ancillary; typedef struct { Elf64_Xword a_tag; union { Elf64_Xword a_val; Elf64_Addr a_ptr; } a_un; } Elf64_Ancillary; For each object with this type, a_tag controls the interpretation of a_un. a_val These objects represent integer values with various interpretations. a_ptr These objects represent file offsets or addresses. The following ancillary tags exist. Table 13-NEW1 ELF Ancillary Array Tags NameValuea_un ANC_SUNW_NULL0Ignored ANC_SUNW_CHECKSUM1a_val ANC_SUNW_MEMBER2a_ptr ANC_SUNW_NULL Marks the end of the ancillary section. ANC_SUNW_CHECKSUM Provides the checksum for a file in the c_val element. When ANC_SUNW_CHECKSUM precedes the first instance of ANC_SUNW_MEMBER, it provides the checksum for the object from which the ancillary section is being read. When it follows an ANC_SUNW_MEMBER tag, it provides the checksum for that member. ANC_SUNW_MEMBER Specifies an object name. The a_ptr element contains the string table offset of a null-terminated string, that provides the file name. An ancillary section must always contain an ANC_SUNW_CHECKSUM before the first instance of ANC_SUNW_MEMBER, identifying the current object. Following that, there should be an ANC_SUNW_MEMBER for each object that makes up the complete set of objects. Each ANC_SUNW_MEMBER should be followed by an ANC_SUNW_CHECKSUM for that object. A typical ancillary section will therefore be structured as: TagMeaning ANC_SUNW_CHECKSUMChecksum of this object ANC_SUNW_MEMBERName of object #1 ANC_SUNW_CHECKSUMChecksum for object #1 . . . ANC_SUNW_MEMBERName of object N ANC_SUNW_CHECKSUMChecksum for object N ANC_SUNW_NULL An object can therefore identify itself by comparing the initial ANC_SUNW_CHECKSUM to each of the ones that follow, until it finds a match. Related Other Work The GNU developers have also encountered the need/desire to support separate debug information files, and use the solution detailed at http://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html. At the current time, the separate debug file is constructed by building the standard object first, and then copying the debug data out of it in a separate post processing step, Hence, it is limited to a total of 4GB of code and debug data, just as a single object file would be. They are aware of this, and I have seen online comments indicating that they may add direct support for generating these separate files to their link-editor. It is worth noting that the GNU objcopy utility is available on Solaris, and that the Studio dbx debugger is able to use these GNU style separate debug files even on Solaris. Although this is interesting in terms giving Linux users a familiar environment on Solaris, the 4GB limit means it is not an answer to the problem of very large 32-bit objects. We have also encountered issues with objcopy not understanding Solaris-specific ELF sections, when using this approach. The GNU community also has a current effort to adapt their DWARF debug sections in order to move them to separate files before passing the relocatable objects to the linker. The details of Project Fission can be found at http://gcc.gnu.org/wiki/DebugFission. The goal of this project appears to be to reduce the amount of data seen by the link-editor. The primary effort revolves around moving DWARF data to separate .dwo files so that the link-editor never encounters them. The details of modifying the DWARF data to be usable in this form are involved — please see the above URL for details.

    Read the article

  • C++: calling non-member functions with the same syntax of member ones

    - by peoro
    One thing I'd like to do in C++ is to call non-member functions with the same syntax you call member functions: class A { }; void f( A & this ) { /* ... */ } // ... A a; a.f(); // this is the same as f(a); Of course this could only work as long as f is not virtual (since it cannot appear in A's virtual table. f doesn't need to access A's non-public members. f doesn't conflict with a function declared in A (A::f). I'd like such a syntax because in my opinion it would be quite comfortable and would push good habits: calling str.strip() on a std::string (where strip is a function defined by the user) would sound a lot better than calling strip( str );. most of the times (always?) classes provide some member functions which don't require to be member (ie: are not virtual and don't use non-public members). This breaks encapsulation, but is the most practical thing to do (due to point 1). My question here is: what do you think of such feature? Do you think it would be something nice, or something that would introduce more issues than the ones it aims to solve? Could it make sense to propose such a feature to the next standard (the one after C++0x)? Of course this is just a brief description of this idea; it is not complete; we'd probably need to explicitly mark a function with a special keyword to let it work like this and many other stuff.

    Read the article

  • Architecture Best Practice (MVC): Repository Returns Object & Object Member Accessed Directly or Repository Returns Object Member

    - by coderabbi
    Architecturally speaking, which is the preferable approach (and why)? $validation_date = $users_repository->getUser($user_id)->validation_date; Seems to violate Law of Demeter by accessing member of object returned by method call Seems to violate Encapsulation by accessing object member directly $validation_date = $users_repository->getUserValidationDate($user_id); Seems to violate Single Responsibility Principle as $users_repository no longer just returns User objects

    Read the article

  • Building Awesome WM

    - by Dragan Chupacabrovic
    Hello, I am following these steps in order to build Awesome window manager on 10.04 I am building 3.4 while the tutorial is for 3.1 I installed all of the specified dependencies including cairo. EDIT I ran: sudo apt-get install libxcb-xtest0-dev libxcb-property1-dev libxdg-basedir-dev libstartup-notification0-dev and now it looks like I'm missing a library Please advise: awesome-3.4$ make Running cmake… -- cat - /bin/cat -- ln - /bin/ln -- grep - /bin/grep -- git - /usr/bin/git -- hostname - /bin/hostname -- gperf - /usr/bin/gperf -- asciidoc - /usr/bin/asciidoc -- xmlto - /usr/bin/xmlto -- gzip - /bin/gzip -- lua - /usr/bin/lua -- luadoc - /usr/bin/luadoc -- convert - /usr/bin/convert -- Configuring lib/naughty.lua -- Configuring lib/awful/tooltip.lua -- Configuring lib/awful/init.lua -- Configuring lib/awful/titlebar.lua -- Configuring lib/awful/key.lua -- Configuring lib/awful/mouse/init.lua -- Configuring lib/awful/mouse/finder.lua -- Configuring lib/awful/autofocus.lua -- Configuring lib/awful/screen.lua -- Configuring lib/awful/rules.lua -- Configuring lib/awful/widget/init.lua -- Configuring lib/awful/widget/taglist.lua -- Configuring lib/awful/widget/graph.lua -- Configuring lib/awful/widget/tasklist.lua -- Configuring lib/awful/widget/common.lua -- Configuring lib/awful/widget/prompt.lua -- Configuring lib/awful/widget/launcher.lua -- Configuring lib/awful/widget/button.lua -- Configuring lib/awful/widget/layoutbox.lua -- Configuring lib/awful/widget/layout/init.lua -- Configuring lib/awful/widget/layout/vertical.lua -- Configuring lib/awful/widget/layout/horizontal.lua -- Configuring lib/awful/widget/layout/default.lua -- Configuring lib/awful/widget/progressbar.lua -- Configuring lib/awful/widget/textclock.lua -- Configuring lib/awful/dbus.lua -- Configuring lib/awful/remote.lua -- Configuring lib/awful/client.lua -- Configuring lib/awful/prompt.lua -- Configuring lib/awful/completion.lua -- Configuring lib/awful/tag.lua -- Configuring lib/awful/util.lua -- Configuring lib/awful/button.lua -- Configuring lib/awful/menu.lua -- Configuring lib/awful/hooks.lua -- Configuring lib/awful/wibox.lua -- Configuring lib/awful/layout/init.lua -- Configuring lib/awful/layout/suit/init.lua -- Configuring lib/awful/layout/suit/floating.lua -- Configuring lib/awful/layout/suit/fair.lua -- Configuring lib/awful/layout/suit/spiral.lua -- Configuring lib/awful/layout/suit/magnifier.lua -- Configuring lib/awful/layout/suit/tile.lua -- Configuring lib/awful/layout/suit/max.lua -- Configuring lib/awful/placement.lua -- Configuring lib/awful/startup_notification.lua -- Configuring lib/beautiful.lua -- Configuring themes/zenburn//theme.lua -- Configuring themes/default//theme.lua -- Configuring themes/sky//theme.lua -- Configuring config.h -- Configuring awesomerc.lua -- Configuring awesome-version-internal.h -- Configuring awesome.doxygen -- Configuring done -- Generating done -- Build files have been written to: /home/druden/util/awesome-3.4/.build-vedroid-i486-linux-gnu-4.4.3 Running make Makefile… Building… [ 4%] Built target generated_sources [ 5%] Building C object CMakeFiles/awesome.dir/awesome.c.o In file included from /home/druden/util/awesome-3.4/spawn.h:25, from /home/druden/util/awesome-3.4/awesome.c:33: /home/druden/util/awesome-3.4/globalconf.h:57: error: expected specifier-qualifier-list before ‘xcb_event_handlers_t’ In file included from /home/druden/util/awesome-3.4/awesome.c:34: /home/druden/util/awesome-3.4/client.h: In function ‘client_stack’: /home/druden/util/awesome-3.4/client.h:212: error: ‘awesome_t’ has no member named ‘client_need_stack_refresh’ /home/druden/util/awesome-3.4/client.h: In function ‘client_raise’: /home/druden/util/awesome-3.4/client.h:227: error: ‘awesome_t’ has no member named ‘stack’ In file included from /home/druden/util/awesome-3.4/awesome.c:42: /home/druden/util/awesome-3.4/titlebar.h: In function ‘titlebar_update_geometry’: /home/druden/util/awesome-3.4/titlebar.h:150: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/titlebar.h:151: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/titlebar.h:152: error: ‘awesome_t’ has no member named ‘L’ In file included from /home/druden/util/awesome-3.4/awesome.c:47: /home/druden/util/awesome-3.4/common/xutil.h: In function ‘xutil_get_text_property_from_reply’: /home/druden/util/awesome-3.4/common/xutil.h:39: warning: ‘STRING’ is deprecated (declared at /usr/local/include/xcb/xcb_atom.h:83) /home/druden/util/awesome-3.4/common/xutil.h: At top level: /home/druden/util/awesome-3.4/common/xutil.h:60: error: expected ‘)’ before ‘*’ token /home/druden/util/awesome-3.4/awesome.c: In function ‘awesome_atexit’: /home/druden/util/awesome-3.4/awesome.c:65: error: ‘awesome_t’ has no member named ‘hooks’ /home/druden/util/awesome-3.4/awesome.c:66: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/awesome.c:66: error: ‘awesome_t’ has no member named ‘hooks’ /home/druden/util/awesome-3.4/awesome.c:68: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/awesome.c:73: error: ‘awesome_t’ has no member named ‘embedded’ /home/druden/util/awesome-3.4/awesome.c:76: error: ‘awesome_t’ has no member named ‘embedded’ /home/druden/util/awesome-3.4/awesome.c:77: error: ‘awesome_t’ has no member named ‘embedded’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: warning: type defaults to ‘int’ in declaration of ‘c’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:91: error: invalid type argument of ‘unary *’ (have ‘int’) /home/druden/util/awesome-3.4/awesome.c:92: error: invalid type argument of ‘unary *’ (have ‘int’) /home/druden/util/awesome-3.4/awesome.c:96: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/awesome.c: In function ‘a_xcb_check_cb’: /home/druden/util/awesome-3.4/awesome.c:223: warning: implicit declaration of function ‘xcb_event_handle’ /home/druden/util/awesome-3.4/awesome.c:223: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:230: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c: In function ‘awesome_restart’: /home/druden/util/awesome-3.4/awesome.c:277: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c: In function ‘xerror’: /home/druden/util/awesome-3.4/awesome.c:305: error: ‘XCB_EVENT_ERROR_BAD_WINDOW’ undeclared (first use in this function) /home/druden/util/awesome-3.4/awesome.c:305: error: (Each undeclared identifier is reported only once /home/druden/util/awesome-3.4/awesome.c:305: error: for each function it appears in.) /home/druden/util/awesome-3.4/awesome.c:306: error: ‘XCB_EVENT_ERROR_BAD_MATCH’ undeclared (first use in this function) /home/druden/util/awesome-3.4/awesome.c:308: error: ‘XCB_EVENT_ERROR_BAD_VALUE’ undeclared (first use in this function) /home/druden/util/awesome-3.4/awesome.c: In function ‘main’: /home/druden/util/awesome-3.4/awesome.c:369: error: ‘awesome_t’ has no member named ‘keygrabber’ /home/druden/util/awesome-3.4/awesome.c:370: error: ‘awesome_t’ has no member named ‘mousegrabber’ /home/druden/util/awesome-3.4/awesome.c:376: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:377: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:381: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:382: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:424: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:431: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:432: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:433: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:434: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:435: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:436: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:443: error: ‘awesome_t’ has no member named ‘default_screen’ /home/druden/util/awesome-3.4/awesome.c:450: error: ‘awesome_t’ has no member named ‘have_xtest’ /home/druden/util/awesome-3.4/awesome.c:462: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:464: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:465: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:467: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:468: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:471: warning: implicit declaration of function ‘xcb_event_handlers_init’ /home/druden/util/awesome-3.4/awesome.c:471: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:472: warning: implicit declaration of function ‘xutil_error_handler_catch_all_set’ /home/druden/util/awesome-3.4/awesome.c:472: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:490: warning: implicit declaration of function ‘xcb_event_poll_for_event_loop’ /home/druden/util/awesome-3.4/awesome.c:490: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:493: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:496: error: ‘awesome_t’ has no member named ‘keysyms’ /home/druden/util/awesome-3.4/awesome.c:507: error: ‘awesome_t’ has no member named ‘colors’ /home/druden/util/awesome-3.4/awesome.c:510: error: ‘awesome_t’ has no member named ‘colors’ /home/druden/util/awesome-3.4/awesome.c:513: error: ‘awesome_t’ has no member named ‘font’ /home/druden/util/awesome-3.4/awesome.c:519: error: ‘awesome_t’ has no member named ‘keysyms’ /home/druden/util/awesome-3.4/awesome.c:519: error: ‘awesome_t’ has no member named ‘numlockmask’ /home/druden/util/awesome-3.4/awesome.c:520: error: ‘awesome_t’ has no member named ‘shiftlockmask’ /home/druden/util/awesome-3.4/awesome.c:520: error: ‘awesome_t’ has no member named ‘capslockmask’ /home/druden/util/awesome-3.4/awesome.c:521: error: ‘awesome_t’ has no member named ‘modeswitchmask’ /home/druden/util/awesome-3.4/awesome.c:563: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:572: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:575: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:576: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:577: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:578: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:579: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:580: error: ‘awesome_t’ has no member named ‘loop’ make[3]: * [CMakeFiles/awesome.dir/awesome.c.o] Error 1 make[2]: [CMakeFiles/awesome.dir/all] Error 2 make[1]: [all] Error 2 make: * [cmake-build] Error 2

    Read the article

  • Much Ado About Nothing: Stub Objects

    - by user9154181
    The Solaris 11 link-editor (ld) contains support for a new type of object that we call a stub object. A stub object is a shared object, built entirely from mapfiles, that supplies the same linking interface as the real object, while containing no code or data. Stub objects cannot be executed — the runtime linker will kill any process that attempts to load one. However, you can link to a stub object as a dependency, allowing the stub to act as a proxy for the real version of the object. You may well wonder if there is a point to producing an object that contains nothing but linking interface. As it turns out, stub objects are very useful for building large bodies of code such as Solaris. In the last year, we've had considerable success in applying them to one of our oldest and thorniest build problems. In this discussion, I will describe how we came to invent these objects, and how we apply them to building Solaris. This posting explains where the idea for stub objects came from, and details our long and twisty journey from hallway idea to standard link-editor feature. I expect that these details are mainly of interest to those who work on Solaris and its makefiles, those who have done so in the past, and those who work with other similar bodies of code. A subsequent posting will omit the history and background details, and instead discuss how to build and use stub objects. If you are mainly interested in what stub objects are, and don't care about the underlying software war stories, I encourage you to skip ahead. The Long Road To Stubs This all started for me with an email discussion in May of 2008, regarding a change request that was filed in 2002, entitled: 4631488 lib/Makefile is too patient: .WAITs should be reduced This CR encapsulates a number of cronic issues with Solaris builds: We build Solaris with a parallel make (dmake) that tries to build as much of the code base in parallel as possible. There is a lot of code to build, and we've long made use of parallelized builds to get the job done quicker. This is even more important in today's world of massively multicore hardware. Solaris contains a large number of executables and shared objects. Executables depend on shared objects, and shared objects can depend on each other. Before you can build an object, you need to ensure that the objects it needs have been built. This implies a need for serialization, which is in direct opposition to the desire to build everying in parallel. To accurately build objects in the right order requires an accurate set of make rules defining the things that depend on each other. This sounds simple, but the reality is quite complex. In practice, having programmers explicitly specify these dependencies is a losing strategy: It's really hard to get right. It's really easy to get it wrong and never know it because things build anyway. Even if you get it right, it won't stay that way, because dependencies between objects can change over time, and make cannot help you detect such drifing. You won't know that you got it wrong until the builds break. That can be a long time after the change that triggered the breakage happened, making it hard to connect the cause and the effect. Usually this happens just before a release, when the pressure is on, its hard to think calmly, and there is no time for deep fixes. As a poor compromise, the libraries in core Solaris were built using a set of grossly incomplete hand written rules, supplemented with a number of dmake .WAIT directives used to group the libraries into sets of non-interacting groups that can be built in parallel because we think they don't depend on each other. From time to time, someone will suggest that we could analyze the built objects themselves to determine their dependencies and then generate make rules based on those relationships. This is possible, but but there are complications that limit the usefulness of that approach: To analyze an object, you have to build it first. This is a classic chicken and egg scenario. You could analyze the results of a previous build, but then you're not necessarily going to get accurate rules for the current code. It should be possible to build the code without having a built workspace available. The analysis will take time, and remember that we're constantly trying to make builds faster, not slower. By definition, such an approach will always be approximate, and therefore only incremantally more accurate than the hand written rules described above. The hand written rules are fast and cheap, while this idea is slow and complex, so we stayed with the hand written approach. Solaris was built that way, essentially forever, because these are genuinely difficult problems that had no easy answer. The makefiles were full of build races in which the right outcomes happened reliably for years until a new machine or a change in build server workload upset the accidental balance of things. After figuring out what had happened, you'd mutter "How did that ever work?", add another incomplete and soon to be inaccurate make dependency rule to the system, and move on. This was not a satisfying solution, as we tend to be perfectionists in the Solaris group, but we didn't have a better answer. It worked well enough, approximately. And so it went for years. We needed a different approach — a new idea to cut the Gordian Knot. In that discussion from May 2008, my fellow linker-alien Rod Evans had the initial spark that lead us to a game changing series of realizations: The link-editor is used to link objects together, but it only uses the ELF metadata in the object, consisting of symbol tables, ELF versioning sections, and similar data. Notably, it does not look at, or understand, the machine code that makes an object useful at runtime. If you had an object that only contained the ELF metadata for a dependency, but not the code or data, the link-editor would find it equally useful for linking, and would never know the difference. Call it a stub object. In the core Solaris OS, we require all objects to be built with a link-editor mapfile that describes all of its publically available functions and data. Could we build a stub object using the mapfile for the real object? It ought to be very fast to build stub objects, as there are no input objects to process. Unlike the real object, stub objects would not actually require any dependencies, and so, all of the stubs for the entire system could be built in parallel. When building the real objects, one could link against the stub objects instead of the real dependencies. This means that all the real objects can be built built in parallel too, without any serialization. We could replace a system that requires perfect makefile rules with a system that requires no ordering rules whatsoever. The results would be considerably more robust. We immediately realized that this idea had potential, but also that there were many details to sort out, lots of work to do, and that perhaps it wouldn't really pan out. As is often the case, it would be necessary to do the work and see how it turned out. Following that conversation, I set about trying to build a stub object. We determined that a faithful stub has to do the following: Present the same set of global symbols, with the same ELF versioning, as the real object. Functions are simple — it suffices to have a symbol of the right type, possibly, but not necessarily, referencing a null function in its text segment. Copy relocations make data more complicated to stub. The possibility of a copy relocation means that when you create a stub, the data symbols must have the actual size of the real data. Any error in this will go uncaught at link time, and will cause tragic failures at runtime that are very hard to diagnose. For reasons too obscure to go into here, involving tentative symbols, it is also important that the data reside in bss, or not, matching its placement in the real object. If the real object has more than one symbol pointing at the same data item, we call these aliased symbols. All data symbols in the stub object must exhibit the same aliasing as the real object. We imagined the stub library feature working as follows: A command line option to ld tells it to produce a stub rather than a real object. In this mode, only mapfiles are examined, and any object or shared libraries on the command line are are ignored. The extra information needed (function or data, size, and bss details) would be added to the mapfile. When building the real object instead of the stub, the extra information for building stubs would be validated against the resulting object to ensure that they match. In exploring these ideas, I immediately run headfirst into the reality of the original mapfile syntax, a subject that I would later write about as The Problem(s) With Solaris SVR4 Link-Editor Mapfiles. The idea of extending that poor language was a non-starter. Until a better mapfile syntax became available, which seemed unlikely in 2008, the solution could not involve extentions to the mapfile syntax. Instead, we cooked up the idea (hack) of augmenting mapfiles with stylized comments that would carry the necessary information. A typical definition might look like: # DATA(i386) __iob 0x3c0 # DATA(amd64,sparcv9) __iob 0xa00 # DATA(sparc) __iob 0x140 iob; A further problem then became clear: If we can't extend the mapfile syntax, then there's no good way to extend ld with an option to produce stub objects, and to validate them against the real objects. The idea of having ld read comments in a mapfile and parse them for content is an unacceptable hack. The entire point of comments is that they are strictly for the human reader, and explicitly ignored by the tool. Taking all of these speed bumps into account, I made a new plan: A perl script reads the mapfiles, generates some small C glue code to produce empty functions and data definitions, compiles and links the stub object from the generated glue code, and then deletes the generated glue code. Another perl script used after both objects have been built, to compare the real and stub objects, using data from elfdump, and validate that they present the same linking interface. By June 2008, I had written the above, and generated a stub object for libc. It was a useful prototype process to go through, and it allowed me to explore the ideas at a deep level. Ultimately though, the result was unsatisfactory as a basis for real product. There were so many issues: The use of stylized comments were fine for a prototype, but not close to professional enough for shipping product. The idea of having to document and support it was a large concern. The ideal solution for stub objects really does involve having the link-editor accept the same arguments used to build the real object, augmented with a single extra command line option. Any other solution, such as our prototype script, will require makefiles to be modified in deeper ways to support building stubs, and so, will raise barriers to converting existing code. A validation script that rederives what the linker knew when it built an object will always be at a disadvantage relative to the actual linker that did the work. A stub object should be identifyable as such. In the prototype, there was no tag or other metadata that would let you know that they weren't real objects. Being able to identify a stub object in this way means that the file command can tell you what it is, and that the runtime linker can refuse to try and run a program that loads one. At that point, we needed to apply this prototype to building Solaris. As you might imagine, the task of modifying all the makefiles in the core Solaris code base in order to do this is a massive task, and not something you'd enter into lightly. The quality of the prototype just wasn't good enough to justify that sort of time commitment, so I tabled the project, putting it on my list of long term things to think about, and moved on to other work. It would sit there for a couple of years. Semi-coincidentally, one of the projects I tacked after that was to create a new mapfile syntax for the Solaris link-editor. We had wanted to do something about the old mapfile syntax for many years. Others before me had done some paper designs, and a great deal of thought had already gone into the features it should, and should not have, but for various reasons things had never moved beyond the idea stage. When I joined Sun in late 2005, I got involved in reviewing those things and thinking about the problem. Now in 2008, fresh from relearning for the Nth time why the old mapfile syntax was a huge impediment to linker progress, it seemed like the right time to tackle the mapfile issue. Paving the way for proper stub object support was not the driving force behind that effort, but I certainly had them in mind as I moved forward. The new mapfile syntax, which we call version 2, integrated into Nevada build snv_135 in in February 2010: 6916788 ld version 2 mapfile syntax PSARC/2009/688 Human readable and extensible ld mapfile syntax In order to prove that the new mapfile syntax was adequate for general purpose use, I had also done an overhaul of the ON consolidation to convert all mapfiles to use the new syntax, and put checks in place that would ensure that no use of the old syntax would creep back in. That work went back into snv_144 in June 2010: 6916796 OSnet mapfiles should use version 2 link-editor syntax That was a big putback, modifying 517 files, adding 18 new files, and removing 110 old ones. I would have done this putback anyway, as the work was already done, and the benefits of human readable syntax are obvious. However, among the justifications listed in CR 6916796 was this We anticipate adding additional features to the new mapfile language that will be applicable to ON, and which will require all sharable object mapfiles to use the new syntax. I never explained what those additional features were, and no one asked. It was premature to say so, but this was a reference to stub objects. By that point, I had already put together a working prototype link-editor with the necessary support for stub objects. I was pleased to find that building stubs was indeed very fast. On my desktop system (Ultra 24), an amd64 stub for libc can can be built in a fraction of a second: % ptime ld -64 -z stub -o stubs/libc.so.1 -G -hlibc.so.1 \ -ztext -zdefs -Bdirect ... real 0.019708910 user 0.010101680 sys 0.008528431 In order to go from prototype to integrated link-editor feature, I knew that I would need to prove that stub objects were valuable. And to do that, I knew that I'd have to switch the Solaris ON consolidation to use stub objects and evaluate the outcome. And in order to do that experiment, ON would first need to be converted to version 2 mapfiles. Sub-mission accomplished. Normally when you design a new feature, you can devise reasonably small tests to show it works, and then deploy it incrementally, letting it prove its value as it goes. The entire point of stub objects however was to demonstrate that they could be successfully applied to an extremely large and complex code base, and specifically to solve the Solaris build issues detailed above. There was no way to finesse the matter — in order to move ahead, I would have to successfully use stub objects to build the entire ON consolidation and demonstrate their value. In software, the need to boil the ocean can often be a warning sign that things are trending in the wrong direction. Conversely, sometimes progress demands that you build something large and new all at once. A big win, or a big loss — sometimes all you can do is try it and see what happens. And so, I spent some time staring at ON makefiles trying to get a handle on how things work, and how they'd have to change. It's a big and messy world, full of complex interactions, unspecified dependencies, special cases, and knowledge of arcane makefile features... ...and so, I backed away, put it down for a few months and did other work... ...until the fall, when I felt like it was time to stop thinking and pondering (some would say stalling) and get on with it. Without stubs, the following gives a simplified high level view of how Solaris is built: An initially empty directory known as the proto, and referenced via the ROOT makefile macro is established to receive the files that make up the Solaris distribution. A top level setup rule creates the proto area, and performs operations needed to initialize the workspace so that the main build operations can be launched, such as copying needed header files into the proto area. Parallel builds are launched to build the kernel (usr/src/uts), libraries (usr/src/lib), and commands. The install makefile target builds each item and delivers a copy to the proto area. All libraries and executables link against the objects previously installed in the proto, implying the need to synchronize the order in which things are built. Subsequent passes run lint, and do packaging. Given this structure, the additions to use stub objects are: A new second proto area is established, known as the stub proto and referenced via the STUBROOT makefile macro. The stub proto has the same structure as the real proto, but is used to hold stub objects. All files in the real proto are delivered as part of the Solaris product. In contrast, the stub proto is used to build the product, and then thrown away. A new target is added to library Makefiles called stub. This rule builds the stub objects. The ld command is designed so that you can build a stub object using the same ld command line you'd use to build the real object, with the addition of a single -z stub option. This means that the makefile rules for building the stub objects are very similar to those used to build the real objects, and many existing makefile definitions can be shared between them. A new target is added to the Makefiles called stubinstall which delivers the stub objects built by the stub rule into the stub proto. These rules reuse much of existing plumbing used by the existing install rule. The setup rule runs stubinstall over the entire lib subtree as part of its initialization. All libraries and executables link against the objects in the stub proto rather than the main proto, and can therefore be built in parallel without any synchronization. There was no small way to try this that would yield meaningful results. I would have to take a leap of faith and edit approximately 1850 makefiles and 300 mapfiles first, trusting that it would all work out. Once the editing was done, I'd type make and see what happened. This took about 6 weeks to do, and there were many dark days when I'd question the entire project, or struggle to understand some of the many twisted and complex situations I'd uncover in the makefiles. I even found a couple of new issues that required changes to the new stub object related code I'd added to ld. With a substantial amount of encouragement and help from some key people in the Solaris group, I eventually got the editing done and stub objects for the entire workspace built. I found that my desktop system could build all the stub objects in the workspace in roughly a minute. This was great news, as it meant that use of the feature is effectively free — no one was likely to notice or care about the cost of building them. After another week of typing make, fixing whatever failed, and doing it again, I succeeded in getting a complete build! The next step was to remove all of the make rules and .WAIT statements dedicated to controlling the order in which libraries under usr/src/lib are built. This came together pretty quickly, and after a few more speed bumps, I had a workspace that built cleanly and looked like something you might actually be able to integrate someday. This was a significant milestone, but there was still much left to do. I turned to doing full nightly builds. Every type of build (open, closed, OpenSolaris, export, domestic) had to be tried. Each type failed in a new and unique way, requiring some thinking and rework. As things came together, I became aware of things that could have been done better, simpler, or cleaner, and those things also required some rethinking, the seeking of wisdom from others, and some rework. After another couple of weeks, it was in close to final form. My focus turned towards the end game and integration. This was a huge workspace, and needed to go back soon, before changes in the gate would made merging increasingly difficult. At this point, I knew that the stub objects had greatly simplified the makefile logic and uncovered a number of race conditions, some of which had been there for years. I assumed that the builds were faster too, so I did some builds intended to quantify the speedup in build time that resulted from this approach. It had never occurred to me that there might not be one. And so, I was very surprised to find that the wall clock build times for a stock ON workspace were essentially identical to the times for my stub library enabled version! This is why it is important to always measure, and not just to assume. One can tell from first principles, based on all those removed dependency rules in the library makefile, that the stub object version of ON gives dmake considerably more opportunities to overlap library construction. Some hypothesis were proposed, and shot down: Could we have disabled dmakes parallel feature? No, a quick check showed things being build in parallel. It was suggested that we might be I/O bound, and so, the threads would be mostly idle. That's a plausible explanation, but system stats didn't really support it. Plus, the timing between the stub and non-stub cases were just too suspiciously identical. Are our machines already handling as much parallelism as they are capable of, and unable to exploit these additional opportunities? Once again, we didn't see the evidence to back this up. Eventually, a more plausible and obvious reason emerged: We build the libraries and commands (usr/src/lib, usr/src/cmd) in parallel with the kernel (usr/src/uts). The kernel is the long leg in that race, and so, wall clock measurements of build time are essentially showing how long it takes to build uts. Although it would have been nice to post a huge speedup immediately, we can take solace in knowing that stub objects simplify the makefiles and reduce the possibility of race conditions. The next step in reducing build time should be to find ways to reduce or overlap the uts part of the builds. When that leg of the build becomes shorter, then the increased parallelism in the libs and commands will pay additional dividends. Until then, we'll just have to settle for simpler and more robust. And so, I integrated the link-editor support for creating stub objects into snv_153 (November 2010) with 6993877 ld should produce stub objects PSARC/2010/397 ELF Stub Objects followed by the work to convert the ON consolidation in snv_161 (February 2011) with 7009826 OSnet should use stub objects 4631488 lib/Makefile is too patient: .WAITs should be reduced This was a huge putback, with 2108 modified files, 8 new files, and 2 removed files. Due to the size, I was allowed a window after snv_160 closed in which to do the putback. It went pretty smoothly for something this big, a few more preexisting race conditions would be discovered and addressed over the next few weeks, and things have been quiet since then. Conclusions and Looking Forward Solaris has been built with stub objects since February. The fact that developers no longer specify the order in which libraries are built has been a big success, and we've eliminated an entire class of build error. That's not to say that there are no build races left in the ON makefiles, but we've taken a substantial bite out of the problem while generally simplifying and improving things. The introduction of a stub proto area has also opened some interesting new possibilities for other build improvements. As this article has become quite long, and as those uses do not involve stub objects, I will defer that discussion to a future article.

    Read the article

  • Do I have to worry about "error: superfluous RAID member"?

    - by 0xC0000022L
    When running update-grub on the newly installed Ubuntu 12.04 with an older software RAID (md), I get: error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). Generating grub.cfg ... error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). Found linux image: /boot/vmlinuz-3.2.0-24-generic Found initrd image: /boot/initrd.img-3.2.0-24-generic error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). Found linux image: /boot/vmlinuz-3.2.0-23-generic Found initrd image: /boot/initrd.img-3.2.0-23-generic error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). Found memtest86+ image: /boot/memtest86+.bin error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). error: superfluous RAID member (5 found). Found Debian GNU/Linux (5.0.9) on /dev/sdb1 Found Debian GNU/Linux (5.0.9) on /dev/sdc1 done I would be less worried if the message would say warning: ..., but since it says error: ... I'm wondering what the problem is. # cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sdc1[1] sdb1[0] 48829440 blocks [2/2] [UU] md3 : active raid1 sdc2[1] sdb2[0] 263739008 blocks [2/2] [UU] md1 : active raid5 sdg1[3] sdf1[2] sde1[1] sdh1[0] sdi1[4] sdd1[5](S) 1250274304 blocks level 5, 64k chunk, algorithm 2 [5/5] [UUUUU] unused devices: <none> Do I have to worry or is this harmless? btw: disregard the mentioning of Debian 5.0.9, that was the previously installed system and is going to be overwritten. It's on /dev/md2 actually.

    Read the article

  • European e-government Action Plan all about interoperability

    - by trond-arne.undheim
    Yesterday, the European Commission released its European eGovernment Action Plan for 2011-2015. The plan includes measures on providing deeper user empowerment, enhancing the Internal Market, more efficiency and effectiveness of public administrations, and putting in place pre-conditions for developing e-government. The Good - Defines interoperability very clearly. Calls interoperability "a pre-condition for cross-border eGovernment services" (a very strong formulation) and says interoperability "is supported by open specifications". - Uses the terminology "open specifications" which, let's face it, is pretty close to "open standards" which is the term the rest of the world would use. - Confirms that Member States are fully committed to the political priorities of the Malmö Declaration (which was all about open standards) including the very strong action: by 2013: All Member States will have incorporated the political priorities of the Malmö Declaration in their national strategies. Such tight Action Plan integration between Commission and Member State priorities has seldom been attempted before, particularly not in a field where European legal competence is virtually non-existent. What we see now, is the subtle force of soft power rather than the rough force of regulation. In this case, it is the Member States who want Europe to take the lead. Very refreshing! Some quotes that show the commitment to interoperability and open specifications: "The emergence of innovative technologies such as "service-oriented architectures" (SOA), or "clouds" of services,  together with more open specifications which allow for greater sharing, re-use and interoperability reinforce the ability of ICT to play a key role in this quest for effficiency in the public sector." (p.4) "Interoperability is supported through open specifications" (p.13) 2.4.1. Open Specifications and Interoperability (p.13 has a whole section dedicated to this important topic. Open specifications and interoperability are nearly 100% interrelated): "Interoperability is the ability of systems and machines to exchange, process and correctly interpret information. It is more than just a technical challenge, as it also involves legal, organisational and semantic aspects of handling  data" (p.13) "standards and  open platforms offer opportunities for more cost-effective use of resources and delivery of services" (p.13). The Bad Shies away from defining open standards, or even open specifications, the EU's preferred term for the key enabler of interoperability. Verdict 90/100, a very respectable score.

    Read the article

  • Creating Multiple Queries for Running Objects

    - by edurdias
    Running Objects combines the power of LINQ with Metadata definition to let you leverage multiples perspectives of your queries of objects. By default, RO brings all the objects in natural order of insertion and including all the visible properties of your class. In this post, we will understand how the QueryAttribute class is structured and how to make use of it. The QueryAttribute class This class is the responsible to specify all the possible perspectives of a list of objects. In other words, is...(read more)

    Read the article

  • Navigate to a virtual member from the member that overrides it

    - by axrwkr
    Using visual studio, in the editor window, I am able to navigate from the usage of a member to the line and file where it is declared by pressing F12 while the cursor is over that member by or right clicking on the member and selecting "Go To Definition". I would like to find a way to navigate from an override member to the base class member that it overrides. For example, if I have the following class with one method public class SomeClass { public virtual void TheMethod() { // do something } } An I override that method somewhere else in the project or solution similar to the following public OtherClass : SomeClass { public override void TheMethod() { // do something else } } I want to navigate from the declaration of TheMethod in OtherClass to the declaration of TheMethod in SomeClass Is there a way to do this? I've found that I can find the definition of the member in the base class by pressing Shift + F12 (Find all References) and then looking through the list occurances, this works fine most of the time, since the list isn't usually that long but it would be much better to have a way to go there directly.

    Read the article

  • Navigate to a virtual member from an overriden member in the derived type

    - by axrwkr
    Using visual studio, in the editor window, I am able to navigate from the usage of a member to the line and file where it is declared by pressing F12 while the cursor is over that member by or right clicking on the member and selecting "Go To Definition". I would like to find a way to navigate from an override member to the base class member that it overrides. For example, if I have the following class with one method public class SomeClass { public virtual void TheMethod() { // do something } } An I override that method somewhere else in the project or solution similar to the following public OtherClass : SomeClass { public override void TheMethod() { // do something else } } I want to navigate from the declaration of TheMethod in OtherClass to the declaration of TheMethod in SomeClass Is there a way to do this? I've found that I can find the definition of the member in the base class by pressing Shift + F12 (Find all References) and then looking through the list occurances, this works fine most of the time, since the list isn't usually that long but it would be much better to have a way to go there directly.

    Read the article

  • Building Awesome WM

    - by Dragan Chupacabrovic
    Hello, I am following these steps in order to build Awesome window manager on 10.04 I am building 3.4 while the tutorial is for 3.1 I installed all of the specified dependencies including cairo. EDIT I ran: sudo apt-get install libxcb-xtest0-dev libxcb-property1-dev libxdg-basedir-dev libstartup-notification0-dev and now it looks like I'm missing a library Please advise: >awesome-3.4$ make Running cmake… -- cat -> /bin/cat -- ln -> /bin/ln -- grep -> /bin/grep -- git -> /usr/bin/git -- hostname -> /bin/hostname -- gperf -> /usr/bin/gperf -- asciidoc -> /usr/bin/asciidoc -- xmlto -> /usr/bin/xmlto -- gzip -> /bin/gzip -- lua -> /usr/bin/lua -- luadoc -> /usr/bin/luadoc -- convert -> /usr/bin/convert -- Configuring lib/naughty.lua -- Configuring lib/awful/tooltip.lua -- Configuring lib/awful/init.lua -- Configuring lib/awful/titlebar.lua -- Configuring lib/awful/key.lua -- Configuring lib/awful/mouse/init.lua -- Configuring lib/awful/mouse/finder.lua -- Configuring lib/awful/autofocus.lua -- Configuring lib/awful/screen.lua -- Configuring lib/awful/rules.lua -- Configuring lib/awful/widget/init.lua -- Configuring lib/awful/widget/taglist.lua -- Configuring lib/awful/widget/graph.lua -- Configuring lib/awful/widget/tasklist.lua -- Configuring lib/awful/widget/common.lua -- Configuring lib/awful/widget/prompt.lua -- Configuring lib/awful/widget/launcher.lua -- Configuring lib/awful/widget/button.lua -- Configuring lib/awful/widget/layoutbox.lua -- Configuring lib/awful/widget/layout/init.lua -- Configuring lib/awful/widget/layout/vertical.lua -- Configuring lib/awful/widget/layout/horizontal.lua -- Configuring lib/awful/widget/layout/default.lua -- Configuring lib/awful/widget/progressbar.lua -- Configuring lib/awful/widget/textclock.lua -- Configuring lib/awful/dbus.lua -- Configuring lib/awful/remote.lua -- Configuring lib/awful/client.lua -- Configuring lib/awful/prompt.lua -- Configuring lib/awful/completion.lua -- Configuring lib/awful/tag.lua -- Configuring lib/awful/util.lua -- Configuring lib/awful/button.lua -- Configuring lib/awful/menu.lua -- Configuring lib/awful/hooks.lua -- Configuring lib/awful/wibox.lua -- Configuring lib/awful/layout/init.lua -- Configuring lib/awful/layout/suit/init.lua -- Configuring lib/awful/layout/suit/floating.lua -- Configuring lib/awful/layout/suit/fair.lua -- Configuring lib/awful/layout/suit/spiral.lua -- Configuring lib/awful/layout/suit/magnifier.lua -- Configuring lib/awful/layout/suit/tile.lua -- Configuring lib/awful/layout/suit/max.lua -- Configuring lib/awful/placement.lua -- Configuring lib/awful/startup_notification.lua -- Configuring lib/beautiful.lua -- Configuring themes/zenburn//theme.lua -- Configuring themes/default//theme.lua -- Configuring themes/sky//theme.lua -- Configuring config.h -- Configuring awesomerc.lua -- Configuring awesome-version-internal.h -- Configuring awesome.doxygen -- Configuring done -- Generating done -- Build files have been written to: /home/druden/util/awesome-3.4/.build-vedroid-i486-linux-gnu-4.4.3 Running make Makefile… Building… [ 4%] Built target generated_sources [ 5%] Building C object CMakeFiles/awesome.dir/awesome.c.o In file included from /home/druden/util/awesome-3.4/spawn.h:25, from /home/druden/util/awesome-3.4/awesome.c:33: /home/druden/util/awesome-3.4/globalconf.h:57: error: expected specifier-qualifier-list before ‘xcb_event_handlers_t’ In file included from /home/druden/util/awesome-3.4/awesome.c:34: /home/druden/util/awesome-3.4/client.h: In function ‘client_stack’: /home/druden/util/awesome-3.4/client.h:212: error: ‘awesome_t’ has no member named ‘client_need_stack_refresh’ /home/druden/util/awesome-3.4/client.h: In function ‘client_raise’: /home/druden/util/awesome-3.4/client.h:227: error: ‘awesome_t’ has no member named ‘stack’ In file included from /home/druden/util/awesome-3.4/awesome.c:42: /home/druden/util/awesome-3.4/titlebar.h: In function ‘titlebar_update_geometry’: /home/druden/util/awesome-3.4/titlebar.h:150: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/titlebar.h:151: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/titlebar.h:152: error: ‘awesome_t’ has no member named ‘L’ In file included from /home/druden/util/awesome-3.4/awesome.c:47: /home/druden/util/awesome-3.4/common/xutil.h: In function ‘xutil_get_text_property_from_reply’: /home/druden/util/awesome-3.4/common/xutil.h:39: warning: ‘STRING’ is deprecated (declared at /usr/local/include/xcb/xcb_atom.h:83) /home/druden/util/awesome-3.4/common/xutil.h: At top level: /home/druden/util/awesome-3.4/common/xutil.h:60: error: expected ‘)’ before ‘*’ token /home/druden/util/awesome-3.4/awesome.c: In function ‘awesome_atexit’: /home/druden/util/awesome-3.4/awesome.c:65: error: ‘awesome_t’ has no member named ‘hooks’ /home/druden/util/awesome-3.4/awesome.c:66: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/awesome.c:66: error: ‘awesome_t’ has no member named ‘hooks’ /home/druden/util/awesome-3.4/awesome.c:68: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/awesome.c:73: error: ‘awesome_t’ has no member named ‘embedded’ /home/druden/util/awesome-3.4/awesome.c:76: error: ‘awesome_t’ has no member named ‘embedded’ /home/druden/util/awesome-3.4/awesome.c:77: error: ‘awesome_t’ has no member named ‘embedded’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: warning: type defaults to ‘int’ in declaration of ‘c’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:89: error: ‘awesome_t’ has no member named ‘clients’ /home/druden/util/awesome-3.4/awesome.c:91: error: invalid type argument of ‘unary *’ (have ‘int’) /home/druden/util/awesome-3.4/awesome.c:92: error: invalid type argument of ‘unary *’ (have ‘int’) /home/druden/util/awesome-3.4/awesome.c:96: error: ‘awesome_t’ has no member named ‘L’ /home/druden/util/awesome-3.4/awesome.c: In function ‘a_xcb_check_cb’: /home/druden/util/awesome-3.4/awesome.c:223: warning: implicit declaration of function ‘xcb_event_handle’ /home/druden/util/awesome-3.4/awesome.c:223: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:230: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c: In function ‘awesome_restart’: /home/druden/util/awesome-3.4/awesome.c:277: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c: In function ‘xerror’: /home/druden/util/awesome-3.4/awesome.c:305: error: ‘XCB_EVENT_ERROR_BAD_WINDOW’ undeclared (first use in this function) /home/druden/util/awesome-3.4/awesome.c:305: error: (Each undeclared identifier is reported only once /home/druden/util/awesome-3.4/awesome.c:305: error: for each function it appears in.) /home/druden/util/awesome-3.4/awesome.c:306: error: ‘XCB_EVENT_ERROR_BAD_MATCH’ undeclared (first use in this function) /home/druden/util/awesome-3.4/awesome.c:308: error: ‘XCB_EVENT_ERROR_BAD_VALUE’ undeclared (first use in this function) /home/druden/util/awesome-3.4/awesome.c: In function ‘main’: /home/druden/util/awesome-3.4/awesome.c:369: error: ‘awesome_t’ has no member named ‘keygrabber’ /home/druden/util/awesome-3.4/awesome.c:370: error: ‘awesome_t’ has no member named ‘mousegrabber’ /home/druden/util/awesome-3.4/awesome.c:376: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:377: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:381: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:382: error: ‘awesome_t’ has no member named ‘argv’ /home/druden/util/awesome-3.4/awesome.c:424: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:425: error: ‘awesome_t’ has no member named ‘timer’ /home/druden/util/awesome-3.4/awesome.c:431: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:432: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:433: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:434: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:435: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:436: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:443: error: ‘awesome_t’ has no member named ‘default_screen’ /home/druden/util/awesome-3.4/awesome.c:450: error: ‘awesome_t’ has no member named ‘have_xtest’ /home/druden/util/awesome-3.4/awesome.c:462: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:464: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:465: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:467: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:468: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:471: warning: implicit declaration of function ‘xcb_event_handlers_init’ /home/druden/util/awesome-3.4/awesome.c:471: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:472: warning: implicit declaration of function ‘xutil_error_handler_catch_all_set’ /home/druden/util/awesome-3.4/awesome.c:472: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:490: warning: implicit declaration of function ‘xcb_event_poll_for_event_loop’ /home/druden/util/awesome-3.4/awesome.c:490: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:493: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:496: error: ‘awesome_t’ has no member named ‘keysyms’ /home/druden/util/awesome-3.4/awesome.c:507: error: ‘awesome_t’ has no member named ‘colors’ /home/druden/util/awesome-3.4/awesome.c:510: error: ‘awesome_t’ has no member named ‘colors’ /home/druden/util/awesome-3.4/awesome.c:513: error: ‘awesome_t’ has no member named ‘font’ /home/druden/util/awesome-3.4/awesome.c:519: error: ‘awesome_t’ has no member named ‘keysyms’ /home/druden/util/awesome-3.4/awesome.c:519: error: ‘awesome_t’ has no member named ‘numlockmask’ /home/druden/util/awesome-3.4/awesome.c:520: error: ‘awesome_t’ has no member named ‘shiftlockmask’ /home/druden/util/awesome-3.4/awesome.c:520: error: ‘awesome_t’ has no member named ‘capslockmask’ /home/druden/util/awesome-3.4/awesome.c:521: error: ‘awesome_t’ has no member named ‘modeswitchmask’ /home/druden/util/awesome-3.4/awesome.c:563: error: ‘awesome_t’ has no member named ‘evenths’ /home/druden/util/awesome-3.4/awesome.c:572: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:575: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:576: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:577: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:578: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:579: error: ‘awesome_t’ has no member named ‘loop’ /home/druden/util/awesome-3.4/awesome.c:580: error: ‘awesome_t’ has no member named ‘loop’ make[3]: *** [CMakeFiles/awesome.dir/awesome.c.o] Error 1 make[2]: *** [CMakeFiles/awesome.dir/all] Error 2 make[1]: *** [all] Error 2 make: *** [cmake-build] Error 2

    Read the article

  • Using Stub Objects

    - by user9154181
    Having told the long and winding tale of where stub objects came from and how we use them to build Solaris, I'd like to focus now on the the nuts and bolts of building and using them. The following new features were added to the Solaris link-editor (ld) to support the production and use of stub objects: -z stub This new command line option informs ld that it is to build a stub object rather than a normal object. In this mode, it accepts the same command line arguments as usual, but will quietly ignore any objects and sharable object dependencies. STUB_OBJECT Mapfile Directive In order to build a stub version of an object, its mapfile must specify the STUB_OBJECT directive. When producing a non-stub object, the presence of STUB_OBJECT causes the link-editor to perform extra validation to ensure that the stub and non-stub objects will be compatible. ASSERT Mapfile Directive All data symbols exported from the object must have an ASSERT symbol directive in the mapfile that declares them as data and supplies the size, binding, bss attributes, and symbol aliasing details. When building the stub objects, the information in these ASSERT directives is used to create the data symbols. When building the real object, these ASSERT directives will ensure that the real object matches the linking interface presented by the stub. Although ASSERT was added to the link-editor in order to support stub objects, they are a general purpose feature that can be used independently of stub objects. For instance you might choose to use an ASSERT directive if you have a symbol that must have a specific address in order for the object to operate properly and you want to automatically ensure that this will always be the case. The material presented here is derived from a document I originally wrote during the development effort, which had the dual goals of providing supplemental materials for the stub object PSARC case, and as a set of edits that were eventually applied to the Oracle Solaris Linker and Libraries Manual (LLM). The Solaris 11 LLM contains this information in a more polished form. Stub Objects A stub object is a shared object, built entirely from mapfiles, that supplies the same linking interface as the real object, while containing no code or data. Stub objects cannot be used at runtime. However, an application can be built against a stub object, where the stub object provides the real object name to be used at runtime, and then use the real object at runtime. When building a stub object, the link-editor ignores any object or library files specified on the command line, and these files need not exist in order to build a stub. Since the compilation step can be omitted, and because the link-editor has relatively little work to do, stub objects can be built very quickly. Stub objects can be used to solve a variety of build problems: Speed Modern machines, using a version of make with the ability to parallelize operations, are capable of compiling and linking many objects simultaneously, and doing so offers significant speedups. However, it is typical that a given object will depend on other objects, and that there will be a core set of objects that nearly everything else depends on. It is necessary to impose an ordering that builds each object before any other object that requires it. This ordering creates bottlenecks that reduce the amount of parallelization that is possible and limits the overall speed at which the code can be built. Complexity/Correctness In a large body of code, there can be a large number of dependencies between the various objects. The makefiles or other build descriptions for these objects can become very complex and difficult to understand or maintain. The dependencies can change as the system evolves. This can cause a given set of makefiles to become slightly incorrect over time, leading to race conditions and mysterious rare build failures. Dependency Cycles It might be desirable to organize code as cooperating shared objects, each of which draw on the resources provided by the other. Such cycles cannot be supported in an environment where objects must be built before the objects that use them, even though the runtime linker is fully capable of loading and using such objects if they could be built. Stub shared objects offer an alternative method for building code that sidesteps the above issues. Stub objects can be quickly built for all the shared objects produced by the build. Then, all the real shared objects and executables can be built in parallel, in any order, using the stub objects to stand in for the real objects at link-time. Afterwards, the executables and real shared objects are kept, and the stub shared objects are discarded. Stub objects are built from a mapfile, which must satisfy the following requirements. The mapfile must specify the STUB_OBJECT directive. This directive informs the link-editor that the object can be built as a stub object, and as such causes the link-editor to perform validation and sanity checking intended to guarantee that an object and its stub will always provide identical linking interfaces. All function and data symbols that make up the external interface to the object must be explicitly listed in the mapfile. The mapfile must use symbol scope reduction ('*'), to remove any symbols not explicitly listed from the external interface. All global data exported from the object must have an ASSERT symbol attribute in the mapfile to specify the symbol type, size, and bss attributes. In the case where there are multiple symbols that reference the same data, the ASSERT for one of these symbols must specify the TYPE and SIZE attributes, while the others must use the ALIAS attribute to reference this primary symbol. Given such a mapfile, the stub and real versions of the shared object can be built using the same command line for each, adding the '-z stub' option to the link for the stub object, and omiting the option from the link for the real object. To demonstrate these ideas, the following code implements a shared object named idx5, which exports data from a 5 element array of integers, with each element initialized to contain its zero-based array index. This data is available as a global array, via an alternative alias data symbol with weak binding, and via a functional interface. % cat idx5.c int _idx5[5] = { 0, 1, 2, 3, 4 }; #pragma weak idx5 = _idx5 int idx5_func(int index) { if ((index 4)) return (-1); return (_idx5[index]); } A mapfile is required to describe the interface provided by this shared object. % cat mapfile $mapfile_version 2 STUB_OBJECT; SYMBOL_SCOPE { _idx5 { ASSERT { TYPE=data; SIZE=4[5] }; }; idx5 { ASSERT { BINDING=weak; ALIAS=_idx5 }; }; idx5_func; local: *; }; The following main program is used to print all the index values available from the idx5 shared object. % cat main.c #include <stdio.h> extern int _idx5[5], idx5[5], idx5_func(int); int main(int argc, char **argv) { int i; for (i = 0; i The following commands create a stub version of this shared object in a subdirectory named stublib. elfdump is used to verify that the resulting object is a stub. The command used to build the stub differs from that of the real object only in the addition of the -z stub option, and the use of a different output file name. This demonstrates the ease with which stub generation can be added to an existing makefile. % cc -Kpic -G -M mapfile -h libidx5.so.1 idx5.c -o stublib/libidx5.so.1 -zstub % ln -s libidx5.so.1 stublib/libidx5.so % elfdump -d stublib/libidx5.so | grep STUB [11] FLAGS_1 0x4000000 [ STUB ] The main program can now be built, using the stub object to stand in for the real shared object, and setting a runpath that will find the real object at runtime. However, as we have not yet built the real object, this program cannot yet be run. Attempts to cause the system to load the stub object are rejected, as the runtime linker knows that stub objects lack the actual code and data found in the real object, and cannot execute. % cc main.c -L stublib -R '$ORIGIN/lib' -lidx5 -lc % ./a.out ld.so.1: a.out: fatal: libidx5.so.1: open failed: No such file or directory Killed % LD_PRELOAD=stublib/libidx5.so.1 ./a.out ld.so.1: a.out: fatal: stublib/libidx5.so.1: stub shared object cannot be used at runtime Killed We build the real object using the same command as we used to build the stub, omitting the -z stub option, and writing the results to a different file. % cc -Kpic -G -M mapfile -h libidx5.so.1 idx5.c -o lib/libidx5.so.1 Once the real object has been built in the lib subdirectory, the program can be run. % ./a.out [0] 0 0 0 [1] 1 1 1 [2] 2 2 2 [3] 3 3 3 [4] 4 4 4 Mapfile Changes The version 2 mapfile syntax was extended in a number of places to accommodate stub objects. Conditional Input The version 2 mapfile syntax has the ability conditionalize mapfile input using the $if control directive. As you might imagine, these directives are used frequently with ASSERT directives for data, because a given data symbol will frequently have a different size in 32 or 64-bit code, or on differing hardware such as x86 versus sparc. The link-editor maintains an internal table of names that can be used in the logical expressions evaluated by $if and $elif. At startup, this table is initialized with items that describe the class of object (_ELF32 or _ELF64) and the type of the target machine (_sparc or _x86). We found that there were a small number of cases in the Solaris code base in which we needed to know what kind of object we were producing, so we added the following new predefined items in order to address that need: NameMeaning ...... _ET_DYNshared object _ET_EXECexecutable object _ET_RELrelocatable object ...... STUB_OBJECT Directive The new STUB_OBJECT directive informs the link-editor that the object described by the mapfile can be built as a stub object. STUB_OBJECT; A stub shared object is built entirely from the information in the mapfiles supplied on the command line. When the -z stub option is specified to build a stub object, the presence of the STUB_OBJECT directive in a mapfile is required, and the link-editor uses the information in symbol ASSERT attributes to create global symbols that match those of the real object. When the real object is built, the presence of STUB_OBJECT causes the link-editor to verify that the mapfiles accurately describe the real object interface, and that a stub object built from them will provide the same linking interface as the real object it represents. All function and data symbols that make up the external interface to the object must be explicitly listed in the mapfile. The mapfile must use symbol scope reduction ('*'), to remove any symbols not explicitly listed from the external interface. All global data in the object is required to have an ASSERT attribute that specifies the symbol type and size. If the ASSERT BIND attribute is not present, the link-editor provides a default assertion that the symbol must be GLOBAL. If the ASSERT SH_ATTR attribute is not present, or does not specify that the section is one of BITS or NOBITS, the link-editor provides a default assertion that the associated section is BITS. All data symbols that describe the same address and size are required to have ASSERT ALIAS attributes specified in the mapfile. If aliased symbols are discovered that do not have an ASSERT ALIAS specified, the link fails and no object is produced. These rules ensure that the mapfiles contain a description of the real shared object's linking interface that is sufficient to produce a stub object with a completely compatible linking interface. SYMBOL_SCOPE/SYMBOL_VERSION ASSERT Attribute The SYMBOL_SCOPE and SYMBOL_VERSION mapfile directives were extended with a symbol attribute named ASSERT. The syntax for the ASSERT attribute is as follows: ASSERT { ALIAS = symbol_name; BINDING = symbol_binding; TYPE = symbol_type; SH_ATTR = section_attributes; SIZE = size_value; SIZE = size_value[count]; }; The ASSERT attribute is used to specify the expected characteristics of the symbol. The link-editor compares the symbol characteristics that result from the link to those given by ASSERT attributes. If the real and asserted attributes do not agree, a fatal error is issued and the output object is not created. In normal use, the link editor evaluates the ASSERT attribute when present, but does not require them, or provide default values for them. The presence of the STUB_OBJECT directive in a mapfile alters the interpretation of ASSERT to require them under some circumstances, and to supply default assertions if explicit ones are not present. See the definition of the STUB_OBJECT Directive for the details. When the -z stub command line option is specified to build a stub object, the information provided by ASSERT attributes is used to define the attributes of the global symbols provided by the object. ASSERT accepts the following: ALIAS Name of a previously defined symbol that this symbol is an alias for. An alias symbol has the same type, value, and size as the main symbol. The ALIAS attribute is mutually exclusive to the TYPE, SIZE, and SH_ATTR attributes, and cannot be used with them. When ALIAS is specified, the type, size, and section attributes are obtained from the alias symbol. BIND Specifies an ELF symbol binding, which can be any of the STB_ constants defined in <sys/elf.h>, with the STB_ prefix removed (e.g. GLOBAL, WEAK). TYPE Specifies an ELF symbol type, which can be any of the STT_ constants defined in <sys/elf.h>, with the STT_ prefix removed (e.g. OBJECT, COMMON, FUNC). In addition, for compatibility with other mapfile usage, FUNCTION and DATA can be specified, for STT_FUNC and STT_OBJECT, respectively. TYPE is mutually exclusive to ALIAS, and cannot be used in conjunction with it. SH_ATTR Specifies attributes of the section associated with the symbol. The section_attributes that can be specified are given in the following table: Section AttributeMeaning BITSSection is not of type SHT_NOBITS NOBITSSection is of type SHT_NOBITS SH_ATTR is mutually exclusive to ALIAS, and cannot be used in conjunction with it. SIZE Specifies the expected symbol size. SIZE is mutually exclusive to ALIAS, and cannot be used in conjunction with it. The syntax for the size_value argument is as described in the discussion of the SIZE attribute below. SIZE The SIZE symbol attribute existed before support for stub objects was introduced. It is used to set the size attribute of a given symbol. This attribute results in the creation of a symbol definition. Prior to the introduction of the ASSERT SIZE attribute, the value of a SIZE attribute was always numeric. While attempting to apply ASSERT SIZE to the objects in the Solaris ON consolidation, I found that many data symbols have a size based on the natural machine wordsize for the class of object being produced. Variables declared as long, or as a pointer, will be 4 bytes in size in a 32-bit object, and 8 bytes in a 64-bit object. Initially, I employed the conditional $if directive to handle these cases as follows: $if _ELF32 foo { ASSERT { TYPE=data; SIZE=4 } }; bar { ASSERT { TYPE=data; SIZE=20 } }; $elif _ELF64 foo { ASSERT { TYPE=data; SIZE=8 } }; bar { ASSERT { TYPE=data; SIZE=40 } }; $else $error UNKNOWN ELFCLASS $endif I found that the situation occurs frequently enough that this is cumbersome. To simplify this case, I introduced the idea of the addrsize symbolic name, and of a repeat count, which together make it simple to specify machine word scalar or array symbols. Both the SIZE, and ASSERT SIZE attributes support this syntax: The size_value argument can be a numeric value, or it can be the symbolic name addrsize. addrsize represents the size of a machine word capable of holding a memory address. The link-editor substitutes the value 4 for addrsize when building 32-bit objects, and the value 8 when building 64-bit objects. addrsize is useful for representing the size of pointer variables and C variables of type long, as it automatically adjusts for 32 and 64-bit objects without requiring the use of conditional input. The size_value argument can be optionally suffixed with a count value, enclosed in square brackets. If count is present, size_value and count are multiplied together to obtain the final size value. Using this feature, the example above can be written more naturally as: foo { ASSERT { TYPE=data; SIZE=addrsize } }; bar { ASSERT { TYPE=data; SIZE=addrsize[5] } }; Exported Global Data Is Still A Bad Idea As you can see, the additional plumbing added to the Solaris link-editor to support stub objects is minimal. Furthermore, about 90% of that plumbing is dedicated to handling global data. We have long advised against global data exported from shared objects. There are many ways in which global data does not fit well with dynamic linking. Stub objects simply provide one more reason to avoid this practice. It is always better to export all data via a functional interface. You should always hide your data, and make it available to your users via a function that they can call to acquire the address of the data item. However, If you do have to support global data for a stub, perhaps because you are working with an already existing object, it is still easilily done, as shown above. Oracle does not like us to discuss hypothetical new features that don't exist in shipping product, so I'll end this section with a speculation. It might be possible to do more in this area to ease the difficulty of dealing with objects that have global data that the users of the library don't need. Perhaps someday... Conclusions It is easy to create stub objects for most objects. If your library only exports function symbols, all you have to do to build a faithful stub object is to add STUB_OBJECT; and then to use the same link command you're currently using, with the addition of the -z stub option. Happy Stubbing!

    Read the article

  • Running Objects – Associations and Relationships

    - by edurdias
    After the introduction to the Running Objects with the tutorial Movie Database in 2 Minutes (available here), I would like to demonstrate how Running Objects interprets the Associations where we will cover: Direct Association – A reference to another complex object. Aggregation – A collection of another complex object. For those coming with a database perspective, by demonstrating these associations we will also exemplify the underline relationships such as 1 to Many and Many to Many relationships...(read more)

    Read the article

  • SQL MDS - Updating the Name attribute of member using Staging Table

    - by Randy Aldrich Paulo
    Creating member is usually done by populating the Member Staging Table (tblStgMember), during this process you assign a value for member code and member name. Now if you want to update the member name attribute you can do this by adding record in Attribute staging table (tblStgMemberAttribute) with Attribute Name = "Name". If you try populating the tblStgMember table it will say that the member code already exists.   INSERT INTO mdm.tblStgMemberAttribute (ModelName, EntityName, MemberType_ID, MemberCode, AttributeName, AttributeValue) VALUES (N'Product', N'Product', 1, N'BK-M101', N'Name',N'Updated Member Name Description')

    Read the article

  • Business Objects - Containers or functional?

    - by Walter
    Where I work, we've gone back and forth on this subject a number of times and are looking for a sanity check. Here's the question: Should Business Objects be data containers (more like DTOs) or should they also contain logic that can perform some functionality on that object. Example - Take a customer object, it probably contains some common properties (Name, Id, etc), should that customer object also include functions (Save, Calc, etc.)? One line of reasoning says separate the object from the functionality (single responsibility principal) and put the functionality in a Business Logic layer or object. The other line of reasoning says, no, if I have a customer object I just want to call Customer.Save and be done with it. Why do I need to know about how to save a customer if I'm consuming the object? Our last two projects have had the objects separated from the functionality, but the debate has been raised again on a new project. Which makes more sense? EDIT These results are very similar to our debates. One vote to one side or another completely changes the direction. Does anyone else want to add their 2 cents? EDIT Eventhough the answer sampling is small, it appears that the majority believe that functionality in a business object is acceptable as long as it is simple but persistence is best placed in a separate class/layer. We'll give this a try. Thanks for everyone's input...

    Read the article

  • Business Objects Enterprise reporting using SDK client gives exception

    - by Dev_Karl
    Hi! We have a client that is using the SDK for invoking reports on the Business Objects Embedded Report Server. We can login, but when calling the openDocument method, something goes wrong. code: //logon IEnterpriseSession session = sessionMgr.logon(username, password, clusterNode, authType); .... clientDoc = reportAppFactory.openDocument(report, 0, locale); /*row 58 in exception*/ exception: com.crystaldecisions.sdk.occa.report.lib.ReportSDKServerException: Unable to connect to the server: . - Server not found or server may be down---- Error code:-2147217387 Error code name:connectServer at com.crystaldecisions.sdk.occa.managedreports.ras.internal.RASReportAppFactory.a(Unknown Source) at com.crystaldecisions.sdk.occa.managedreports.ras.internal.RASReportAppFactory.a(Unknown Source) at com.crystaldecisions.sdk.occa.managedreports.ras.internal.RASReportAppFactory.a(Unknown Source) at com.crystaldecisions.sdk.occa.managedreports.ras.internal.RASReportAppFactory.openDocument(Unknown Source) at com.reportclient.MyReportClient.getReportFromInfoStore(MyReportClient.java:58) ... 28 more Caused by: com.crystaldecisions.sdk.occa.report.lib.ReportSDKServerException: Unable to connect to the server: . - Server not found or server may be down---- Error code:-2147217387 Error code name:connectServer at com.crystaldecisions.sdk.occa.report.lib.ReportSDKServerException.throwReportSDKServerException(Unknown Source) at com.crystaldecisions.sdk.occa.managedreports.ras.internal.CECORBACommunicationAdapter.connect(Unknown Source) ... 32 more Caused by: com.crystaldecisions.enterprise.ocaframework.OCAFrameworkException$NotFoundInDirectory: Server not found or server may be down at com.crystaldecisions.enterprise.ocaframework.j.find(Unknown Source) at com.crystaldecisions.enterprise.ocaframework.AbstractServerHandler.buildServerInfo(Unknown Source) at com.crystaldecisions.enterprise.ocaframework.AbstractServerHandler.buildClusterInfo(Unknown Source) at com.crystaldecisions.enterprise.ocaframework.aa.for(Unknown Source) at com.crystaldecisions.enterprise.ocaframework.ServiceMgr.for(Unknown Source) at com.crystaldecisions.enterprise.ocaframework.o.a(Unknown Source) at com.crystaldecisions.enterprise.ocaframework.o.a(Unknown Source) at com.crystaldecisions.enterprise.ocaframework.o.a(Unknown Source) at com.crystaldecisions.enterprise.ocaframework.p.a(Unknown Source) at com.crystaldecisions.enterprise.ocaframework.ServiceMgr.getManagedService(Unknown Source) ... 33 more The communication obviously works when logging in. Please let me know if you got any ideas or know where I can go and look for the answer. :) Regards, Karl

    Read the article

  • PHP OOP Concepts (Value Objects / Data Access Objects)

    - by Iuhiz
    Hi, I've just started to learn PHP OOP, previously I have been doing PHP in a procedural manner. I was reading this article and I've got a couple of quick questions, How is the constructor for value objects commonly defined? As one that takes in all "data members" as parameters or stick to the default constructor and use mutator / accessor methods to set / get data members? Is this actually the recommended way to start doing PHP OOP? Cos honestly, the concepts explained in the article was a tad confusing for me. Cheers

    Read the article

  • Movie Database in 2 Minutes with Running Objects

    - by edurdias
    Demonstrating how to use Running Objects, we have published a tutorial in how to create a Movie Database, like the one from Stephen Walther, in just 2 minutes. The tutorial demonstrate how to create the application end-to-end. You can access the tutorial in the following URL: http://runningobjects.azurewebsites.net/p/movie-database-in-2-minutes I hope you enjoy it!   Regards, Eduardo...(read more)

    Read the article

  • SQL Server 2012 : Changes to system objects in RC0

    - by AaronBertrand
    As with every new major milestone, one of the first things I do is check out what has changed under the covers. Since RC0 was released yesterday, I've been poking around at some of the DMV and other system changes. Here is what I have noticed: New objects in RC0 that weren't in CTP3 Quick summary: We see a bunch of new aggregates for use with geography and geometry. I've stayed away from that area of programming so I'm not going to dig into them. There is a new extended procedure called sp_showmemo_xml....(read more)

    Read the article

  • [C++]Advantage of using a static member function instead of an equivalent non-static member function

    - by jonathanasdf
    I was wondering whether there's any advantages to using a static member function when there is a non-static equivalent. Will it result in faster execution (because of not having to care about all of the member variables), or maybe less use of memory (because of not being included in all instances)? Basically, the function I'm looking at is an utility function to rotate an integer array representing pixel colours an arbitrary number of degrees around an arbitrary centre point. It is placed in my abstract Bullet base class, since only the bullets will be using it and I didn't want the overhead of calling it in some utility class. It's a bit too long and used in every single derived bullet class, making it probably not a good idea to inline. How would you suggest I define this function? As a static member function of Bullet, of a non-static member function of Bullet, or maybe not as a member of Bullet but defined outside of the class in Bullet.h? What are the advantages and disadvantages of each?

    Read the article

  • Foreach loop with 2d array of objects

    - by Jacob Millward
    I'm using a 2D array of objects to store data about tiles, or "blocks" in my gameworld. I initialise the array, fill it with data and then attempt to invoke the draw method of each object. foreach (Block block in blockList) { block.Draw(spriteBatch); } I end up with an exception being thrown "Object reference is not set to an instance of an object". What have I done wrong? EDIT: This is the code used to define the array Block[,] blockList; Then blockList = new Block[screenRectangle.Width, screenRectangle.Height]; // Fill with dummy data for (int x = 0; x <= screenRectangle.Width / texture.Width; x++) { for (int y = 0; y <= screenRectangle.Height / texture.Width; y++) { if (y >= screenRectangle.Height / (texture.Width*2)) { blockList[x, y] = new Block(1, new Rectangle(x * 16, y * 16, texture.Width, texture.Height), texture); } else { blockList[x, y] = new Block(0, new Rectangle(x * 16, y * 16, texture.Width, texture.Height), texture); } } }

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >